On Mon, 21 Jun 2010 16:04:51 +0300, Tiago Vignatti <[email protected]> wrote:
> Yes, we have significant work happening right now: clean-up. It's a feature as > desirable as any other. I'm not saying there isn't significant and useful work going on, but that we aren't seeing long-term development and testing happening asynchronously from the master branch. As such, master continues to gate exposure of much of the new development work to a wider audience. > 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. Am I still dropping patches on the floor somehow? I've got a bunch of cleanup patches from you and a few from Mikhail sitting here that are awaiting some kind of resolution as to whether they should be merged post-RC1 or not. Aside from that, there are a few bug fixes that I'm merging today at which point I'll do RC2 and post the list of pending patches that haven't been merged yet. > 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? Daniel's point here is that a shorter release cycle will increase the number of releases that we as a community need to maintain as upstream and in distributions. Having to do security updates for one release is hard enough, having to do them simultaneously for many releases would be even harder. > 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. Yes, and pulling from those has been a lot easier than merging patches in by hand, which has been great. The distinction here is that these trees don't get independently tested. This is not to diminish the value of publishing the trees in any way, just that we don't have a huge number of people with time to kill testing random X server trees, unlike, say Linux. > 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. For input stuff, I'm trying to let Peter manage them and send pull requests. When I mess up, he politely informs me to not merge patches that are in his tree as that simply increases his workload. There are other registered maintainers for various subsystems, but that file is hard to find as it lives in the xorg-docs repository instead of the X server and has a lot of stale information. I think we should pull the X server bits out of that and stick them in the xserver doc subdirectory and then try to get that up-to-date. When someone obviously 'takes over' a particular subsystem, we should expect a patch to the MAINTAINERS file along with the code change. Our usual review process can be amended to have reviewers consider the lack of such a change as a reason to reject large patches. -- [email protected]
pgp4f1dHkyycH.pgp
Description: PGP signature
_______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
