Feedback on Oneiric Release and Improvements for Precise
This meeting is to brainstorm on the current release process used Oneiric, what worked and what didn't, and ways they can be improved for Precise.
Blueprint information
- Status:
- Started
- Approver:
- Kate Stewart
- Priority:
- High
- Drafter:
- Kate Stewart
- Direction:
- Needs approval
- Assignee:
- Ubuntu Release Team
- Definition:
- Drafting
- Series goal:
- Accepted for precise
- Implementation:
-
Started
- Milestone target:
- None
- Started by
- Kate Stewart
- Completed by
Whiteboard
Work Items for ubuntu-12.04:
[kate.stewart] release etherpad needs to be better advertised (perhaps to ubuntu-devel): DONE
[stgraber] for ISO Tracking session add ability to include notification of why rebuild happening: DONE
[kate.stewart] clean up ReleaseCandidate on the process pages - pre-release image could be the final image: INPROGRESS
[kate.stewart] refactor ReleaseImageCon
[brad-figg] kernel-bot: need to stop spamming bug which are feature requests, and those where the developer knows its not fixed:DONE
[kate.stewart] create a generic "stop nagging me tag".
[kate.stewart] communicate widely the "bot stop nagging" tag to bot writers
Pre-UDS notes from Whiteboard:
===================
Some of the open questions up for discussion:
- We did not create a formal release candidate deliverable in Oneiric, was the extra bug fixing time worth it?
- Were the milestone image planning pages (ReleaseImageCo
- There are many process pages for managing a release is scattered over many different WIKI pages, and the role as to who needs to do which tasks is not always clear ( does it make sense to create a unified summary page with roles a bit clearer? )
- How to fix bugs earlier in the release cycle? Some High/Critical bugs persisting through cycle.
Seb24 :
- Add a real Realease Candidate period to fix more bugs ?
- Feature freaze earlier and strict, no more Feature Freeze Exception ?
ScottK:
- Oneiric was the same as Natty for a "Release Candidate". I think it's a feature that we start to call an image a release candidate when we think it's something we might release. The old "Release Candidate" milestone is now called Beta 2, so we haven't lost anything. Please don't revert to calling non-release candidate images release candidates.
- The ReleaseImageCon
- Many of the bugs dealt with in the endgame were a consequence of late features being accepted. This should absolutely be avoided for the LTS.
- Other bugs were a side effect of the accelerated release schedule we inherited from 10.10.10.
- If feature work actually stops earlier, then there will be more resource scope for bug fixing (at least for funded projects - for free time projects the available resources aren't necessarily transferable).
Sorrodje:
- I'm used to participate to Beta/alpha testing on french Ubuntu forum . I think we need a test protocol for upgradind process ( or other cirtical process of a release ) in order to eliminate biggest problems.
- I think Ubuntu MUST provide a delay time - two or three weeks between release and opening possibility of upgrade
- User MUST be concerned about his upgrade : the best solution IMO would be that upgrade process must be accompanied through a tool like ubiquity which diagnosticate the Machine and the system and guide user through preupgrade essential tasks ( explaination about danger , question about backup , information about new features ... ) before having user clear validation to upgrade from User ( " are you sure to want upgrading NOW ? " Di you prefer waiting a few days ( remember me in X days ) ... )
- Users involved in bug tracking must all work better together to eliminate bugs in last weeks before release
- I should improve my english to participate well ;-D
M.B.:
This article sums up many of the fundamental problems with the current release process that get overlooked:
http://
- The need to change to an always "stable-trunk" model.
- Ubuntu features are time based, not a fixed 13 weeks.
- We replace stable features with their half-baked counterparts.
- Pay, bonuses, etc. dictated by how many are in by feature freeze
- Need for experimental/
- Or promote "non-lts" releases as dev/testing since that is basically what they will become again soon.
- Normal users want every release (no matter the cycle length) to be a good release and as bug free as possible, not just the LTS. They dont want anything to do with these bugs as they are not beta-testers.
Discussion at UDS:
===========
transcribed from: http://
on 20111107
Changes:
- status.ubuntu.com - work item tracker available to flavors and other teams via "topic-" creation.
http://
- automatic partitioning of bugs to teams
http://
- Release Candidate - no formal publishing, pointed press at iso tracker
Release candidate not being a formal thing was very positive allowed better inclusion of fixes before release, resulting in fewer SRUs.
It was difficult to find out what was the actual final release bits ?? before or after release ?
You needed to be in the release irc channels to know when there was a respin. There is now an etherpad for this, in the topic of #ubuntu-release.
( http://
* need improved communication for the above bits, announce on #ubuntu-devel, email
* need announcements for respins (fixed in new version of iso-tracker)
* need ability to comment on the reason that a respin is happening, for instance, so that people can be told to continue testing
- Explicit inclusion of flavor leads in weekly meeting
Flavour leads were happy to be included, their inclusion was deemed useful.
Some of the open questions up for discussion:
- We did not create a formal release candidate deliverable in Oneiric, was the extra bug fixing time worth it?
Bug fixing time was useful (see above).
Lot of people looking for something - announce? milestone in project; criteria?
IRC: Automated reactions to bugs is demotivating - faster response. 2-3 bots not as friendly.
Fix tools to submit right information. -> more conversation on bug reports. Sources of information.
- Were the milestone image planning pages (ReleaseImageCo
Generally thought to be useful.
However, rearrange to be more easy to type into.
- There are many process pages for managing a release is scattered over many different WIKI pages, and the role as to who needs to do which tasks is not always clear ( does it make sense to create a unified summary page with roles a bit clearer? )
ReleaseTaskSignup - hard to find. Get standardized.
- How to fix bugs earlier in the release cycle? Some High/Critical bugs persisting through cycle.
TRYING in P: http://
See session on acceptance criteria - code in Canonical, only upload if working.
Smaller list of bugs - someone in UE is going to fix, which we will live with.
Seb24 :
- Add a real Release Candidate period to fix more bugs ?
The Point of a release candidate is to say that we think the release is ready
bug fixing is the whole release period
- Feature freeze earlier and strict, no more Feature Freeze Exception ?
ScottK:
- Oneiric was the same as Natty for a "Release Candidate". I think it's a feature that we start to call an image a release candidate when we think it's something we might release. The old "Release Candidate" milestone is now called Beta 2, so we haven't lost anything. Please don't revert to calling non-release candidate images release candidates.
? names - miscommunication, needs to be clarified, see elsewhere.
- The ReleaseImageCon
https:/
will look at restructuring
- Many of the bugs dealt with in the endgame were a consequence of late features being accepted. This should absolutely be avoided for the LTS.
- Other bugs were a side effect of the accelerated release schedule we inherited from 10.10.10.
- If feature work actually stops earlier, then there will be more resource scope for bug fixing (at least for funded projects - for free time projects the available resources aren't necessarily transferable).
rickspencer3 is worried that people see "freezing early" as a panacea, but he thinks it's not realistic and will just make us hard to work with and spend a lot of time managing "expections". Rather, we should focus on making Ubuntu good quality each day and allow teams with solid code to land that code with reasonable ease (acceptance criteria might probably "replace" the need of Freezes).
I think a big problem with the "Release Candidate" thing this cycle was that some users didn't understand whether there was one or not; insufficient communication.
Standing Freeze exceptions; interlock with other upstreams. See approaches being tackled in P release (criteria, committed fixes).
- Should be worrisome to have image builds failing for several days. One day failing, we have a problem to investigate; one week failing, it's the apocalypse. We should have daily images (or so), and that needs to be critical.
Sorrodje:
- I'm used to participate to Beta/alpha testing on french Ubuntu forum. I think we need a test protocol for upgrading process (or other cirtical process of a release) in order to eliminate biggest problems.
upgrading in batches? sort of happening already - but may be worth investigating further batching? automated testing results visible might help.
- I think Ubuntu MUST provide a delay time - two or three weeks between release and opening possibility of upgrade
- We will do this for LTS-to-LTS upgrades, as we always do; upgrades from 10.04 will only be enabled as of the first point release, three months or so out. For upgrades from 11.10 I think it's less of a problem. -cjwatson
- User MUST be concerned about his upgrade : the best solution IMO would be that upgrade process must be accompanied through a tool like update-manager which diagnose the Machine and the system and guide user through preupgrade essential tasks ( explanation about danger , question about backup, information about new features ... ) before having user clear validation to upgrade from User ( "are you sure to want upgrading NOW ? " Di you prefer waiting a few days (remember me in X days) ... )
?mail list discussion - more technical design.
- Users involved in bug tracking must all work better together to eliminate bugs in last weeks before release
- I should improve my english to participate well ;-D (vous parlez anglais tres bien!)
M.B.: ---> see: https:/
see: https:/
This article sums up many of the fundamental problems with the current release process that get overlooked:
http://
- The need to change to an always "stable-trunk" model.
- Ubuntu features are time based, not a fixed 13 weeks.
- We replace stable features with their half-baked counterparts.
- Pay, bonuses, etc. dictated by how many are in by feature freeze
- Need for experimental/
- Or promote "non-lts" releases as dev/testing since that is basically what they will become again soon.
- Normal users want every release (no matter the cycle length) to be a good release and as bug free as possible, not just the LTS. They dont want anything to do with these bugs as they are not beta-testers.
- bugs and bots? do we need a session. - X team? security.
Work Items
Dependency tree
* Blueprints in grey have been implemented.
