Brainstorming improvements to future release processes
There has been some very interesting ideas on improving the release process brought up by Scott James Remnant in his blog post, http://
Some of these we are looking at implementing for Precise (in other blueprints), other points need discussions as future options.
This session is targetted to brainstorming what would be the impact of some of the more radical changes we're not going to fit into precise, since it is an LTS. Also what planning/
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Discussion
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
- None
- Started by
- Completed by
Whiteboard
Scott's post on http://
has some very good ideas in it. Some of which we can contemplate for Precise, and others of which need more research to assess if there is a net benefit over current system. This session is for brainstorming the ideas in his proposal, and determining what work should be done in 'Precise' to lay the groundwork for changes in Q release or later.
Ideas being investigate implementation in 'Precise' :
https:/
Ideas that should be assessed for 'Q' and beyond:
... fill in.
*Start planning for a change in cycle length ?
- Jason Smith (deebeeoh) has mentioned 12 months:
"I think as a developer, you are always wanting more time to make it perfect. There is a balance to be struck, personally i think a 12 month cycle makes more sense, but not everyone agrees with me."
http://
- In the comments from Scott's article, mpt, Treviño and other developers also mentioned longer cycles.
"the ideal release cycle length depends not on that development model, but on other factors. [...] we should have a much longer cycle than we have now. ISV compatibility checking and migration tools, OEM certification, cross-feature integration testing, upgrade testing, training program maintenance, toolchain and language migration, enterprise migration, server uptime vs. security, tech support, printed manuals and other books, developer reference materials, and so on."
http://
- Mandriva's recent change from 6 to 12 months could be another case-study.
- Ubuntu 12.04 will be an "extra LTS" (5 years) and with 2 extra years of new hardware support by popular demand. Making other releases too soon seems like wasting effort that can be used for more important things.
- Casual users (or the general consumer) rarely like or are prepared to handle potential upgrade problems, they purchase a computer (or device) and use the OS preinstalled till they buy a new one or it quits functioning (usually within 2 to 5 years). They do update apps however (which is usually quick and safe). This should be handled by a current backports / updates specification for USC soon.
*A real Release-Candidate period ?
- 1 week RC periods are really of not much benefit.
- In contrast the Windows RC period is "Months" before RTM (release to manufacturing).
http://
http://
- The real point of an rc period is polish and feedback period, so it cant be just 1 week...
- Also some apps like firefox when they offer an rc, they often make several more until the product is finally Polished, stable and its users/testers are happy.
Analysis necessary to determine if ideas are improvement over status quo:
... fill in.
Work items:
[ev] live-build generating virtual box images including PPA packages, with documentation
[skaet] set up a wiki for guidelines and strategies; mail out request for people to add best practices.
[barry] add strategy into best practices during early development wiki
[cjwatson] add in survival tips, if can be resurrected/found from earlier presentation.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
