Notes from afternoon discussion, part I of Maintenance and Minor Release discussion
Branch management tracking
Patching is for a bug, not a feature
info required on testing already achieved and where it is running
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
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
Post this to Management/coordination page as notes (as per Peter)
For new functionality: also try to introduce something that comes out more regularly and probably QA driven.
UCD wasn't running official 2.4.x GB - something sooner. What is problematic though is that anybody can introduce anything.
Note: there is no enforcement mechanism now to talk about what you are doing and to expose it to the community. There are so many moving parts and people working on different things that it is really problematic. Gets more and more difficult to get the thing running.
Seth's proposal is an equivalent of patching PMC for functional changes: very small group of people with technical person, UIperson,
e.g. Indiana's chat tool. Promised in a conference call that there would be no UI changes but that turned out not to be true.
Related issue is things are developed as full package: functionality, UI and API
The way Apache does it is with some amount of technical review. Some people just need some guidance.
But a big question is who has the expertise to be on such a committee. Who is it and do they have the time.
topic: if want to do minor release on top of 2.5---what is an example.:
one example is an optional feature that you can swap out.
Another question is why do we have to release all the tools at the same time. Could have 5 GB releases when other tools have different time scales. Feature Release branches....
Eclipse model is coordinated subprojects and each project is responsible for its own release. But this feeds into K1 discussion and different individual numbering schemes.
Installer model would be really nice.
Changes that don't require changes to underlying services.
What do we want to see improved in the shorter term
One example: camtools by October
Another: email templating service (new services is easier)
Lance distinguishes between experimental releases and enterprise releases (Fedora vs RedHat)
Maintenance Release:
Propose to community that some technical governance group QA+Branch Mgmt will review
No decision yet on functional releases (minor releases).
Talking about minor risk is in part documenting what we are already doing.
New topics: technical governance of functional
decoupling general tool releases from functional additions