This one's for the other maintainers of this module -- chx added me as a co-maintainer yesterday at the end of DrupalCon. I committed #971260: Adding event details page to mongodb_watchdog to the 6.x branch, but I want to hold off on committing #971232: Collection name variables should be removed and other changes until I coordinate it with the other maintainers.
Specifically:

  • The patch in #971232: Collection name variables should be removed would affect other modules using this one, so it would have to be released carefully.
  • commit log c911d0d2080fbac53173d8ca20982aec9f174886: "The D7 version of the module is actually compatible with D6 at this point: just update the .info" - indicates that there should be much closer code coordination between the branches. How should this be handled?
  • How are releases coordinated among the multiple maintainers in general?

I'm happy to take this "offline" to IRC, let me know.
Thanks!

Comments

chx’s picture

chx commented

Yes. I will answer. (aka subscribe)

chx’s picture

chx commented

OK I am back. Sorry for disappearing like that. Life was happening. Lots. And I spent my Drupal time in the relation project. Thanks for coordinating. I just pushed a lot of stuff (basically, the last eight or so months of fixes from examiner.com) to D7 but the mongodb.module itself did not change this time see http://drupalcode.org/project/mongodb.git/history/refs/heads/7.x-1.x:/mo...

and let's coordinate releases, yes. I answered the other issue too.

crea’s picture

crea commented

Subscribing

thebuckst0p’s picture

thebuckst0p commented

Thanks chx! I reviewed the issues you just updated for 6.x relevance, most don't apply, but #971232: Collection name variables should be removed is still outstanding, I committed a partial fix (removing unused variables), but I could use a 2nd eye before I commit the main issue (inconsistent variables).

I'm only using the Watchdog part of the module, and the core connection helpers for custom functionality, so I'm not sure what the roadmap or status of the cache and session components are. Is anyone using them?

thebuckst0p’s picture

thebuckst0p commented
Status: Active » Postponed (maintainer needs more info)

Looks like we need someone who uses the cache or session parts of the 6.x module in production to give some feedback on those. I'll mark this 'postponed' for now.

arielkung’s picture

arielkung commented

Hi, I'm going to use sessions part on a high traffic production site. I'll try to stay tuned and give some feedback.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Postponed (maintainer needs more info) » Active

I took an different approach in #1174142: Backport from D7 version, by bringing the 6.x version completely to sync with the latest 7.x version (mongodb[_watchdog] only).

This seems a more natural fix than letting the 6.x version evolve/diverge separately and with lower functionality for the same (sub)modules: as I will be working again quite a bit on Mongo with 6.x for several weeks, I will also be more able to work on 6.x issues if we follow this path than the current version, since it will be closer to the 7.x. This should also make it easier for anyone wishing to backport any of the other submodules if mongodb.module, at least, stays mostly in sync with 7.x.

crea’s picture

crea commented

I suggest that we review (for a short time) existing patches in the queue and commit. We don't have a release at this point so it's better to commit something that is known to work and to continue from there.
Then we can invite everyone to test the dev release and report bugs. It's much easier to test when you have working module out of the box without applying handful of patches.

Reported installs: 36 sites currently report using this module.

This is a very low score for such promising module and I think we could change that.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented
Status: Active » Needs review

As indicated on the #1174142: Backport from D7 version, the 6.x version is now in line with the 7.x version for mongodb and watchdog, meaning from then on, patches for these two modules should likely apply to both versions.

Until #1007974: Backport sessions module to D6, #1098268: Backport cache to D6 and #1179738: Backport queue to D6 are committed, other modules can still evolve only on D7, likely making it easier to backport from a single version than maintaining divergent code bases. Once/if these are backported, patches should then apply to both versions (or be backported from D7 where needed).

I do not think it makes sense to open the D8 branch yet, does it ?

The "needs review" status is set for this proposed policy, not for the code, of course.

thebuckst0p’s picture

thebuckst0p commented

Nice work fgm. I just got back from vacation and won't have any time (or incentive) to work on this module for the foreseeable future, so it's all yours as far as I'm concerned.
Ben

crea’s picture

crea commented

Actually, I'm interested in 6.x too. I'm only learning MongoDB thus I can't make important decisions on my own. Also I don't use IRC unfortunately, but I'm always happy to discuss stuff in the issue queue.

fgm’s picture

fgm
Primary language French
Location Paris, France
commented

OK, committed our latest changes to 6.x.

crea’s picture

crea commented

I think having separate code bases is inevitable. I am happy to develop for D6, but having to make D7 version of a patch then backporting it to D6 would be very frustrating for me, because I'm not even using D7.
So I say, let's hack the hell of it, and D7 users can forward port.

marcingy’s picture

marcingy commented
Status: Needs review » Closed (won't fix)

Closing as over 2 years old