> Even better would be if we could set a fixed step-by-step > cherry-pick/build/verify procedure (e.g. on the Wiki) and > get another developer or two involved in the process. This should > get easier after R14 is released as we won't be working around the > significant renaming between the SRU and master branches. > > Thoughts? How do developers in other projects support parallel branches? Much easier for R14 and forward. I suspect any outright bug fix gets merged in both the master branch and the R14 branch. New features, API/ABI breakage, enhancements, etc. (everything) are merged into the main branch but each commit is evaluated individually before merging into point release branches. We can handle that. The bug report itself is a guide as to whether the patch should be merged to the R14 branch, but as mentioned, we need a quality control check list. Once R14.0.0 is released we stop supporting 3.5.13. The last set of tarballs released for 3.5.13 is the end of that "branch." Anybody wanting to continue 3.5.13 will need to monitor the commit page to backport patches but that will not be a project goal. Thus we need only two GIT branches, the master development branch and the stable branch, the latter of which point release tarballs are derived. An R14 release schedule would help. Otherwise we have no good feeling of goals or time line. Currently the number of open bug tracker items is 569. As shared earlier: Blocker: 15 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Blocker Critical: 20 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Critical Major: 64 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Major Regressions: 12 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Regressions Build issues: 86 http://bugs.trinitydesktop.org/buglist.cgi?cmdtype=runnamed&namedcmd=Build%20issues As mentioned, because of overlap in categories, resolving Blockers and Criticals resolves 17 build issues. http://bugs.trinitydesktop.org/bugzilla/bugzilla/buglist.cgi?query_format=advanced&short_desc=Build%20issue%3A&bug_severity=blocker&bug_severity=critical&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=NEEDINFO&bug_status=CONFIRMED&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=PATCHAVAIL&bug_status=VERIFIED&short_desc_type=allwordssubstr Several build issues have work-arounds and need not be resolved for releasing R14.0.0. They get resolved in subsequent point releases. With 569 open bug reports, suppose all Blockers, Criticals, and Regressions are resolved to release R14.0.0. That is a total of 47 bug reports. Improve that number to 60 bug reports, which further reduces the list of open Majors and Build Issues, and we probably have our R14.0.0 release. 569 - 60 = 509 remaining open bug reports, of which 147 are enhancement/wish list requests, leaving 362 "true" bugs. We set a goal of a minimum 20 resolved bug reports per point release. Divide 362 by 20 to create 18 theoretical point releases. We don't have to have 18 point releases, although considering other software projects, that number would not be considered high or silly. At two month intervals, 18 point releases requires 36 months, or three years. Or, perhaps we set a project goal of 9 point releases per major release. At 9 point releases, we would be releasing a new major release every 18 months. At 9 point releases and 20+ bug reports per point release, we resolve 180+ bug reports. In that course new changes to upstream packages will introduce new bug reports that demand attention. New usability bugs will be filed. New enhancements requested. The never ending story. Yet by establishing a schedule we can envision our progress because we have goals. We resolve bug reports at a sane pace for the size of the team because the goals are realistic and manageable. Should Trinity's popularity improve, we likely improve the numbers with each additional developer. The potential is large with significant benefits. Darrell