New release process for 1.8 (READ THIS)

[Daniel Stone]

On Thu, Oct 01, 2009 at 10:14:23AM +0200, Michel Dänzer wrote:
> On Thu, 2009-10-01 at 11:59 +1000, Dave Airlie wrote: 
> > So I feel locking down master is going to get messy fast, I agree
> > all major developments should be done on branches, but we have many
> > incremental improvements in areas like EXA where we have no fulltime
> > developers working on it and the only real way for it to get tested
> > across drivers is to shove it into master. Also having things in master
> > means you get indirect cross testing, so if I want to add something new
> > I end up having to test all the new stuff other people have merged.
> 
> I share your concerns, though branches in the main repo might be a
> little better than hiding stuff in personal repositories.

We can hook up commit notifications for personal repos, they're there in
cgit, or even (god forbid) someone could actually publish some kind of
status update on their personal repos. :P The only concern I have with
putting them in the primary repo is that it's going to get very messy
very fast, and you don't actually know the full status, because is it
the input branch? Is it daniels-input? Is it
daniels-input-hey-ignore-the-other-one-and-just-merge-this-one? Or was
that from last week? It's reasonably easy inside personal repos -- and
you have a lot more latitude to delete/modify/etc branches -- but I'm
mildly terrified of the explosion that'd cause within the master repo.

The idea is that we get broader testing for master, by being able to
make regular snapshot releases, by being able to point users to it and
having them able to build it consistently and reproducibly, as well as
developers not being scared to run it.  The point at which someone asked
who was actually running master, and my hand was one of the very few in
the room, was pretty troubling.  A few people said 'I never touch master
because it's always broken and difficult to build'.  At the point where
X developers are running away because the build's difficult and the code
broken, we're doing something quite badly wrong IMO.

> > \o/, I got the shit shot out of me for suggesting that last year,
> > wonders whats changed.
> 
> This took me by surprise as well - when/where/how was this decided? I
> didn't have the impression that there was 'broad consensus' for this,
> and I certainly can't say I like the idea.

No-one in the room disagreed.  I don't like the idea as we do it now --
as I said, it's predicated on getting a more sensible master.  As it is
now, nothing will be bisectable ever, because even if the core server
works, will your input work at all? How about modesetting? Rendering?
Doubt it.

However, if we can go through a cycle or two where we actually have a
broadly stable master, then we can think about adding drivers into the
mix; definitely not before.  Also we have to prove that we can do
releases on time, and then the need for separate releases diminishes.

There were a couple of different motivations for this, one was to make
building things a great deal easier (jbarnes was pushing for it quite
strongly and agd5f was in favour -- personally I'd expected the driver
guys to disagree, but apparently even the ones who'd feel it the most
don't).  It's a bit of a shambles at the moment.

The other was to finally fix the horrific abortion we call an API.  Have
you looked at a ScreenInit lately? We've no chance of fixing most of
these unless we pull drivers into the core -- doing it incrementally is
next to impossible, and the insane ifdef city will probably lead to
driver authors just having a flag day anyway.

What're your concerns?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.x.org/archives/xorg-devel/attachments/20091001/242efa4e/attachment.pgp