Hi all, The more I think about it the less frightened I am becoming. If we could include the safety net of a source release then that would sway it for me.
Cheers, Robin. On Thu, 2011-07-14 at 19:26 +0100, Tim Donohue wrote: > Thanks for doing this Robin! > > I'll add a few more thoughts in here.. > > On 7/14/2011 10:41 AM, Mark Diggory wrote: > > Robin, > > > > Thank you for a great introduction. I'll inject just a few comments inline. > > > > On Thu, Jul 14, 2011 at 2:22 AM, Robin Taylor<[email protected]> wrote: > >> Hi all, > >> > >> A large portion of yesterdays meeting ended up being a discussion on > >> async releases. Mark (Diggory) has for some time been strongly > >> advocating this approach and has written extensively on the subject both > >> on the wiki and in Jira. I think it is incumbent on us all to consider > >> his arguments and comment thereon. So to give him a rest I'll chip in, > >> albeit from a different angle. > > To be honest, the more I think through this in my mind, the more I > really do feel there are some major bonuses to Mark Diggory's ideas. > > Looking back at it now, it may have seemed from yesterday's meeting that > I was arguing against async releases. The reality here is that I > actually agree with MarkD that async releases is a good idea overall. > However, I think there is some disagreement on implementation or > processes to get there. My concerns are more around the processes of > Async Releases. > > I'll admit, some of these concerns were allayed a bit from yesterday's > discussions -- more below. > > >> So why do async releases ? There are a number of reasons, for example... > >> 1. To fix a bug in module dspace-xxx we could just release that module. > >> 2. Or make available new features without waiting for the annual > >> release. > >> 3. Or release entire new modules > >> etc etc. > > Your #1 & #2 reasons are both extremely powerful and also potentially > worrisome if not handled properly. This might sound controversial, but > let me explain... > > First off, I fully agree that #1 and #2 are great things (I'm not > arguing against that at all). I would love to be able to fix bugs more > quickly (via small module releases) and make new features available more > quickly. I full agree that we should think about moving in this direction. > > I think the one concern here is around *management* of all these > individual modules (which unfortunately comes back to the idea of > defining "support"). > > To retain our Community trust, we do need to be careful about how we > define "support" and how we are releasing new bug fixes or features via > async module releases. For instance, we want to make sure that "core" > modules (where "core" just means the main/primary code behind > out-of-the-box DSpace) are still being well vetted & tested before being > released. So, we would need to establish some basic policies/best > practices around how to also vet, test & release new bug fixes > asynchronously (Obviously, this may not require a full testathon, or a > full Release Coordinator role. But we need some basic policies/best > practices on how a bug fix is vetted & tested & asynchronously released). > > We'd also want to make sure DSpace users fully understand who is > "supporting" each individual module. As we move this route, I still feel > that we'll start to enter a situation where some modules are "centrally > supported" (by the Committers as a whole), while others are only > supported by smaller sub-teams or even external, third-parties. I think > this is all a great thing (to have many modules built & supported by > many different groups)! But, users need to be able to know where they > can go for support & documentation, and *which* modules have been > stamped as "Committer Approved, Vetted & Documented", or similar. > > NOTE: I should mention, I'm not saying we need some sort of detailed > approval process for everything (I don't want to bog us down with > red-tape, etc). I'm just saying users need to know which modules are > actually controlled & released by the Committers, and which may be just > a smaller project or experiment that was put up by a sub-team or one > individual or an external group. > > So, to summarize this point: In my opinion, Modularization & > Asynchronous Releases seems like a good thing overall. However, we may > need to rethink some of our vetting, testing & release processes to > ensure that we are still continually putting out well-tested, vetted & > stable code, not only during the main DSpace "packaged" releases, but > also during smaller async module releases. We also need to think about > how we communicate the level of "support" provided for each module (is > support equal for everything, are some modules more well supported than > others?) > > >> Even better, we could distribute the binary > >> release with ranges of version numbers (Maven allows for<version>1.7.1, > >> 1.7.2, etc) and then all they would have to do would be to rebuild and > >> it would automatically pick up the latest version. It is worth noting > >> that this is exactly what we already do for the language packs so this > >> is not new. > > > > I don't really recommend this, it works for language pack because they > > are optional. > > I wouldn't recommend an "automatic" pickup via Maven either. That is > potentially hazardous, as some small change (even a bug fix) could > affect your local customizations/changes. (And if it was an automatic > pick up, you might not have even realized that something has changed) > > But, the general concept here is sound. You would have the *ability* to > pick up the latest version of a newly released module. It just wouldn't > be automatic. You'd have to know there was a new module, and then either > tweak Maven pom.xml or run some script to tweak the pom.xml for you > (which would cause that new module version to be installed the next time > you build DSpace) > > >> > >> So, if you are a fan of the XMLUI and Maven overlays, a binary release > >> might well be sufficient for you. You can of course still check out the > >> code for any module that interests you from the DSpace SVN site. > >> > >> However, if you are a JSPUI user and/or want or need to see the source > >> code in general, then you probably want a source code release. That way > >> you don't have to familiarise yourself with the DSpace SVN site. > > > > Not, this approach works with all webapps, not just XMLUI/aspects. > > Overlays will be a powerful tool even in the new WebMVC and REST > > projects. > > Mark is correct. Overlays are actually a Maven feature and are not > specific to XMLUI in any way. Because we are using Maven, people can > use Overlays for any of the DSpace webapps. > > >> Could we continue to do both a source and binary release as we do at > >> present ? Yes. Many of the modules that currently reside in trunk in SVN > >> would be moved into the modules directory so that they could be released > >> independently of one and other, and the assembly of the source code > >> release would pick up the source code from there rather than from trunk. > > > > Yes, a maven assembly can create something that looks a lot like > > dspace-src-release-x.x.x > > Yes, this is a good thing to be able to continue to release a > dspace-src-release.x.x.x.zip. This is one of my previous concerns that > I had, but yesterdays' discussion helped allay that concern. So, I > don't see this as a concern any more :) > > >> The downside of continuing with a source code release is that it > >> prevents us from unifying behind one approach and being able to make > >> announcements relating to new releases (async or otherwise) that apply > >> to everyone. > > > > No, we can still have an officially sanction release, it would just > > contain separately versioned submodules rather than all residing on > > one version tree. Maven's release plugin will even mediate assuring > > that an aggregated release of all separately managed modules happens > > and a build with complete and compatible release numbers can occur. > > Even if you were using the Source Code Release, you'd still obviously be > using Maven to build it. So, you could *still* tweak your Maven's > pom.xml (or run a script to do so), and install the absolute latest > version of a new asynchronously released Module. > > Technically, we could also probably provide a way for you to pull down > (again via Maven) the latest Source Code for that newly released async > module as well. This would provide a way to somewhat "sync" your local > source code release. Though, admittedly, this could also be a bit > "messy" as we wouldn't be able to merge your local source changes with > any new updates. (But the merging of local changes is not something we > can ever really "solve". We just need to recommend that you are using > tools like SVN, Git, IDEs etc. So, I'm not concerned if this is a manual > merge process) > > >> Personally, I am still in favour of source code releases. I don't see > >> DSpace as a framework on which people build their local customisations, > >> I see it as a complete implementation which people take and do what they > >> want with it. > > > > I'd be curious about the statistics around this last topic, we > > actually recommend dspace as a framework on which people build their > > local customizations. Depending on the degree of complexity of those > > changes, we recommend working within specific "levels" of > > customization of DSpace. > > Unfortunately, I don't think we have any good statistics on whether > people tend to use the "Binary" Release or the Source Code Release. The > closest we can get is the SourceForge download stats (but unfortunately, > SourceForge's download stats have been broken for weeks, so they all > show "0 downloads"). > > I'm just in favor of the source code releases as an *option*. I'm > perfectly fine if we want to highly recommend people use & download the > "binary packaged" release. But, as an open source project, we should > always allow them the option of easily pulling down the entire source > code at once (for whatever reasons they may have). In order to remain > completely transparent, we should just ensure our entire source code is > very easy to obtain. > > > Overall, I do think we are coming closer to an agreement with these > discussions (no matter how heated they may get at points!). I don't > think Mark & I are that far off, in reality. > > I think we just need to approach each of the concerns of Committers > one-by-one and start to move closer to a consensus. So, I'd be very > interested to hear what other concerns may be out there. > > - Tim ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Dspace-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-devel
