Hi, On Sun, Jun 20, 2010 at 02:02:34AM +0200, ext Keith Packard wrote: > > Running a shorter release schedule would be fine with me, but as we > don't have any significant work happening in other trees
Yes, we have significant work happening right now: clean-up. It's a feature as desirable as any other. > On Sat, 19 Jun 2010 15:22:50 -0700, Jamey Sharp <[email protected]> wrote: > > Perhaps we need an xserver-next tree AFAIK -next tree intents to solve integration issues. On kernel land they have a lot of submaintainers and each time one sends a pull request, such pull collides with another one because the code changes conflict. So the idea is to very often (daily?) collect patches from submaintainers' trees and create builds. All this happens in automatically fashion and they target integration problems. I'm afraid integration and collision of patches are not our main problem now. The problem is that people are creating patches but they got lost somewhere and/or take so many time to go upstream. In my opinion, reducing the release schedule now would improve the throughput of patches going in. Probably three months for the whole release would be better with the majority of time being gates opened for merge window - two months maybe? > If not, I wonder if we > couldn't have either a separate tree or just a separate branch where > people were pushing these kinds of changes by themselves, at least > they'd be all ready to merge once 1.9 ships. that's pretty much what was happening recently: I've been carrying a tree with PCI clean ups, Mikhail with huge janitor clean-ups, Jamey re-working screen structures and etc. I don't think one special tree collecting all patches is really needed. But I think we should decide, i.e. nominate, who maintains a module, piece of code or feature. So for instance if one send a patch for xkb then he/she would expect that, say, either daniels or whot would apply in a few days. Can be both caring similar trees, but only one would be the main responsible. The RM would have to get a confidence with his submaintainers and expect that they deliver their trees doing often PULL requests when the merge window is opened. Cheers, Tiago _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
