New release process for 1.8 (READ THIS)

[Daniel Stone]

Hi,

On Thu, Oct 01, 2009 at 11:59:05AM +1000, Dave Airlie wrote:
> My main issue with this is, while we'd like to be the kernel, we have in
> no way got the developer/testers bandwidth they have. Generally when
> developing a feature for the kernel, you can find someone else to
> interact with while you write the code and bounce it around to get the
> bugs out, etc.

Indeed.

> With X generally requests for testing things no on master and not
> directly affecting another developer at that point go unnoticed, the
> only way stuff really gets tested in X is indirectly, by people cloning
> master and running it, its unfortunate but I don't think its due to our
> process but lack of bandwidth.

Yeah, certainly we lack badly for developers, and a lot of the XDC
discussion was on how to make the codebase more approachable so we can
get more testers, casual contributors, and full-on developers involved.
We've got a long way to go.

One of the suggestions was to get people more involved; if you see a
review go past, just dive in and review it anyway.  If you can't review
it because of a lack of context, go back and ask them to document the
relevant area.

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

Sure, but in reality, very few people end up actually regularly running
master, just because of the breakage.  Even if it ends up going really
wrong, we end up blindly merging branches we can't really test, and we
at least get some modicum of review, with some additional amount of lag
between commit and master.

> The other thing is we need to stop being afraid of git revert I think
> judicious use of revert could resolve a lot of our problems (read:
> _X_EXPORT). We also get to keep history of why we hated something.

Heh, sure. :)

> > Future: Around 1.10, we'd like to merge the drivers back into the core
> > so we can start getting a coherent API (well, any API would be a start).
> > We're also working on a much better testing model, with functional
> > testing as well as XTS, so we can exercise modesetting, input
> > functionality, real-world rendering, etc.
> 
> \o/, I got the shit shot out of me for suggesting that last year,
> wonders whats changed.

We had broad agreement that we wanted to merge the drivers in, but if
all development is being done directly in master ... what are the odds
of having the core server, rendering, input, modesetting, and your
particular driver actually working?

So, at least from my point of view, locking master off is basically the
only thing that actually makes it possible to merge the drivers.

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/20090930/306d82dc/attachment.pgp