4.6.1 release process proposal
botsie at xfce.org
Fri Jan 16 13:08:46 CET 2009
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
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
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:
> (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.
More information about the Xfce4-dev