geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Builds in limbo during voting cycle
Date Sat, 16 Dec 2006 18:35:53 GMT
This is because we have not been diligent in releasing sub projects  
like Genesis, Specs, JavaMail and Geronimo schema.  If we had, then  
then nothing would be in limbo at all.  In the future, I think we  
should have the rule be no SNAPSHOTS to subprojects we control and  
the exception to be SNAPSHOTS.   Not like we currently have it were  
everything under G has a SNAPSHOT dependency.

Basically, this shouldn't happen again.


On Dec 15, 2006, at 5:11 PM, Jason Dillon wrote:

> Why is it that when we go through a voting cycle that builds are  
> left in limbo?
> For example, to build server 1.2 at the moment, users need to also  
> know that they must build genesis 1.1 from its tag, openejb from  
> its tag, and then a handful of specs, from each of their respective  
> tags.  I don't even know which tag is actually needed for each of  
> the damn specs, so I have to go hunt down what version is actually  
> being used, then check out each tag one by one...
> or I have to hack the pom to add the "staged" repos, which is  
> equally worse has to build as tag I have to change its source?!?!   
> and IMO that is just unacceptable.
> I would much rather check out everything that is needed from the  
> tag and build... though that brings me right back to this mess with  
> per-module versioned specs.  Its a nightmare to find the right  
> tags, check them out and build them.  The entire process would be  
> dramatically easier if there was on tag for the specs to be checked  
> out and built... and that is for manual or automated.
> IMO these projects, and their branches should always be buildable,  
> at any time, with out making changes to sources... and we need to  
> be able to setup an automation process to help ensure that they  
> always remain buildable.  It should be possible to setup an  
> automated build for release branches/tags during the voting phase,  
> and even more so, it should be possible to setup the automated  
> system to actually handle cutting that release.
> BUT... to get to that point with the tools which we have decided to  
> use, we need to adhere to a few restrictions which simplify the  
> entire matter... which I don't think that many of you have even  
> thought about.
> maybe the community does not want stable builds?  maybe the  
> community does not want to have durable builds?  maybe the  
> community does not want to have an automated system to ensure build  
> consistency?
> maybe I am just wasting my time?
> --jason

View raw message