On Thu, Oct 1, 2009 at 7:29 AM, Dave Airlie <airl...@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 _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel