On Thu, 2009-10-01 at 11:59 +1000, Dave Airlie wrote: > On Wed, 2009-09-30 at 18:35 -0700, Daniel Stone wrote: > > Hi all, > > Following on from Peter's email about the 1.8/7.6 release process[0], we > > had a BoF about the same[1] at XDC. Everyone broadly agreed on the > > substance of Peter's mail, and here are our rough conclusions. > > > > Release process: We're going to aim for a six-month release process, as > > Peter outlined, with 3 months feature freeze, 2 months bugfix, and the > > final month release freeze. We're going to start this for 1.8, and > > hopefully we'll be able to land predictable releases. > > > > 7.6: Either Peter or keithp will be the RM: they can arm-wrestle for it. > > I assume the six-month cycle will start on the day 1.7/7.5 is released > > (hopefully Monday). > > > > Development model: xserver master will be closed to general commits; it > > will be owned by the RM, or one of their delegates. Again, DO NOT > > COMMIT DIRECTLY TO XSERVER MASTER. Everyone should have their own > > xserver trees, and/or one per subsystem (I'll have xserver-xkb and an > > input tree, I guess Peter will have an input tree, there should be an > > EXA tree, etc, etc). When you want to push something to master, either > > send patches to the list, or send a pull request for your tree. ajax > > has quite unwisely volunteered to run a trivial-patch tree, accumulating > > random misc. When you send a pull request or patches, it's expected > > that they've been tested and are working to preserve bisectability, and > > don't destroy ABI every other commit, so feel free to buffer them up a > > bit. Judicious use of rebase -i is not wholly discouraged. I know this > > sounds concerning, but if your merge request just gets forgotten or > > dropped on the floor, bug us until we make it happen. > > 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. > > 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. > > 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. > > 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. 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. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel