Regarding cmake 2.8.12, that is and should be a Blocker bug report - -- but not a blocker for R14. We add a note in the release README (refer to etherpad) that we are aware of the issue and offer packagers a temporary work-around similar to that suggested by Fat- Zer. At least two people should test a formal patch, then we attach the patch to the bug report and reference the bug report in the README. Regarding the delays with rebuilding Debian/Ubuntu packages. The presumption seems open to debate whether all of these package sets have to be built on the Trinity servers. At a pace of 18 days the realization is the servers lack the capacity. Likewise the presumption that all of these package sets must be built --- and mirrored --- before announcing the release. We have so few people participating in development and packaging. I don't know why package sets need to be built on the Trinity servers. Why not by individual participants and then uploaded? Moreso, rather than one bulk release, why not offer package sets progressively as they are built and mirrored? Issue press releases as each package set becomes available --- a simple public relations strategy that keeps Trinity in the news, let alone relieves serious tension and pressure to have all package sets built at one time. The initial press release merely states that additional package sets are forthcoming. If build scripts and tarballs are available in the official release announcement, then others can get involved. Until then serious triage is needed of what to support. Unlike previous releases, the sticky part of R14 is the significant number of renaming and branding changes. As the old adage goes, we only get one chance to create a first impression. We never developed any kind of release test plan. We hobbled along only through feedback by the few of us participating. We've done okay, but for example, we have not performed largescale testing of the r14-xdg-update script. Slavek and I tested but we are only two people with two different usage perspectives. That one script has the potential to destroy first impressions. My personal usage of R14 indicates no serious problems. Yet I don't use every single package nor do I use all apps every day. I'm sure there are hidden bugs as a result of the massive renaming and branding changes. I'm not worried about these types of bugs. My primary concern is not bug reports like cmake 2.8.12, but fundamental desktop usability. The desktop is the sole location where users and reviewers form their first impressions. While long- term Trinity users will tolerate bugs, reviewers and new users will not. Of those types of reports listed in the etherpad, I see the following that should be resolved immediately: 1761 tdevelop FTBFS with recent (t)qassistantclient patches 1759 R14 FTBFS with cmake 2.8.12 --- only test a formal patch providing a temporary work-around 1733 Launcher menu (T-Menu) takes a long time to appear the first time using Alt+F1 1729 KOffice: Applications crash on logout Get those reports resolved and release R14. Long term, as noted, we will never resolve all bug reports in a timely manner. That kind of focus is part of maintenance releases. We establish an etherpad wish list for each maintenance release period. The bugzilla supports voting. Nothing fancy needed here. Short term we focus on triage and develop a reasonable release pace for various distro packages. I believe that after we release R14.0.0, and users migrate from 3.5.x to R14, the bulk of the effort is behind us. We then focus on a maintenance release schedule where we no longer are distracted by the pressure of big announcements and big pushes. With maintenance releases we are able to move along at a steady pace. We just need to get past the big hump now known as R14.0.0. :-) Darrell