Mark & All, Although I welcome more discussion around Git/Github and whether or not we'd like to move that direction, I feel we should try to avoid jumping down to 'technological solutions' with these questions that Robin posed.
Robin can correct me if I'm wrong, but I feel Robin's questions were more related to *policy decisions* from the Committers group. For example, his first question could have been reworded as: "What should be our *policy* around who should have commit rights to various modules?". To be honest, I worry that jumping directly into technology implementation ideas (git/github, etc.) only muddles things a bit. I don't mean any offense with this suggestion, I'm just noting that I don't think we're even all on the "same page" yet -- which is where we need to be before we can make decisions on *how* we want to move forward. To put this another way, as a group, we first need to determine "what it is we are trying to achieve" (policy-wise and at a 'higher level'), and then we can look at "how best to achieve that" (via technology, whether it is git/github or an SVN reorganization or further modularization or whatever). If there was one thing that came out of our discussion at yesterday's developers meeting, it's that we definitely don't all seem to have a common understanding of what it is we want to achieve (in regards to asynchronous releases or modularization, etc). I think Robin's questions (and other similar questions that others may have) are worth us all taking some time to think about and provide our own opinions on, so that we can move towards a common understanding. Just my two cents on this.. :) - Tim On 5/5/2011 11:00 AM, Mark Diggory wrote: > > On May 5, 2011 8:06 AM, "Mark Diggory" <mdigg...@atmire.com > <mailto:mdigg...@atmire.com>> wrote: > > > > It would make for a better "developer discussion". > > > > On May 5, 2011, at 7:11 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. > > > > I am starting to see how GIT can benefit us in this area. I see two > orthogonal features of GitHub. > > > > a.) Separate Repositories: have have separate Git Repos in the DSpace > Project to manage rights on mirrors what I was trying to attain in > scm.dspace.org <http://scm.dspace.org> modules space, we could start to > consider defining two types of repos "supported" and "experimental" > which would take us a long way towards answering the question of how we > treat modules that dspace is dependent on. > > > > b.) Upstream commit authors are retained: likewise, the commits in > git that get pushed into the repository better capture the contribution > effort of those working on it upstream clones regardless of their commit > rights in the the github master repo. > > > > > 2. Who would decide when a module should be released ? > > > > Those who have a stake-hold in its development and maintenance. > > > > > > > > 3. Who would do the release ? > > > > > > I think this goes to the heart of how we as committers 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 assume you mean the "Product Release", it'd be the same folks who > still do it now. > > > > > > > > Cheers, Robin. > > > > > > Ps. I restricted this to the committers list but if anyone feels it > > > should get a wider audience then I'll repost to dspace-devel. > > > > Please do, its actually not getting to all those stakeholders being > posted here. > > > > Mark > > > > > > ------------------------------------------------------------------------------ > 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
