New release process for 1.8 (READ THIS)

[Michel Dänzer]

On Thu, 2009-10-01 at 08:26 -0700, Daniel Stone wrote: 
> 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 --

Maybe in theory, but in practice the personal repos I've seen don't seem
to confirm this. The higher visibility of the main repo might even
encourage better discipline.

> but I'm mildly terrified of the explosion that'd cause within the
> master repo.

Maybe restrict branches in the main repo to one (or at most a few) per
subsystem and release branch.


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

I would have been another one, FWIW.

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

Indeed. The main problem from my POV is developers' lack of
responsibility for their changes. As Dave mentioned, git revert is a
possible tool for that - if a developer doesn't fix a screwup promptly,
the master branch meister can just revert it. Making even subsystem
maintainers do the patch submission dance every time seems like an
unnecessary increase in workload both for them and the master branch
meister, which seems like an odd response to lack of manpower.


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

So decisions like this are made by whoever happens to be present at a
conference?


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

I've done it a couple of times, it can be tricky but certainly not
impossible.

> There were a couple of different motivations for this, one was to make
> building things a great deal easier

Would it really? IME complications have mostly been due to things like
protos, not directly between xserver and drivers.


> What're your concerns?

First of all, surely the onus is on those who want to move the drivers
into the xserver tree to present convincing arguments in support of it.

That said, e.g., what will happen with drivers which can't or don't want
to be in the xserver tree? Like GPL input drivers, or the Gallium Xorg
state tracker, which really wants to live in the Gallium tree at least
for the time being. It seems like they would become second class
citizens in the best case.


Anyway, this seems like a done deal, so I won't spend much more energy
on it.


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer