Looks like the 1.9 server release has gone off fairly well, and I think the few changes we made in the process helped quite a bit, in particular, having a release tracking bug made it easy to find things that people wanted fixed, and several of them actually did get fixed, including some ancient ones (like bug 3040).
Are there other things we can do to help improve the 1.10 release? Merging Drivers: I'm also still interested to hear how we can de-modularize the system to some extent where it would be useful. Merging the protocol headers into a single package would be a good step, but it would require someone to step up and offer to take charge of doing release management for the whole thing. I think Peter Hutterer is almost convinced that bringing the input drivers into the server would help let us fix the API/ABI issues in that interface faster. Video drivers seem a bit harder, they're much larger, of course, and we'd really need a dedicated 'subsystem maintainer' to make that work inside the server. For drivers using KMS, I think moving them into the core server would let us refactor them to eliminate the duplicate mode setting code. Anyone want to volunteer to have "their" driver get merged into the server for 1.10? Release Schedule: While most of the 1.9 cycle seemed to work fine from my perspective, it seemed like it dragged a bit at the end. There were only 10 patches in the last week before release. However, all of the core patches in that last week were well reviewed, and fixed obvious regressions or crashes. I asked about changing the length of the release cycle last time and it seemed to me that the general consensus was that we should leave it at 6 months, at least for now. I'm OK with that; we don't have so many changes coming into the server than a 3 month cycle seems required. If we start integrating video drivers into the server, we may want to reconsider to make sure we can get support for new hardware out in a timely fashion. So, if we're leaving things the same for this release, I think that makes the schedule look something like: Merge window closes: 2010-12-1 Non-critical bug deadline: 2011-02-1 1.10 Release: 2011-02-18 External Repositories: Yes. Please. If you're doing work on the X server and want to share that among multiple developers, please publish a git repository containing your changes. There's absolutely no reason to gate work on a single repository branch. Patch Merging Process: Here's a copy of the text posted with the 1.9 schedule. 1) Post all proposed patches to [email protected]. All patches must have Signed-off-By: lines attached. I think every patch should be posted and not just a link to a git repository (except in the case of huge white-space or other automated changes). I do patch review off-line, having things in my inbox makes that really easy. 2) Review as many patches as you can stand. Even if you don't know the area that the code touches, please feel free to post comments about style, grammar and the patch description. A 'Reviewed-by:' line doesn't have to say 'I know this code will work', only that you think that the patch is ready for merging. 3) Test patches that change stuff you care about. If there's a piece of code that touches something that you know about or use regularly, please give it a try and see what it does. If things appear to work as advertised, please reply with a 'Tested-by:' line. 4) Ack patches that you think are necessary. An 'Acked-by:' line should signify that the patch purports to do something that you think is necessary or useful, but that you haven't reviewed in depth or tested it. I'd like to encourage people who see an Acked-by line to consider reviewing and testing the associated patch; all things being equal, patches that lots of people want should probably be higher priority than other patches. 4) Patches that are both ready for merging and which conform to the release schedule policy should get updated with all Reviewed-by:, Acked-by:, Tested-by: and Signed-off-by: lines inserted and then sent back to [email protected] and Cc:'d to the release manager (that's me for 1.9). You can either send them as patches to the list, or as pull requests. Patches should contain the word 'PATCH' in the subject while pull requests should contain the word 'PULL'. Here's some Do's and Don't's: 1) Do post patches as soon as you think they're ready for review. They do not have to be 'finished'. The earlier you post big changes, the sooner we can get agreement on how such things should be done. Send them as patches, not pull requests so that we can see the code without needing to pull from your git repository. 2) Do not Cc: the release manager with patches that have not been posted to the list before, or patches which haven't seen sufficient review. 3) Review, test and acknowledge patches early and often. The more people we get looking at the code, the better things go. 4) Review all aspects of a patch, from the coding style to the grammar in the comments. Be constructive and remember that many (most?) of the people in our development community are not native English users. Thanks again for everyone's work on the X server, and keep on coding. -- [email protected]
pgpVWtk0C22f7.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
