Build stability was Re: [jboss-dev] Why Maven sucks (part 1)

[Adrian Brock]

On Tue, 2008-04-22 at 13:17 +0200, Carlo de Wolf wrote:
> My mistake, we're mixing two issues here:
> - stability of the build
> - reproducibility of the build
> 
> I completely agree that any real release must be reproducible, but is it 
>   feasible to do release for every little nitbit? I say no.
> 
> > People need to stop being lazy and create proper releases.
> > 
> > SNAPSHOTS are only useful when you want to know whether a new release
> > will work another project.
> > 
> > e.g. before I release the next version of jboss-vfs, I create a SNAPSHOT
> > in my *local* repository and update the jbossas build to use it.
> > If it works, I do a proper release (NOT a mvn deploy of the SNAPSHOT)
> > for others to use.
> 
> That's really bad. So if it works on your machine, it's gold? (We know 
> it is, but that's not good enough on my machine. ;-) )
> 
> We must have a stable integration build on a QA machine before we can 
> declare something releasable.
> 

And you do that by producing Candidate Releases.

Who cares whether a snapshot passes 12 hours of tests on a QA machine.
Nobody can reproduce that build within a couple of days (hours???)
so it is worthless. :-)

Now if the process was based on a staging server that checked
commits and releases before doing them I might agree with you.

But with the current infrastructure and workload I doubt
that's going to scale to a project the size of JBoss.

Chances are that trunk would be days/weeks behind development trees.
It would become obsolete and people would just work on 
little shared branches with their teams.
i.e. nobody would be testing or care about trunk

People don't care enough about trunk now (when it is actually used)
judging by all the build breakages. :-)
-- 
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx