4.6.1 release process proposal

[Biju Chacko]

Brian J. Tarricone wrote:
> Botsie!  Long time no see.  You should stop by in #xfce-dev so we can
> heckle you ^_^.

I'm around -- I'm just in lurk mode most of the time.


> On Fri, 16 Jan 2009 09:13:58 +0530 Biju Chacko wrote:
> 
>> I'm wary of doing a release with components built on multiple 
>> environments -- it requires a fair amount of care and discipline to
>> get right.
> 
> No, it really doesn't.  As long as each particular system is capable of
> building a correct package, it doesn't matter if the various module
> tarballs were built on different system.

That's true, my mistake. However, it does make a bigger difference if we 
  want to start releasing binaries -- tarballs, rpm or whatnot.

>> Basically, on every check-in the entire project is rebuilt
> 
> Who's going to provide the hardware for this?  Who's going to host it?
> I really don't think mocha is strong enough to be doing multiple builds
> per day (currently it just does one every night) considering that the
> box does a bunch of other things too.

That's a problem. We could run the CI system in nightly mode until some 
kind soul donates hardware. Or we run only incremental builds on 
check-ins and full builds once a day.

The important part is setting up the automation. The quicker and easier 
we make the release process, the easier it is for any one of us to pick 
up the Release Manager Role. If doing a Release becomes sending out a 
nag mail to maintainers to test their respective modules and then 
pressing a button to upload the tarballs to the website then more of us 
would be willing to do it.

It would be easier to do it more often too.

>> - We would use a canonical environment for all builds. We wouldn't
>> get caught by a maintainer using a newer GTK+, say, than what we've
>> targeted for a particular release.
> 
> Also good.  This isn't so much release-related as
> ongoing-development-related, though.  Sure, we've been bitten by this
> problem in the past, but I wouldn't characterise it as a release
> issue.  It's a "developers need to test-compile against the lowest
> common denominator of dependencies" issue.  Something that's annoying
> and most none of us do... an excellent candidate for automation, as you
> note.

I've drunk the Agile development Kool Aid here in ThoughtWorks, so one 
of my thumb rules is not to differentiate much between 'development' and 
'release'.

In the Ideal World(TM), release is a decision not a process. It's a good 
idea to do every step of your release process as often as possible so 
that you don't get any nasty surprises when you actually do release.

In the real world that isn't always possible, of course.

>> - We'd be able to release nightly builds to make it easier for people
>> to test trunk.
> 
> We already do that:
> http://mocha.xfce.org/downloads/svn-snapshots/xfce/
> (As you can see, it's not perfect; some things fail to build for months
> and nobody notices.  In this case the problem is on the build server,
> not a problem with the packages.)

If you're doing CI then a broken build is an absolute no-no. It's akin 
to walking around with your fly open. Anybody who breaks the build wins 
immediate public humiliation.

While it's always good not to have a broken build, personally I find 
inflicting public humiliation sufficiently entertaining to be enough 
motivation for the practice. What can I say? I'm a sadist. ;-)

>> I've got a fair amount of experience in this area so I could help set 
>> this up.
> 
> Sure, if you're willing to do the work, it sounds like it could be a
> great idea.  What do you need to get started?

A nice build script would be good start. And if someone could reset my 
password on mocha, that would help.

-- b