New release process for 1.8 (READ THIS)

[Nirbheek Chauhan]

On Thu, Oct 1, 2009 at 7:29 AM, Dave Airlie <airlied at redhat.com> 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.
>

In my humble opinion, Xorg has got an untapped pool of testers waiting
to break their X for testing out various branches. Most of that pool
is untrained right now, but I would expect that in 1-2 releases (with
proper effort), an equilibrium state will be reached with enough
trained/useful testers around.

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

If there's going to be a 3 month merge window for master for new
features, followed by pure bugfix mode, won't that actually be
*better* w.r.t master testing? Fixed 3 months of havoc (instead of an
indefinite time) followed by 2 months for pure bugfix with a guarantee
(well, almost) that no new regressions are going to happen which will
actually bring in *more* people cloning+testing 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.
>

Won't this be handled during the 2 months of bugfixing? Or perhaps 2
months won't be sufficient (atleast for 1-2 releases) ?

-- 
~Nirbheek Chauhan