On Thu, Feb 17, 2011 at 12:18:24PM -0800, Jason Gerecke wrote: > On Wed, Feb 16, 2011 at 7:45 PM, Peter Hutterer > <peter.hutte...@who-t.net> wrote: > > What I'd like to commit to is regular releases. While the misc cleanup is > > still going strong, we can't and shouldn't just line up with X server > > releases. So what I propose is an approcimately monthly release with a > > driver release ever first week of the month. > > > This sounds reasonable. The median release time is between 4 and 5 > weeks (depending on if you count .10 and .11) which lines up nicely > with your proposal. I do share Ping's concern about providing a > testing period though. Whether this means a code freeze on master, a > tag/branch in that people can checkout and test, or a packaged RC > which is uploaded to SourceForge... I'm still too new to this project > to even pretend to know the best route.
well, what I do with all other X input drivers is to tag them as a .901 and .902 for the first and second RC, respectively. and of course provide tarballs. No reason we couldn't do the same though in that case I might go for a 0.11 and 0.12 etc release naming. 0.10.11.901 seems a bit excessive :) we've had mixed experiences with people testing branches for releases. in the end it comes down to the branch being more complicated to check out and test, so you want the code that's most in need of testing on master. I think the -next is working out well for the kernel and we've had some success with it in X as well. so master would be frozen between RCs and intrusive stuff can go on -next. > > This requires some more discipline, so I'll simply stop merging intrusive > > patches on the 1st of each month and focus on dealbreakers only for a couple > > of days. anything else will simply go on -next, which will then be merged > > whenever the previous release is out. > > > This kinda conflicts with both itself and the paragraph above... Are you > saying: > > 1. Release the first week of each month. Just prior to release, stop > merging intrusive patches entirely to give people time to test. > Sometime after release, resume merging intrusive patches. > > 2. Release the first week of each month. Just prior to release, create > a -next branch where intrusive patches can go while people test. > Sometime after release, merge "-next" back into master. ^^ this one. Also, I should probably note that the next release won't be in the first week of March (though looking at the cintiq issues it may be necessary). I expected a longer discussion with the new changes (doxygen, test suite, release schedule, etc.) so that helps us bridge over the remaining two weeks in Feb. Cheers, Peter > 2. Release the first week of each month. Just after release, stop > merging intrusive patches entirely to give the code a stable base > while we fix reported bugs. Sometime later, resume merging intrusive > patches. > > 3. Release the first week of each month. Just after release, create a > -next branch where intrusive patches can go so master remains stable > while we fix reported bugs. Sometime later, merge "-next" back into > master. ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
