New release process for 1.8 (READ THIS)

[Alex Deucher]

On Thu, Oct 1, 2009 at 11:26 AM, Daniel Stone <daniel at fooishbar.org> 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 -- 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.
>

Well, my support for it was predicated on xserver being sane and
easily buildable and not before.  So if and when we get to that point,
I'm ok with it.  We'll have to see how the next few releases go.  On
the downside, it will take a lot more time/energy to build/test a new
driver changes.

Alex