All, Just a few comments in agreement with what Graham has mentioned...
On 4/6/2011 3:40 PM, Graham Triggs wrote: > On 1 April 2011 11:08, Mark Diggory <mdigg...@atmire.com > <mailto:mdigg...@atmire.com>> wrote: > > I argued extensively during my redesign of dspace to use maven > in 2006, that many of the individual dspace-xxx modules should have > had their own svn project spaces (trunk/branches/tags) so that they > could have separate releasing, but the group pushed back excessively > on creating more than on trunk at that time. > > > The thing is, we are looking for a genuine benefit to operating in that > way - and so far, personally, I can't see one. Even in the 'simplest' > case of dspace-services, it isn't really taking advantage of separate > releasing - it's basically being released at the same time as the main > release. Except it's more work to have to do separately each time. I'm also unclear of the genuine benefits of releasing 'dspace-services' separately. So far, we have always released dspace-services just before a normal release. So, it does currently add an additional step on to the normal release process. > > I have to be critical that DSpace Services have no reason to be in > the main DSpace trunk. It is a standalone tool with no dependency > on dspace-api, this was how it was designed to be. > > > It is not standalone though. It may not have a dependency on dspace-api, > but it is in itself very distinctly a part of the 'core' of dspace. And > something that everything else does depend - directly or indirectly. It > is that nature of it's relationship to the rest of dspace that marks it > out as something that should be part of trunk - something that gives it > two extremely good reasons to be so: This is the same general concern I had, and why I had suggested moving 'dspace-services' over to Trunk (in my alternative proposal for asynchronous releases). Again, I don't want to confuse two separate proposals here (services and async releases), just pointing out one alternative view where 'dspace-services' could sit in Trunk alongside 'dspace-api': https://wiki.duraspace.org/display/DSPACE/Asynchronous+Release+-+Alternative+Option More importantly, as discussed in yesterday's Developers Meeting, we also seem to be continually seeking full "buy in" from all the Committers on DSpace Services. One way to make Services more visible to everyone (and encourage more to use it) would be to move DSpace Services over to Trunk. Full discussion from yesterday at: http://irclogs.duraspace.org/index.php?date=2011-04-06 I fully understand that 'dspace-services' is not required to be a part of Trunk (as there are no dependencies on dspace-api). But, the pros/cons seem to be: Pros for putting 'dspace-services' in Trunk: -------------------------------------------- (1) More Committer eyes on the dspace-services source code (as it's in your source code checkout by default). Hopefully can help us all get more comfortable with it, and provide feedback to move it forward. (2) Some simplification of current release process (Services would be released/versioned alongside dspace-api) (3) More consistent testing of dspace-services during Testathons, etc. Latest 'dspace-services' code will always be tested/debugged alongside latest 'dspace-api'. In addition, 'dspace-services' could not be released outside of normal DSpace Release processes (i.e. this would require 'dspace-services' to always undergo a Testathon for each release) (4) Makes the full source of DSpace easier to obtain overall (currently our "source releases" don't actually include the full source of DSpace). Makes 'dspace-services' source more easily available to external developers who want to help develop new 'services', or test/debug/patch existing ones. Cons against putting 'dspace-services' in Trunk: ------------------------------------------------ (1) No longer can be asynchronously released separate from dspace-api / DSpace (Note: to date Services has not yet been truly asynchronously released, as it has always been released in conjunction with a new DSpace release) (2) Yet another maven project in Trunk. Already nine other maven projects there (with some additional sub-projects). But, as part of the separate 'async release' idea, we could potentially think about moving other maven projects outside of Trunk, if it makes sense to allow for asynchronous releases of other projects. Do others see additional pros/cons? Or agree/disagree with any of the pros/cons I've listed above? Perhaps if we can enhance this list of the various pros/cons, then it would help us to come to a decision around where 'dspace-services' should sit in SVN, and how it should be released, etc.? > And to be honest, none one should be locally altering the > implementation of the Service Manager codebase in the customization > of your DSpace instance. This doesn't mean other committers in the > group can't alter the code and contribute improvements to it, > everyone is certainly welcome to contribute. Its very serious, you > shouldn't be touching this code if you are just customizing your > local DSpace instance, this is why its source is separate from the > distribution and has separate release cycles. > > > I agree that if you are just customizing a local instance, then there > are parts of the code that should only be modified as a last resort - > that includes various parts of the domain model, not just the service > manager. But that's our role to document and educate - not babysit. It's > far more important that we don't obstruct the review of code, and hold > people back from debugging, fixing, contributing to that code than it is > for us to try to prevent someone making a local modification that they > will find hard to maintain - when they probably won't anyway. +1 I agree that we should discourage people from locally modifying specific areas of DSpace source. But, I agree with Graham, that this is an education/documentation issue. As an open source project, we should give users the ability to modify whatever they want to modify (again, as Graham mentions, doing so can often result in contributions/fixes back to DSpace). But, we definitely should come up with "Best Practices" / "Guidelines" around what areas of DSpace source code we recommend you should avoid changing locally. I also feel that separating "core" parts of DSpace out into separate SVN checkouts just confuses people at times. It does add a small "barrier" to suggest they shouldn't edit these areas. But, that "barrier" also has a cost with it -- the cost being more questions on mailing lists around how to obtain source code of certain areas of DSpace, or why that source code doesn't seem to exist in the official "Source Release" of DSpace. I'd much rather avoid those extra costs, and just post up big "RED FLAGS" warning people not to edit specific "core" parts of DSpace (or warning that if they do edit them, we cannot promise support for such changes on mailing lists, etc.) Again, I'd love to hear what others think here! - Tim ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
