4.6.1 release process proposal

[Brian J. Tarricone]

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

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

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 
discussion:
http://mocha.xfce.org/~kelnos/xfce4/xfce4-snapshots.pl.txt

> 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?

	-b