On Wed, Feb 16, 2011 at 7:45 PM, Peter Hutterer <[email protected]> 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.
> 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. 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. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
