On May 5, 2011, at 9:27 AM, Tim Donohue wrote: > 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.
Its hard, because the GiT proposal reduces our dependency on such policies... > > 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?". Commit rights should be given to those that want to work on the module and improve it. It would be good to have a module "lead" that managed dealing with such rights. In either svn or git cases. > 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. I don't really have any questions about this, its relatively clear that gatekeeping cripples participation and we should try to avoid it as to not raise the bar to participation too high. > 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). I'm more for defacto than dejour in this case. The modules workspace allows for non-dspace/trunk commiters to participate in dspace development directly by participating in supporting projects and addons. > 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). We want to attain a build process that allows for addons to exist independently of the release cycle. thats always been the case. > > 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. My concern with the common "assumption" that is made in the commiters group that all code that is part of the release should be in tdspace-trunk has gotten rather antiquated. It is quite difficult to catch changes to code that shouldn't have happened in parts of dspace that should be considered critical/core when the din of commit activity in the trunk gets deafening. The point of modularization is to compartmentalize that "din" so that we can make sure changes shouldn't happen in important parts of DSpace that impact backward compatibility. This said, in modularizing, I'm not suggesting its a "free for all" commit wherever the hell you want. Its actually delegating management of specific portions of the codebase to "expert groups" which anyone can join and participate in. For instance I'm not going to monitor much of anything going on in JSPUI project directly because its are outside the scope on my use/need. This said, if someone comes through with JSPUI development that is going to impact org.dspace.content as well... I do want to know about and act in a peer review role in such cases. It would be best id such changes were compartmentalized under a subproject to ease monitoring... (again, another feature more easily configured in GitHub than in our current svn). > > Just my two cents on this.. :) > > - Tim My 0.233877098 Pesos Mark > 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
