Apologies for starting this up again but... Whilst I tend towards being in favour of Mark's proposal, I think there is still a lot og grey areas so its important to keep the discussion going.
Picking up on a couple of Peter's points... > Adding a new module to DSpace is as easy as editing a > pom. https://github.com/DSpace/DSpace/blob/master/dspace/pom.xml#L502 > I should be able to just simply edit that and add an entry for the > REST API, or for WebMVC and when the project gets rebuilt, it has a > new module attached. > Whilst editing a pom is an option for developers who are familiar with the DSpace Maven infrastructure I think we need to come up something much more user friendly. In the UK at least most sites do not have a dedicated repo developer. I also suspect most sites take the code from the downloadable zip and never go near SVN. There is already a Jira issue from the DCAT group asking for an install process that doesn't require the installer to get involved with Maven and Ant. I think we risk alienating a section of the community if we don't provide an easy mechanism to add modules and/or find the source code. This is not an insurmountable problem, we just need to figure out some good solutions. I'm looking forward to seeing Tim's Installer, it might spark off some good discussions. > > Project Restructuring > There is a minimum necessary amount of project rearrangement needed > for this pick-and-choose modularization mechanism to work smoothly. > Mainly the current [dspace-source]/dspace directory has to be off on > its own in the code repository. It shouldn't have a parent pom, and > dspace-jspui, dspace-xmlui, etc shouldn't be its "neighbors". JSPUI, > and XMLUI should become pluggable modules that one enables to have as > the web interface to their DSpace repository. > But we do need a to agree on an easily understandable, consistent approach. Should nothing other than the core 'dspace' module be included in the first instance and everything else be optional ? I think Mark still envisages 'stats' and 'discovery' being referenced as Maven modules, just that the source code would live outside in the modules directory in order to enable async releases. How would that be possible if the XMLUI was not included by default ? Would we follow that approach for all the other modules so that we effectively have a binary release that includes all modules but only source code for core dspace ? Is that practical ? We may have conflicting modules. Cheers, Robin. > > On Thu, May 5, 2011 at 5:48 PM, Tim Donohue <tdono...@duraspace.org> > wrote: > Mark, > > I feel like you and I may actually be coming at this from two > different > directions. But I'm not sure, primarily because I'm not sure I > fully > understand some of your ideas (see below for more) > > On 5/5/2011 3:43 PM, Mark Diggory wrote: > > >> 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. > > > This is something I see as a "committer policy" issue, and > something we > have never actually discussed as a group. Should Commit rights > be given > to anyone who wants to work on any module (including 'core' > ones) to > improve it? Should we only assign one "lead" for each Module, > or should > every 'core' module fall under "Committer Team" control? > > These are honest questions. The Committers as a whole have > never > discussed these sorts of policy changes. Obviously, we *don't* > allow > anyone who wants to work on XMLUI or JSPUI (as examples) to > just start > committing code. These policies can always be changed, but we > need to > discuss these changes before jumping to conclusions. > > >> 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. > > > I'm all for changing some of the 'gatekeeping' to make it > easier for > participation. But, we do have to realize one of the main > purposes of > "gatekeeping" is to ensure that each DSpace release is well > vetted, > tested and approved by a "trusted" group. This is what our > community of > 1000+ institutions expects from the Committers Group -- we are > here to > ensure we are providing a consistently stable, well vetted & > useful product. > > We can definitely change where the "gatekeeping" occurs, but I > think > there will always need to be some gates in place in order to > properly > 'vet' the "trustworthy" modules from the "not-so-trustworthy" > ones (or > the ones that may be highly unstable). We also need to ensure > the final > "packaged" DSpace product is vetted & well tested itself, so > there are > additional "gates" that still need to be in place to ensure > unstable or > unapproved code isn't in that "packaged" release. > > > > >> 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. > > > But, the reality here is that we have several Committers who > are > actively *questioning* whether the "modules workspace" is also > causing > some core source code to be "invisible" (or at least harder to > find). > > So, I don't know that I agree the "modules workspace" is truly > a > 'defacto' standard -- it's more like a few people have gone > that route, > and there's a few others who now are popping up with concerns > that > haven't been answered. > > I will state that I *completely* agree that we should have an > "open > development workspace" for anyone (committers or > non-committers) to > create their own Maven projects & DSpace plugins. But, I think > that is > *NOT* the same as what the "modules workspace" currently is. > The > "modules workspace" is currently an unfortunate jumble of > "stable, > controlled" modules, unstable/experimental modules, > third-party > developed modules, and outdated/obsolete modules. > > I admit, I'm still hazy on whether you are suggesting that we > should > remove the Committer boundaries/gatekeeping on *all* Maven > projects, or > just on a sub-set of those projects. Obviously, there's a big > difference there. So, I'd be curious to hear which > "boundaries" you > would see as remaining, and which would "go away" based on > your suggestions. > > >> 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 we found out yesterday that several people are not > sure if we > actually want that. We had several "undecided" votes (more > 'undecided' > than 'decided' votes in fact). > > So, I think we need to take a step back and actually reanalyze > what we > mean by "we want a build process that allows for addons to > exist > independently of the release cycle". I don't think we all have > the same > understanding of what that statement means. > > > 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). > > > So, who would form these "expert groups" you are talking > about? Are you > suggesting splitting up the Committers into subgroups? Are you > suggesting that any developer can join any "expert group" if > they are > interested in helping to develop on that module? > > Mark, I think your last paragraph here gets to the heart of my > confusion > around your idea. I don't quite understand your suggestions > around > "expert groups" (instead, I had thought you were in fact > suggesting a > near "free for all"). How would one get "chosen" for these > "expert > groups"? I'm also not sure where the "Committers" fit into all > this (are > we the "overseeing" group? are we just here to package up > releases? are > we essentially "split up" and we all join the "expert groups" > we are > most interested in?). > > Definitely interested in better understanding your suggestions > here. > > Thanks, > > - 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 > > > ------------------------------------------------------------------------------ Achieve unprecedented app performance and reliability What every C/C++ and Fortran developer should know. Learn how Intel has extended the reach of its next-generation tools to help boost performance applications - inlcuding clusters. http://p.sf.net/sfu/intel-dev2devmay _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
