Re: X server 1.9 release thoughts
On Sun, 2010-04-11 at 18:49 -0700, Keith Packard wrote: On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer mic...@daenzer.net wrote: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. This is good feedback, thanks. Can you point out specific cases and we can figure out what went wrong? [...] You're dodging the fundamental issues and deflecting to details. I don't have the time or patience for these games. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, Apr 6, 2010 at 09:30:47 -0700, Keith Packard wrote: First off, I'd like to get a start on making things easier to build for people interested in testing the server or new drivers. I'm still interested in getting drivers pulled back into the server itself at some point, but it seems like an important and trivial first step will be to merge all of the protocol headers into one package. I'll get started on that and post a pointer to a merged repository for review. So the way I see it, this is a bunch of busy work with 0 benefit. What is this supposed to help with? Most protos you can get from your distro, and if you want to build everything from git there are scripts around which make building 10 or 20 protos not harder than building one. On Tue, Apr 6, 2010 at 15:18:24 -0700, Keith Packard wrote: On Tue, 06 Apr 2010 14:43:01 -0700, Jeremy Huddleston jerem...@freedesktop.org wrote: I think a 3-month major-release cycle will be very taxing, especially considering the increased codebase with drivers. We're doing 3 month releases with the intel drivers today; it's working out pretty well as I think we're more responsive to regressions and other bugs than we used to be. Really? I haven't had that impression at all since you started this let's release the intel driver every 3 months thing. Today, I can get the radeon bugfixes, and try to leave out the latest intel regressions, with no extra work. If they're both in the same repo, that gets much harder. Cheers, Julien signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Sun, 11 Apr 2010 18:49:56 -0700 Keith Packard kei...@keithp.com wrote: On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer mic...@daenzer.net wrote: This seems inconsistent with the usage of this tag in the Linux kernel development process. If we're going to continue shoehorning our project into that process, we should avoid such inconsistencies, or it'll be even worse than merely imposing a process from a different project without serious consideration of the goals and properties of that process and whether those are desirable for our project. Sorry, I didn't mean to make it inconsistent; can you explain what you think the Acked-by line means? The Acked-by lines are only as relevant as the one who give's them out. If you have a Patch that touches the input-subsystem, and you are not the input-subsystem-maintainer but want to take the patch because some work of your's depends on it or something other, then you have to get the Acked-by line of that maintainer. So everybody is free to give out Acked-By lines... but they only make sense, when the patch in question touches someone else's code and you bypass that maintainer because of logistical reasons. Cheers, Flo ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, 2010-04-06 at 09:30 -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. I still think restricting write access to xserver master to a single person has been a mistake, choking existing momentum without generating new momentum, or making master broken less of the time — rather the opposite: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. Restricting write access to a single person makes a lot of sense for the stable branches (in fact it should have been done for those much earlier), but we cannot afford the overhead for master. Note that I'm not suggesting everybody should get unconditional write access. E.g. people not taking responsibility for changes they push — fixing up or reverting broken changes in due time — obviously shouldn't. Even restricting write access of most people to certain subtrees would be a step forward. One thing that's sorely needed again is a blocker/tracker bug at least for the x.y.0 release. It's been my impression that 1.8.0 was released with a few bugs that should have been fixed or at least seriously considered before, but apparently nobody really had an overview of the situation. In the run-up to 1.7.0 and earlier releases, I would regularly go through the list of blocker bugs and try and fix some of them. (The motivation for that would have been lower now due to the new process costing excessive time and effort to get in simple fixes, but it would have been better) 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. This seems inconsistent with the usage of this tag in the Linux kernel development process. If we're going to continue shoehorning our project into that process, we should avoid such inconsistencies, or it'll be even worse than merely imposing a process from a different project without serious consideration of the goals and properties of that process and whether those are desirable for our project. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
2010/4/12 Michel Dänzer mic...@daenzer.net: On Tue, 2010-04-06 at 09:30 -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. I still think restricting write access to xserver master to a single person has been a mistake, choking existing momentum without generating new momentum, or making master broken less of the time — rather the opposite: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. I'd have to agree here, I think we need to do 1.9 following the same process again and refine it a lot more. Keith there were large stages during the 1.8 process where master was broken and you weren't tasked to fixing it, and people were relying on stuff from the list or other peoples branches. This doesn't seem like the way forward, and I suspect if you want to take responsibility for the tree you need to appoint someone else to push build and correctness fixes while you are unavailable. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
2010/4/11 Michel Dänzer mic...@daenzer.net: On Tue, 2010-04-06 at 09:30 -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. I still think restricting write access to xserver master to a single person has been a mistake, choking existing momentum without generating new momentum, or making master broken less of the time — rather the opposite: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. I agree here - it has been adding extra administrative overhead for everyone at the detriment of quality. If we want to merge even _more_ code into the server (i.e. drivers), things are not going to get better. Stephane ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer mic...@daenzer.net wrote: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. This is good feedback, thanks. Can you point out specific cases and we can figure out what went wrong? There are a couple possible sources of failure that I can think of: 1) The release manager disappears for a few days. Ideally, they'd be available 24x7, but in reality, that's not going to happen. Business trips, and even an occasional vacation can halt stuff heading into master. 2) The patches to fix a bug aren't ready. Either the proposed fix for a regression doesn't make everyone happy, or the patch just isn't getting any review. In the first case, I think it's probably a good idea to simply have a back-up person who can push stuff to master while the release manager is afk. Would Peter (our 1.8 stable maintainer) be willing to do this? My thinking here is that often the most critical patches are those which also need to be added to the stable tree. In the second case, it might be that the best plan is to simply revert whatever code was added which causes the bug until the whole sequence is fixed. If caught early, this shouldn't be hugely disruptive. We could even adopt a policy that lets more people revert patches -- something as simple as allowing a subsystem maintainer, or even the original patch author, to get code back out of the server might reduce the window of brokenness. I'd also like to continue to encourage subsystem maintainers to publish a tree with their current patches. When they're ready, just ask me to pull them in instead of pulling patches off the mailing list. You can publish a tree anywhere you like, including people.freedesktop.org. For anything more than a handful of patches, this seems more reliable to me. Of course, this is just for patches which are ready to be merged; patches under discussion should hit the mailing list. Peter has been doing this for input and I think it's worked fairly well. One thing that's sorely needed again is a blocker/tracker bug at least for the x.y.0 release. It's been my impression that 1.8.0 was released with a few bugs that should have been fixed or at least seriously considered before, but apparently nobody really had an overview of the situation. In the run-up to 1.7.0 and earlier releases, I would regularly go through the list of blocker bugs and try and fix some of them. (The motivation for that would have been lower now due to the new process costing excessive time and effort to get in simple fixes, but it would have been better) Yes. I felt a bit at sea in the last week or so running up to the release; there really wasn't any sense of what needed to be done. I've always liked the tracking bug plan in the past. Bug 27592. The big commitment that I'd like to see us make is to avoid regressions From the previous release, so any tracking bug should have a big warning label on bugs which are regressions. Bugs which aren't regressions would be significantly lower in priority and would have to be pretty bad to block a release. This seems inconsistent with the usage of this tag in the Linux kernel development process. If we're going to continue shoehorning our project into that process, we should avoid such inconsistencies, or it'll be even worse than merely imposing a process from a different project without serious consideration of the goals and properties of that process and whether those are desirable for our project. Sorry, I didn't mean to make it inconsistent; can you explain what you think the Acked-by line means? -- keith.pack...@intel.com pgpui6sN8cv2Z.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Mon, 12 Apr 2010 07:02:27 +1000, Dave Airlie airl...@gmail.com wrote: I'd have to agree here, I think we need to do 1.9 following the same process again and refine it a lot more. Yeah, developing the release process is almost as hard as developing the code. Keith there were large stages during the 1.8 process where master was broken and you weren't tasked to fixing it, and people were relying on stuff from the list or other peoples branches. Would it be better to just pull broken stuff out of master at these times? There are big portions of the server that I can't frankly test or fix, like exa, as I have no hardware which uses that code. This doesn't seem like the way forward, and I suspect if you want to take responsibility for the tree you need to appoint someone else to push build and correctness fixes while you are unavailable. Yeah, if the goal is to keep master usable by people all of the time, then we need a fallback plan for cases when it just doesn't build. Having it possible for someone else to fix the build seems essential. Would more frequent RC releases help? Some people don't want 'master', they just want something 'new'. I wasn't happy with the frequency of RC releases during 1.8; they're not hard to do and I don't think they need to be anything more than 'what's up this week'. -- keith.pack...@intel.com pgpNG7c8sR2Li.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Sun, Apr 11, 2010 at 06:49:56PM -0700, Keith Packard wrote: On Sun, 11 Apr 2010 18:14:33 +0200, Michel Dänzer mic...@daenzer.net wrote: There were a number of cases where breakage wasn't fixed for days because nobody else was allowed to push the fixes. This is good feedback, thanks. Can you point out specific cases and we can figure out what went wrong? there was at least one case where master was broken for a week or more although the patches were sitting reviewed on the list (and I even sent a pull request). and IIRC in that case a 1.7 release was relying on those fixes too. There are a couple possible sources of failure that I can think of: 1) The release manager disappears for a few days. Ideally, they'd be available 24x7, but in reality, that's not going to happen. Business trips, and even an occasional vacation can halt stuff heading into master. 2) The patches to fix a bug aren't ready. Either the proposed fix for a regression doesn't make everyone happy, or the patch just isn't getting any review. In the first case, I think it's probably a good idea to simply have a back-up person who can push stuff to master while the release manager is afk. Would Peter (our 1.8 stable maintainer) be willing to do this? My thinking here is that often the most critical patches are those which also need to be added to the stable tree. I really wouldn't mind if someone else can pick this up, mainly to get an extra pair of eyes to it. Also, ETIME and whatnot. In the second case, it might be that the best plan is to simply revert whatever code was added which causes the bug until the whole sequence is fixed. If caught early, this shouldn't be hugely disruptive. We could even adopt a policy that lets more people revert patches -- something as simple as allowing a subsystem maintainer, or even the original patch author, to get code back out of the server might reduce the window of brokenness. fully agree. I'd also like to continue to encourage subsystem maintainers to publish a tree with their current patches. When they're ready, just ask me to pull them in instead of pulling patches off the mailing list. You can publish a tree anywhere you like, including people.freedesktop.org. For anything more than a handful of patches, this seems more reliable to me. Of course, this is just for patches which are ready to be merged; patches under discussion should hit the mailing list. Peter has been doing this for input and I think it's worked fairly well. yes, with a few exceptions where I pinged you to speed things up a bit, I'm quite happy with how things went. The few problems we ran into over the cycle have been pretty much addressed now. - both picking up a given patch, mostly meh, git handles this nicely. - delays in pulls, this is largely fine now though sometimes it's annoying since the 1.7/1.8 policy requires that fixes be in master first. so what often happens is that I cherry-pick too soon from master, rather than letting it sit there first for a few days to maturee. - partial pulls (at least once you just cherry-picked some patches from my tree instead of refusing the whole lot). I think you stopped doing that, that was my biggest gripe. Juggling the branches is sometimes tedious but generally I can recommend to send pull requests over patches. for me, it means I'm in charge of the patches until I push them to my repo and I don't have to check if you missed one or not, etc. not all is perfect, but for me this cycle was working better than the 1.6-1.7 cycle and master was generally in a testable state. Cheers, Peter One thing that's sorely needed again is a blocker/tracker bug at least for the x.y.0 release. It's been my impression that 1.8.0 was released with a few bugs that should have been fixed or at least seriously considered before, but apparently nobody really had an overview of the situation. In the run-up to 1.7.0 and earlier releases, I would regularly go through the list of blocker bugs and try and fix some of them. (The motivation for that would have been lower now due to the new process costing excessive time and effort to get in simple fixes, but it would have been better) Yes. I felt a bit at sea in the last week or so running up to the release; there really wasn't any sense of what needed to be done. I've always liked the tracking bug plan in the past. Bug 27592. The big commitment that I'd like to see us make is to avoid regressions From the previous release, so any tracking bug should have a big warning label on bugs which are regressions. Bugs which aren't regressions would be significantly lower in priority and would have to be pretty bad to block a release. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
2010/4/11 Keith Packard kei...@keithp.com: On Mon, 12 Apr 2010 07:02:27 +1000, Dave Airlie airl...@gmail.com wrote: I'd have to agree here, I think we need to do 1.9 following the same process again and refine it a lot more. Yeah, developing the release process is almost as hard as developing the code. The release process, although not on regular schedule, used to work fine. Right now it seems you are developing something similar to the old XFree86 days... Keith there were large stages during the 1.8 process where master was broken and you weren't tasked to fixing it, and people were relying on stuff from the list or other peoples branches. Would it be better to just pull broken stuff out of master at these times? There are big portions of the server that I can't frankly test or fix, like exa, as I have no hardware which uses that code. Yes that is the point exactly, for example with EXA and likewise for drivers this schemes provides no advantage at all, and there is no way a single person can be relevant for code review/merge for the whole server. Stephane ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 20:50:28 -0700 Stephane Marchesin stephane.marche...@gmail.com wrote: On Wed, Apr 7, 2010 at 20:44, Daniel Stone dan...@fooishbar.org wrote: On Wed, Apr 07, 2010 at 05:02:20PM -0700, Jesse Barnes wrote: On the flip side, unless we have a decent set of video and input drivers included in the server, building and testing a new one will always be a bit painful. Sure, but on the flip-flip side, and it's hard to say this without slighting anyone here, but will the drivers actually be stable enough to ensure that? If I fix a bug in evdev and ask someone to go test current xserver master, hopefully they're not going to come back and say 'I've got an 855 so my display doesn't work, do you have a patch against an older server?'. To be honest, I'm not sure our regression testing is yet good enough for this. Indeed, it seems to me that video drivers are different enough that they can be kept separate for now. Also note that the EXA and Randr have stabilized (those were the most intrusive changes recently), and most of the interface changes are done now. Merging would bring little gain then. I think video drivers have settled down a bit too actually. With most of the mode setting logic in the kernel the DDX video drivers are pretty small, and the intel one at least has seen much less churn lately. Of course, that argument cuts both ways. E.g. if the video drivers aren't changing much, what API/ABIs are we hoping to make easier to change? For me the most recent was DRI2. We already have a bunch of ugly conditional code in our driver to handle various versions of the server DRI2 interface we could get rid of with an integrated package. It would also be easier to factor out common KMS code from the drivers into the server. -- Jesse Barnes, Intel Open Source Technology Center ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
Alex Deucher wrote: On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net wrote: It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. I agree with this sentiment for video drivers right now as well. From the distro builder point of view, when a new graphics chipset is released, I'm much more likely to take an individual driver update back to a LTS/enterprise support branch than take an entire new X server version back, especially if that requires protocol updates that might also trigger client library updates. (At least that's my point of view for Solaris 10 - I can't claim to have polled the people responsible for RHEL, SLED, Ubuntu LTS or any other enterprise release, but would be interested to see their thoughts.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Fri, Apr 9, 2010 at 4:24 AM, Alan Coopersmith alan.coopersm...@oracle.com wrote: Alex Deucher wrote: On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net wrote: It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. I agree with this sentiment for video drivers right now as well. From the distro builder point of view, when a new graphics chipset is released, I'm much more likely to take an individual driver update back to a LTS/enterprise support branch than take an entire new X server version back, especially if that requires protocol updates that might also trigger client library updates. (At least that's my point of view for Solaris 10 - I can't claim to have polled the people responsible for RHEL, SLED, Ubuntu LTS or any other enterprise release, but would be interested to see their thoughts.) I've found this mostly to be a false economy, as unless you do a lot of QA, you are essentially running an untested combo. I know for -ati every backport requires revalidating as e.g. RHEL5 has no useful exa in the server, so suddenly you are using XAA/shadowfb codepaths nobody has tested. We ended up backporting all of xrandr core in our server instead of each driver. Dave. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. Ok, so now for the details about the 1.9 release itself. First off, I'd like to get a start on making things easier to build for people interested in testing the server or new drivers. I'm still interested in getting drivers pulled back into the server itself at some point, but it seems like an important and trivial first step will be to merge all of the protocol headers into one package. I'll get started on that and post a pointer to a merged repository for review. I'm just replying here so we've got my opinion public and archived rather than spread across several IRC conversations. From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. Right now, the drivers that matter build against several X server versions and I get testing of e.g. evdev master against older servers, finding evdev-specific bugs during the development cycle. This is mostly due to the input drivers being much simpler and easier to install than video drivers, they have virtually no dependencies. The work needed to support multiple server versions is mostly negligible. To get the same exposure of testing once the drivers are merged into master requires a lot of cherry-picking on my behalf. Even then, we'd still need users to install the server + dependencies to test a new evdev patch, something which at this point would likely be a deterrent. So at this point, merging drivers in would increase my workload and reduce testing exposure. That's why I'm reluctant for evdev and synaptics to be merged, even though the no API/ABI is tempting. The drivers just don't move enough to make it worthwhile just yet. We'll see how Benjamin's multitouch efforts will affect that. Beyond that, one requirement that I see for merging output drivers would be to shorten the X server release from the current 6 months down to 3 months or so. Otherwise I feel that the window of time between hardware release and driver release could become too long. I'm up for this cadence, but it would mean that we'd need to see major patches posted and reviewed in the previous release cycle so that they could be applied shortly after a release. I don't want to shorten the RC schedule by much. If ABI/API churn is an issue, we could try freezing those for the 'odd' releases, but I'd rather avoid that as it can artificially constrain development. For 1.9, I'd like to shorten the schedule a bit, if that works for other people. It seems like releasing around mid-late August would better align with the Beta schedules for Fedora, Ubuntu and MeeGo. If that seems reasonable to most people, I'd like to propose the following schedule: Merge window closes:2010-6-1 Non-critical bug deadline: 2010-8-1 Release:2010-8-20 I don't think there are any major changes planned for this release, so this shorter merge window seems like it should be sufficient. Nor do I necessarily think that this would also mean that the X.org release date should be moved in; having the X server ready *before* the X.org release seems like a good idea to me. I'll be doing periodic release candidates starting with the close of the merge window. This schedule would mean that anyone with changes they've been working on should get them posted now. Independent of the 1.9 release schedule, I'd like to encourage people to post patches as soon as possible anyway; there's no reason to wait until the feature merge window is open to get code reviewed, the merge window is supposed to be about getting changes lined up for the server release. Finally, some notes about what our current process is, just to remind everyone of what I think the rules are: 1) Post all proposed patches to xorg-de...@lists.x.org. 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. 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
Re: X server 1.9 release thoughts
On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. Ok, so now for the details about the 1.9 release itself. First off, I'd like to get a start on making things easier to build for people interested in testing the server or new drivers. I'm still interested in getting drivers pulled back into the server itself at some point, but it seems like an important and trivial first step will be to merge all of the protocol headers into one package. I'll get started on that and post a pointer to a merged repository for review. I'm just replying here so we've got my opinion public and archived rather than spread across several IRC conversations. From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. One of the big advantages of putting the input drivers in the same repo would be the ability to refactor common functionalities like mouse button emulation into the server. One of the things I'd like to see happen over time is the input properties becoming less driver specific. E.g., I'd much rather make use of the property Middle Button Emulation than Evdev Middle Button Emulation. This would seem to occur much easier when the server and drivers can be refactored simultaneously. Right now, the drivers that matter build against several X server versions and I get testing of e.g. evdev master against older servers, finding evdev-specific bugs during the development cycle. This is mostly due to the input drivers being much simpler and easier to install than video drivers, they have virtually no dependencies. The work needed to support multiple server versions is mostly negligible. To get the same exposure of testing once the drivers are merged into master requires a lot of cherry-picking on my behalf. Even then, we'd still need users to install the server + dependencies to test a new evdev patch, something which at this point would likely be a deterrent. So at this point, merging drivers in would increase my workload and reduce testing exposure. That's why I'm reluctant for evdev and synaptics to be merged, even though the no API/ABI is tempting. The drivers just don't move enough to make it worthwhile just yet. We'll see how Benjamin's multitouch efforts will affect that. In the near term that would hurt you because you'd have the modular evdev built against older servers and the monolithic evdev in the newer server. So, testing over multiple servers and porting fixes would be a pain. Longer term, I can't see it being that big a deal. If a person says that they're having a problem in a stable release, you check out and build the stable server with the _exact_ driver they're using and find the bug. It would seem to make hunting bugs easier since you can have basically an exact copy of the software they're running in one repo. Porting fixes from one driver version to the other would still be a cherry-pick forward or back, just like if you were fixing a bug in the server. If they're on a really old server/driver combo, tell them to upgrade. If someone came to you with a xorg-server-1.6 bug right now, would you attempt to fix it? I'd guess you'd tell them to try a newer server. That advice wouldn't change if the bug happened to be in the evdev driver bundled with that server. Just my opinion. Obviously, you're the one who's going to take the burden here or not. -- Dan ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 16:29:13 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. Yeah, we keep comparing the X server to the kernel and we really need to understand the fundamental difference -- kernels need drivers for dozens of devices for every machine. X needs very few -- video, keyboard, mouse and touchpad. And, X has external dependencies which aren't going to be integrated -- libdrm and Mesa. So, we're not now in a place where we could offer a single package that can work independent of other pieces. I think we should continue to consider when and where further re-unification of the source code would be valuable for developers and testers of our code. It may be that just unifying the protocol headers helps enough that we can get people to the point of testing the master version of drivers or the X server. except those patches where you are the most likely person to review them? I seem to have a few of them, mostly code that's old enough to drive, if not drink. Right, if you know a specific developer that should be reviewing a patch, you should Cc: them. If that's also the release manager, then you should make it clear in the message that you're asking for review and not asking to have the patch merged :-) We also had some overlap where I picked up patches at the same time as you did, causing some overlap. I think that's better now but we still don't really have a strict divide. More tree maintainers to snap up patches would be handy here. Something that might help here is to publish the list of subsystems and who is the maintainer in charge of them. That should be in the project tree itself so that anyone can find the right person. Sometimes it's hard to know which subsystem a particular patch affects though. If you find a patch that you want to shepherd and which has been sent directly to me, you'd be welcome to reply with a note claiming ownership. I'll try to keep my eye out when looking for stuff to integrate. -- keith.pack...@intel.com pgphLNsX6BrF6.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Apr 7, 2010, at 10:46, Keith Packard wrote: Something that might help here is to publish the list of subsystems and who is the maintainer in charge of them. That should be in the project tree itself so that anyone can find the right person. It already is... http://cgit.freedesktop.org/xorg/doc/xorg-docs/tree/MAINTAINERS ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, Apr 07, 2010 at 10:46:11AM -0700, Keith Packard wrote: And, X has external dependencies which aren't going to be integrated -- libdrm and Mesa. Why not? The license issues do not seem unmanageable, so what else is there? OG. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, Apr 07, 2010 at 06:33:25AM -0700, Dan Nicholson wrote: On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer peter.hutte...@who-t.net wrote: I'm just replying here so we've got my opinion public and archived rather than spread across several IRC conversations. From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. One of the big advantages of putting the input drivers in the same repo would be the ability to refactor common functionalities like mouse button emulation into the server. One of the things I'd like to see happen over time is the input properties becoming less driver specific. E.g., I'd much rather make use of the property Middle Button Emulation than Evdev Middle Button Emulation. This would seem to occur much easier when the server and drivers can be refactored simultaneously. I wholeheartedly agree with that, this is in fact the carrot Keith hangs in front of my face every time he brings merging the drivers up :) Right now, the drivers that matter build against several X server versions and I get testing of e.g. evdev master against older servers, finding evdev-specific bugs during the development cycle. This is mostly due to the input drivers being much simpler and easier to install than video drivers, they have virtually no dependencies. The work needed to support multiple server versions is mostly negligible. To get the same exposure of testing once the drivers are merged into master requires a lot of cherry-picking on my behalf. Even then, we'd still need users to install the server + dependencies to test a new evdev patch, something which at this point would likely be a deterrent. So at this point, merging drivers in would increase my workload and reduce testing exposure. That's why I'm reluctant for evdev and synaptics to be merged, even though the no API/ABI is tempting. The drivers just don't move enough to make it worthwhile just yet. We'll see how Benjamin's multitouch efforts will affect that. In the near term that would hurt you because you'd have the modular evdev built against older servers and the monolithic evdev in the newer server. So, testing over multiple servers and porting fixes would be a pain. once merged, the modular evdev driver would simply be a minimally maintained stable branch. so that's easy enough, though more legwork is needed for patches of course. Longer term, I can't see it being that big a deal. If a person says that they're having a problem in a stable release, you check out and build the stable server with the _exact_ driver they're using and find the bug. It would seem to make hunting bugs easier since you can have basically an exact copy of the software they're running in one repo. Porting fixes from one driver version to the other would still be a cherry-pick forward or back, just like if you were fixing a bug in the server. If they're on a really old server/driver combo, tell them to upgrade. If someone came to you with a xorg-server-1.6 bug right now, would you attempt to fix it? I'd guess you'd tell them to try a newer server. That advice wouldn't change if the bug happened to be in the evdev driver bundled with that server. not _quite_ the same issue. there is one big difference in there that matters: I can't yet tell a user to just rebuild the whole server (note the just), but I can do so for input drivers. Get the git repo, then rebuild and install over the system one and off we go with testing. the server is more complicated and I've had quite a few ppl go away when requested to test newer servers (especially those with little experience). It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. Cheers, Peter ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Apr 07, 2010 at 06:33:25AM -0700, Dan Nicholson wrote: On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer peter.hutte...@who-t.net wrote: I'm just replying here so we've got my opinion public and archived rather than spread across several IRC conversations. From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. One of the big advantages of putting the input drivers in the same repo would be the ability to refactor common functionalities like mouse button emulation into the server. One of the things I'd like to see happen over time is the input properties becoming less driver specific. E.g., I'd much rather make use of the property Middle Button Emulation than Evdev Middle Button Emulation. This would seem to occur much easier when the server and drivers can be refactored simultaneously. I wholeheartedly agree with that, this is in fact the carrot Keith hangs in front of my face every time he brings merging the drivers up :) Right now, the drivers that matter build against several X server versions and I get testing of e.g. evdev master against older servers, finding evdev-specific bugs during the development cycle. This is mostly due to the input drivers being much simpler and easier to install than video drivers, they have virtually no dependencies. The work needed to support multiple server versions is mostly negligible. To get the same exposure of testing once the drivers are merged into master requires a lot of cherry-picking on my behalf. Even then, we'd still need users to install the server + dependencies to test a new evdev patch, something which at this point would likely be a deterrent. So at this point, merging drivers in would increase my workload and reduce testing exposure. That's why I'm reluctant for evdev and synaptics to be merged, even though the no API/ABI is tempting. The drivers just don't move enough to make it worthwhile just yet. We'll see how Benjamin's multitouch efforts will affect that. In the near term that would hurt you because you'd have the modular evdev built against older servers and the monolithic evdev in the newer server. So, testing over multiple servers and porting fixes would be a pain. once merged, the modular evdev driver would simply be a minimally maintained stable branch. so that's easy enough, though more legwork is needed for patches of course. Longer term, I can't see it being that big a deal. If a person says that they're having a problem in a stable release, you check out and build the stable server with the _exact_ driver they're using and find the bug. It would seem to make hunting bugs easier since you can have basically an exact copy of the software they're running in one repo. Porting fixes from one driver version to the other would still be a cherry-pick forward or back, just like if you were fixing a bug in the server. If they're on a really old server/driver combo, tell them to upgrade. If someone came to you with a xorg-server-1.6 bug right now, would you attempt to fix it? I'd guess you'd tell them to try a newer server. That advice wouldn't change if the bug happened to be in the evdev driver bundled with that server. not _quite_ the same issue. there is one big difference in there that matters: I can't yet tell a user to just rebuild the whole server (note the just), but I can do so for input drivers. Get the git repo, then rebuild and install over the system one and off we go with testing. the server is more complicated and I've had quite a few ppl go away when requested to test newer servers (especially those with little experience). It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. I agree with this sentiment for video drivers right now as well. Alex ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 19:32:32 -0400 Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net wrote: On Wed, Apr 07, 2010 at 06:33:25AM -0700, Dan Nicholson wrote: On Tue, Apr 6, 2010 at 11:29 PM, Peter Hutterer peter.hutte...@who-t.net wrote: I'm just replying here so we've got my opinion public and archived rather than spread across several IRC conversations. From the input drivers POV merging them in provides little benefit as of yet and would probably be even detrimental to testing. One of the big advantages of putting the input drivers in the same repo would be the ability to refactor common functionalities like mouse button emulation into the server. One of the things I'd like to see happen over time is the input properties becoming less driver specific. E.g., I'd much rather make use of the property Middle Button Emulation than Evdev Middle Button Emulation. This would seem to occur much easier when the server and drivers can be refactored simultaneously. I wholeheartedly agree with that, this is in fact the carrot Keith hangs in front of my face every time he brings merging the drivers up :) Right now, the drivers that matter build against several X server versions and I get testing of e.g. evdev master against older servers, finding evdev-specific bugs during the development cycle. This is mostly due to the input drivers being much simpler and easier to install than video drivers, they have virtually no dependencies. The work needed to support multiple server versions is mostly negligible. To get the same exposure of testing once the drivers are merged into master requires a lot of cherry-picking on my behalf. Even then, we'd still need users to install the server + dependencies to test a new evdev patch, something which at this point would likely be a deterrent. So at this point, merging drivers in would increase my workload and reduce testing exposure. That's why I'm reluctant for evdev and synaptics to be merged, even though the no API/ABI is tempting. The drivers just don't move enough to make it worthwhile just yet. We'll see how Benjamin's multitouch efforts will affect that. In the near term that would hurt you because you'd have the modular evdev built against older servers and the monolithic evdev in the newer server. So, testing over multiple servers and porting fixes would be a pain. once merged, the modular evdev driver would simply be a minimally maintained stable branch. so that's easy enough, though more legwork is needed for patches of course. Longer term, I can't see it being that big a deal. If a person says that they're having a problem in a stable release, you check out and build the stable server with the _exact_ driver they're using and find the bug. It would seem to make hunting bugs easier since you can have basically an exact copy of the software they're running in one repo. Porting fixes from one driver version to the other would still be a cherry-pick forward or back, just like if you were fixing a bug in the server. If they're on a really old server/driver combo, tell them to upgrade. If someone came to you with a xorg-server-1.6 bug right now, would you attempt to fix it? I'd guess you'd tell them to try a newer server. That advice wouldn't change if the bug happened to be in the evdev driver bundled with that server. not _quite_ the same issue. there is one big difference in there that matters: I can't yet tell a user to just rebuild the whole server (note the just), but I can do so for input drivers. Get the git repo, then rebuild and install over the system one and off we go with testing. the server is more complicated and I've had quite a few ppl go away when requested to test newer servers (especially those with little experience). It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. I agree with this sentiment for video drivers right now as well. On the flip side, unless we have a decent set of video and input drivers included in the server, building and testing a new one will always be a bit painful. Today to test a driver: 1) grab the latest driver git, build and test * or if there have been API/ABI changes that need testing * 1) grab the whole hairy mess of the server, build 2) grab latest driver git, build test and hope it all works. If we only get some of the important (i.e. required for a standalone use case) drivers incorporated, we'll end up in the second scenario more than we do today I think. So most people are probably agreed that we should make it as easy as possible (ideally just one git tree) to build test new code. In order
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 19:32:32 -0400, Alex Deucher alexdeuc...@gmail.com wrote: On Wed, Apr 7, 2010 at 7:19 PM, Peter Hutterer peter.hutte...@who-t.net wrote: It's a numbers game. How many contributors and testers will I lose or gain compared to the hours of work spent? Until the server is a lot easier to build from scratch, I think the numbers aren't in my favour yet. I agree with this sentiment for video drivers right now as well. I think that's where we all are at present; we want to make things easier for everyone, and it's not obvious that merging the X bits needed to build a server is the best way to make this happen today. The other issue briefly touched on is the mesa/libdrm situation. Right now, libdrm gets released at the drop of a hat when some driver needs a new interface or bug fix. That's bee tremendously useful, but it often means that mesa and the video drivers are tied to a very new libdrm release, so people testing video drivers often need a new libdrm *and* a new mesa. Merging the video drivers into the server means we'd now end up forcing people to upgrade libdrm and mesa to build the server. Let's see what we think in a few months when we're starting to do planning for 1.10; we'll have had some experience with the merged protocol headers by that point (I hope), perhaps that's all we need to do? -- keith.pack...@intel.com pgpseNSCXuKLM.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, Apr 07, 2010 at 05:02:20PM -0700, Jesse Barnes wrote: On the flip side, unless we have a decent set of video and input drivers included in the server, building and testing a new one will always be a bit painful. Sure, but on the flip-flip side, and it's hard to say this without slighting anyone here, but will the drivers actually be stable enough to ensure that? If I fix a bug in evdev and ask someone to go test current xserver master, hopefully they're not going to come back and say 'I've got an 855 so my display doesn't work, do you have a patch against an older server?'. To be honest, I'm not sure our regression testing is yet good enough for this. Cheers, Daniel pgplW8ZwpvwQs.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, Apr 7, 2010 at 20:44, Daniel Stone dan...@fooishbar.org wrote: On Wed, Apr 07, 2010 at 05:02:20PM -0700, Jesse Barnes wrote: On the flip side, unless we have a decent set of video and input drivers included in the server, building and testing a new one will always be a bit painful. Sure, but on the flip-flip side, and it's hard to say this without slighting anyone here, but will the drivers actually be stable enough to ensure that? If I fix a bug in evdev and ask someone to go test current xserver master, hopefully they're not going to come back and say 'I've got an 855 so my display doesn't work, do you have a patch against an older server?'. To be honest, I'm not sure our regression testing is yet good enough for this. Indeed, it seems to me that video drivers are different enough that they can be kept separate for now. Also note that the EXA and Randr have stabilized (those were the most intrusive changes recently), and most of the interface changes are done now. Merging would bring little gain then. Stephane ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote: Beyond that, one requirement that I see for merging output drivers would be to shorten the X server release from the current 6 months down to 3 months or so. Otherwise I feel that the window of time between hardware release and driver release could become too long. I'm up for this cadence, but it would mean that we'd need to see major patches posted and reviewed in the previous release cycle so that they could be applied shortly after a release. I don't want to shorten the RC schedule by much. If ABI/API churn is an issue, we could try freezing those for the 'odd' releases, but I'd rather avoid that as it can artificially constrain development. Er, is there no reason hardware enable (even if it's not entirely fully-featured) can't be done in point releases? Cheers, Daniel pgpkZUwB4O8rG.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 04:47:13 +1000, Daniel Stone dan...@fooishbar.org wrote: Er, is there no reason hardware enable (even if it's not entirely fully-featured) can't be done in point releases? Nope, and perhaps that's what 'ABI/API stable odd releases' should mean? Does mean more non-trivial churn for the stable branch, but that might be fine. Other opinions? -- keith.pack...@intel.com pgpXzH4PeDV8x.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, 06 Apr 2010 14:43:01 -0700, Jeremy Huddleston jerem...@freedesktop.org wrote: I think a 3-month major-release cycle will be very taxing, especially considering the increased codebase with drivers. We're doing 3 month releases with the intel drivers today; it's working out pretty well as I think we're more responsive to regressions and other bugs than we used to be. The question is whether driver maintainers want to deal with non-maintenance changes (like new hardware support) in the stable branch of the X server, which will require additional work as they back-port things from master. Another possibility to take some load off of the release manager might be allowing assistant release manager (or possibly assistant to the release manager ;) positions for the drivers. That way, Keith doesn't need to be the gate-keeper for an increasing code-base, and the driver developers still have the same manager for their driver in its new location as they did in its old location. We've already got that in places already in the server -- Peter does all of the input review and I've been merging from him without a huge amount of additional review. I would expect any driver getting merged to the server to have a single driver maintainer that sends the pull requests; there's no way I can review Radeon or nVidia driver changes in any detail. -- keith.pack...@intel.com pgpNdjFaV6qHd.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Wed, 7 Apr 2010 04:47:13 +1000, Daniel Stone dan...@fooishbar.org wrote: Er, is there no reason hardware enable (even if it's not entirely fully-featured) can't be done in point releases? On second thought, this would require additional work for driver developers who would also need to deliver these same changes to the master branch. If the goal is to get more testing on code which is closer to 'master', then releasing 'master' more often seems like the best way to manage that. Of course, we could do both -- release master more often, *and* allow driver maintainers to back-port hardware support to the stable branch. Hardware support that depends on major X server changes may not get back-ported at all. I have a slight preference for faster releases; I don't think it significantly increases the burden for most developers as they'll work From master in any case. The trick is to mostly ignore the 'merge window' until you're actually ready to submit code for release, at which point you just check what the current release phase is and either submit immediately or pend until the next suitable window. -- keith.pack...@intel.com pgpvIy1znj3MU.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X server 1.9 release thoughts
On Tue, Apr 06, 2010 at 09:30:47AM -0700, Keith Packard wrote: First off, thanks to everyone involved in the 1.8 release; it was a pleasure to work with you. I'm hoping everyone else is as happy as I am about our new release process, it seemed to me that we saw a lot more active review and discussion about proposed patches this time around. For version 1.9, I'm planning on doing things in much the same way, if people have suggestions on how we can improve things, please post them so we can get things settled before we get too far into the release. Ok, so now for the details about the 1.9 release itself. First off, I'd like to get a start on making things easier to build for people interested in testing the server or new drivers. I'm still interested in getting drivers pulled back into the server itself at some point, but it seems like an important and trivial first step will be to merge all of the protocol headers into one package. I'll get started on that and post a pointer to a merged repository for review. Beyond that, one requirement that I see for merging output drivers would be to shorten the X server release from the current 6 months down to 3 months or so. Otherwise I feel that the window of time between hardware release and driver release could become too long. I'm up for this cadence, but it would mean that we'd need to see major patches posted and reviewed in the previous release cycle so that they could be applied shortly after a release. I don't want to shorten the RC schedule by much. If ABI/API churn is an issue, we could try freezing those for the 'odd' releases, but I'd rather avoid that as it can artificially constrain development. For 1.9, I'd like to shorten the schedule a bit, if that works for other people. It seems like releasing around mid-late August would better align with the Beta schedules for Fedora, Ubuntu and MeeGo. If that seems reasonable to most people, I'd like to propose the following schedule: Merge window closes:2010-6-1 Non-critical bug deadline: 2010-8-1 Release:2010-8-20 I don't think there are any major changes planned for this release, so this shorter merge window seems like it should be sufficient. Nor do I necessarily think that this would also mean that the X.org release date should be moved in; having the X server ready *before* the X.org release seems like a good idea to me. I'll be doing periodic release candidates starting with the close of the merge window. This schedule would mean that anyone with changes they've been working on should get them posted now. Independent of the 1.9 release schedule, I'd like to encourage people to post patches as soon as possible anyway; there's no reason to wait until the feature merge window is open to get code reviewed, the merge window is supposed to be about getting changes lined up for the server release. Hi Keith. From Daniel Stone's original announcement of the new release process [1] it seemed as if the release manager would be choosen from release to release, but apparently it is now set in stone. So, congratulations on achieving would-be linus status for X.org, i know how long and hard you have been striving towards this [2]. From Daniel his mail, it seems that undoing modularization for only graphics drivers was aimed for 1.10 instead of 1.9. Is there any reason for rushing this? This means that merging graphics drivers back into the server needs to be discussed in full, instead of just being decided ad-hoc by those who were at XDC. Please list and explain the advantages that this will bring over modular drivers, a tinderbox, and patch review. Why are you pushing towards a 3 month release cycle? I can only assume that this is because the intel portland team has been doing quarterly release cycles on their intel driver. Lumping the proto headers together seems like the first step on a complete undo of modularization on the non-driver side as well. Are we now backpedalling completely on the big first really big statement X.org made? How does this look technically? Are we not going to get into a libdrm like situation, where an update of one volatile part forces a version bump of the amalgamut, which in turn forces updates of all the dependants, even when they just depend on some otherwise stable parts? Are we then not just plainly scurrying towards having the protoheaders, the libraries, the library headers and the server all back in one repository? Thanks. Luc Verhaegen. [1] http://www.mail-archive.com/xorg-devel@lists.x.org/msg02128.html [2] http://xfree86.org/pipermail/forum/2003-March/000128.html ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
