For 1.8, I would like to propose a new release and development process. Since I won't be at XDC, I'd appreciate it if this could be brought up and discussed there.
As you are aware, our current development model and release process have several issues: - our release schedule is unpredictable. 1.7 was such an example, we announce a schedule, then it went silent, then another, revised schedule, silent again, and then out of nowhere the code freeze and the final schedule and the actual releases. - git master is unusable at times. This hits developers as one suddenly has to spend time fixing other issues. Worse, it hits testers of new code who are at times unable to fix the actual issue. This exposes us to limited testing which in turn hurts everyone. - Late testing cycle. Build issues are reported fairly late in the process when we should be focusing on blocker bugs. Largely caused by the above problem. We can live with the above, but we shouldn't have to. In particular, it feels we're making it particularly hard for others to test our code. Not all is bad, we still manage to get releases out. The number of patches and reviews on xorg-devel has increased vastly and the number of contributors seems to increase too. At this rate, it can't take more than a century and two lab mice to obtain world domination. Anyway, I propose the following changes to our development and release process: 1. Feature branches: Any feature that is potentially disruptive, cannot be merged as a set of patches in one go, and needs intermediate testing must be developed on a branch first. When it is deemed ready, it can be merged during the feature merge window (see below). Feature branches can work well. For example, the mpx merge last year went quite smoothly. This process requires discipline though. For example, XI2 was developed on a branch but merged prematurely, resulting in active development on master. Not how it should be. 2. Three stages: feature merge - bugfix - release freeze This is possibly the largest impact to our development process. After a release, the feature merge window opens. Feature branches deemed ready may be merged into master. During this time, master is expected unstable and API churn happens. After the feature merge window, only bugfixes and general fixes may be merged onto master. Towards the end of this cycle, master should be stable and all drivers work with master. After this stage, master freezes for the release process. Patches to go onto master must hit xorg-devel first and only crucial bugfixes go in until 1.8 is cut straight from master. Once 1.8.0 is out, the 1.8 branch is created and the merge window opens again. Note that this is quite similar to the kernel process but with a central repository. The argument against an earlier 1.8 branch is that any bugfix on master should be going into 1.8 anyway so why have a separate branch. I think 3 + 2 + 1 months should be approporiate for the various stages. 3. Predictable time-based releases With the above, it should be easier to test master and no half-complete feature should be blocking master at any point in time. This allows for monthly snapshots of master so people can test the tarballs early. Towards the end of the cycle, bi-weekly or weekly snapshots until the RCs start. Release schedule is announced once and stuck to - within reason of course. The above incorporates suggestions from various people I've asked for input on this. Generally, I've seen a positive attitude towards having more predictable releases and the use of feature branches. Note that this process does not address all issues that we currently face and doesn't intend to. One step at a time. Comments appreciated. Cheers, Peter _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
