Rather timely that you sent an email about this, as I was thinking a bit
more about this over lunch.
And in particular, about the issue of 'additional' modules and the spaghetti
dependencies between them and the projects of the official release [trunk].
Bottom line, is that I still believe that basically, it should just be
avoided, and that things should either be 'the default', which means they
are part of the release (both in logically and in project location - even if
they can be disabled). Or it is additional, in which case the release should
not reference them at all - and it's up to the user to add the module (eg.
by editing the pom).
What I additionally considered though is, do we really need to limit
ourselves to thinking about there only being one release?
Yes, it would start with the 'minimal' community supported, truly supported
release - which is trunk and doesn't have any reference to things that are
modules. But there could be subsequent separate release(s), that do bundle
in the optional modules as being enabled.
In fact, that is a good opportunity for someone - say @mire - to create
their own, branded open source package, bundling up the modules they want to
include - optional open source modules, trial commercial ones, etc.
Basically, it would operate the same way as the Acquia / Drupal model [a
core Drupal release, and an enhanced 'free' Acquia one]. And we wouldn't
have to worry about the trunk <-> modules cross-dependencies.
G
On 5 May 2011 16:22, Tim Donohue <tdono...@duraspace.org> wrote:
> 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
>
------------------------------------------------------------------------------
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
