Excerpts from Daniel Stone's message of Thu Oct 22 12:09:24 +0900 2009: > What? Why?
Doing more frequent releases will obviously reduce the lag between implementation and deployment; this should do lots of good for everyone involved. I get constant requests for shorter X server release intervals, enough so that I'm willing to do the work to make it happen if that's OK with the X.org community. The Intel driver is on a quarterly release schedule at this point, and we've been getting good feedback on this process from Linux OSVs and other users of the driver. Obviously sticking to schedules is a key part of any benefit to the OSVs here, and in my experience, shorter schedules are easier to hit than longer ones. Yes, it's a lot of release management, but as I said, I'm willing to make that happen. In any case, I've already committed to quarterly Intel driver releases, so either the X server as a whole gets released on this schedule or I'll end up doing a separate 'old X server + new intel driver' release every other quarter. That would suck. Independent of the release schedule, getting people thinking about how drivers will get integrated should improve the chances of a successful 1.9 release. > If 7.6 in December 2010 seems like a good idea, then what's the point of > doing 1.9 in September 2010? Few OSVs track just the katamari anyway; with drivers integrated into the server, we've got a complete and consistent X server that is deliverable at all times. Getting 1.9 done with the drivers integrated lets me get started merging API/ABI changes in the server, something which I find long overdue. I'll be posting patches for review in this area shortly. > Is the thinking to ram all the features we > need for the next year in to 1.8, do a short 1.9, seriously[0] maintain > it as a stable branch and keep it going and ship 7.6 with a more > plausible 1.9.5 or thereabouts, and then do the feature dance again for > 1.10? Nope; my plan is strictly time-based releases that contain whatever features are ready at that time. I'll push my requirements to match the merge window, and I'd hope that other people would be willing to do the same. Doing these frequently reduces the cost of missing a particular release, letting us push things off that aren't quite ready. Of course, OSVs will be able to pull such features into their packages as necessary to hit their customer requirements where said features are not yet released upstream. The key here is to get features ready for the merge before the merge window opens. We can merge huge changes in a short time if they've seen review and general agreement on the design. The release schedule shouldn't in any way drive broad feature development schedules, other than the final alignment with a suitable merge window. Frankly, I see the katamari process as less urgent once we merge the server and drivers back together -- we've always had an extremely strong API/ABI guarantee across the wire/kernel interface, and that isn't changing anytime soon. That means that the promised testing and integration offered by the katamari will be less important as the less stable driver API/ABI is removed as an external interface. > If so, is this something we want to think about doing long-term? (If so, > we might want to invert our cycles to stick with the x.y : y -> > odd/unstable, even/stable convention used by pretty much every other > open source project ever.) I'd like to say that all of our releases are stable releases -- unstable work should occur in feature branches or separate repositories. > (And +1 to the Dec 2010 schedule as well. Not only does it sound > plausible and give us more time to get our user[1]-facing APIs as good > as possible while letting us rip the server to shreds, I don't see > anyone else stepping up to do the thankless katamari work.) Agreed -- building the client-side pieces is still too much work to even contemplate on a more frequent basis. Thanks again to Alan for stepping up this time around! -- keith.pack...@intel.com
signature.asc
Description: PGP signature
_______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel
