...
Doesn't sound like branch processes are broken
Michael proposes the following (picking on Seth and David): get them to write up the process and get it posted. Then we will start following it. E.g. the Jira type is bug etc.
may be value in broadening the branch mgmt process to get second opinions on whether it passes. Doing it in some areas such as involving Jim Eng in Resources issues. Document this as part of the process. Recommendation of a project leader is a good stamp of approval.
2.5.1 and # of components that were touched and the number of tests needed.
Can these fixes be clustered in narrower focus to make testing easier.
Could be tough to track the modules and the clustering
Megan says can work around needed fixes by version release vs maintenance branch
I f If 2.5.2 and 2.5.3 come out only a month apart this makes tracking easier
Time boxing helps with local resource allocation. Need is to have a goal for maintenance release.
Counter difficulty is it is hard to take a lot of smaller releases if you have large mods and your own copy of the whole system (e.g. if it takes a month to apply the minor releases)
Fine for 2.5.x to only accept bug fixes. Then maintenance release tests only certain areas and pulls other code from the previous releases.
Michael's goal is to take down a certain release and put up something better for people to download.
Seth likes the idea of targeted tested areas with time frames. 2.5.x continues. But maintenance release is 2.5.1 - announced for 
months ahead. Fixes in that would be focused on certain functional areas (with security bugs an exception). Announce the coming next release as make a call for QA assistance and choose the functional area for the release based on the QA resource that is volunteered.
2.5.x evolves as branch manager sees fit.
2.5.2, 2.5.3 evolve as scoped by what QA resources are available in a relatively short time frame as volunteered.
And Security trumps all.
It ought to be okay to take down prior maintenance releases (for public download)
For a major security release and a month or more to go to next planned release then make a tag for that and include only the security patch
...