Hi All, I'll take an initial "stab" at this. This is just my initial thoughts/brainstorms, but I could be convinced otherwise :)
On 5/5/2011 10:15 AM, Robin Taylor wrote: > Hi all, > > I just wanted to bring up one area that we didn't really touch on in the > developer meeting viz. the management of modules. For the sake of > argument lets assume we did move much of the code into discrete external > modules, are we in agreement about how we would manage these modules ? > > 1. Who would have commit rights to the various modules ? Bear in mind > that currently more than just the committers have commit rights to some > modules. Not a bad thing in itself but something to consider. In my mind, there are (at least) two "types" of module projects: 1) Third-Party "Plugin" modules -- these are modules which are *not* distributed "out-of-the-box", and in fact are not even centrally controlled by Committers (any third-party entity can create and distribute a 'plugin'). 2) "Official", "centrally controlled" modules/projects -- these are modules which are distributed "out-of-the-box", and/or have some level of centralized control (e.g. they are vetted, tested, approved and released centrally by the Committers). So, for some basic examples: * Currently, I'd consider the REST API to still be an "Third Party Plugin", which is still primarily under development by a 'third party entity' (in this case, it's really primarily Bojan). It hopefully will undergo a transition into a centrally controlled, "Official" module in near future, wherein it would then become vetted, accepted, and released as part of DSpace (or as an optional part of DSpace). * Currently, I'd consider 'dspace-discovery', 'dspace-solr', 'dspace-stats' and 'dspace-services' to be "Official Modules". These are all currently released "out-of-the-box" (even if some are disabled by default and optional to enable). They all also undergo a formalized Testathon & release as part of DSpace. Therefore, these should be considered vetted, tested, approved & released by the Committers. You'll notice, I mentioned the ability to *transition* between module types. I think this will become even more important in the future. We've already seen some modules make this transition, e.g. Discovery was initially a "Third Party Plugin" (controlled/developed entirely by @mire), but transitioned into an "Official" module during the DSpace 1.7.0 release when it was officially accepted/adopted by the Committers. > 2. Who would decide when a module should be released ? Based on the type of module, I think it's the group or entity that 'controls' that module. Third-party Plugin modules are released by the third-party person/group who is working on them. But, in my opinion, "official" modules should *always* be released by the Committers (after they have undergone official vetting, testing, approval). There may be some "gray areas" here, where we need to decide whether others (non-committers) could actually continue to help develop on "official" modules. But, I feel that even if others help with development of "official modules", the official *vetting* and *releasing* should be performed by a Committer. > > 3. Who would do the release ? Again, I'd say whoever 'controls' the module. In the case of "official" modules, it'd likely be either the DSpace Release Coordinator, or maybe we would designate a "Release Team" (in which case it would be someone who is officially a member of that Release Team who would be designated to release a particular module). > > I think this goes to the heart of how we see the project > developing. Does it remain under control of the existing committers > group or does it become more of an Eclipse type framework where > different interest groups maintain and manage their own modules. I'm not sure if all will agree with me. But, as you can tell above, I feel the existing Committers group needs to maintain some level of control over those "official" modules. At this point in time, I'm not sure we have enough highly active developers to make up "different interest groups" around different modules. However, as implied above, we should start to *enable* people to form their own interest groups and create their own 'third party plugins'. If some of those groups become highly active and build amazing 'third party plugins', that'd be *wonderful* (and we could then determine if we wanted to give those groups even more 'control'). But, until we see that happen, I think it is within our best interest to keep some level of 'centralized' Committer control (while also enabling others to build their own third-party plugins as they see fit). Again, just my opinions here (please feel free to disagree/agree with me, as I feel this is something we should discuss openly and decide upon together). - Tim ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
