Builds in limbo during voting cycle

[Jason Dillon <ja...@planet57.com>]

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

Re: Builds in limbo during voting cycle

[Jason Dillon <ja...@planet57.com>]

No, I believe that there will always be a time when builds are in  
limbo due to reliance on our projects artifacts being deployed to a  
remote repository... when they have not made it there yet.

IMO, the only way to avoid this limbo is to always build components  
from source, removing the remote repository from the equation.

This is also the only way to ensure that when working with SNAPSHOT  
artifacts, that you always use a known set, and don't accidentally  
get a new artifact midway through your build.

--jason


On Dec 16, 2006, at 10:35 AM, Dain Sundstrom wrote:

> 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.
>
> -dain
>
> 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
>

Re: Builds in limbo during voting cycle

[Dain Sundstrom <da...@iq80.com>]

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.

-dain

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