4.6.1 release process proposal
Brian J. Tarricone
bjt23 at cornell.edu
Fri Jan 16 20:27:53 CET 2009
Biju Chacko wrote:
> Brian J. Tarricone wrote:
>> 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.
I'm not sure that we do want to. IMO distributing binaries on Linux is
a waste unless you're targeting specific versions of specific distros.
And for that, you usually need a machine running that version of that
distro. For a large project with lots of infra resources, that might
make sense, but not really for us, I don't think.
>>> 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.
Yeah, you're probably right. If someone sees that we're working on a
nice automation system, they might even offer to donate some hardware.
Or if we were to ask for this hardware, it's a lot easier to justify it
by saying "hey, we have this build automation, but currently it sucks
because we only have one machine to run it on, and that machine is
bogged down with other tasks already."
> 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.
That's a nice way of thinking about it, I suppose. The problem with
processes that aren't executed often is that, as the conditions around
the process change, you can't be sure the process will always work properly.
>>> - 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.
No no no, you're misunderstanding. The build is broken because the
build server is broken and the automation isn't robust, not because
someone checked in broken code.
>>> 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.
Well, I have a build script. Whether or not it's "nice" can be up for
> And if someone could reset my password on mocha, that would help.
Well, you actually don't have a shell account, just a https account.
Auke, can you promote botsie's https account to ssh?
More information about the Xfce4-dev