> 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.

This sounds like a good idea, at least we avoid further delay of R14 :)


> 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.

I also haven't experienced any major problem with R14 in the few months of usage 
I have done so far. Nevertheless I think Darrell's suggestion about 
further testing the r14-xdg-update script is a good idea.

> We establish an etherpad wish list for each maintenance release 
> period. The bugzilla supports voting. Nothing fancy needed here.

As already discussed in the etherpad, IMO we should look at adopting some kind
of fix release schedule for the maintenance releases. Further details are 
available at http://trinity.etherpad.trinitydesktop.org/63


  Michele