Desktop Build Release Process Meeting Notes
Attendees
- Driver: Philippe
- Facilitator: Jeffrey
- Note Taker: Aparna
- Attendees : Katie, Philippe, Bear, Bryan Stearns, Andi, Robin, Dan, Grant, Reid, Jared, Aparna, Jeffrey
Agenda:
- Objective of a renewed release process - Philippe, 5 min
- Current state of affairs (status of current thread of this subject) - Philippe, 5 min
- Use of SVN: trunk, branches and policies - 15 min
- Bugzilla tracking: use of various fields so we know what to work on first - 15 min
- Build and TBoxes: what gets built when (need to cover how we get TBoxes to build and test branches in particular) - 15 min
- How we make decision on what gets into a release - 15 min
- Release Process (how we branch, test, etc...) - 15 min
Current release process (until Preview)
- classic waterfall process
- everything being committed into the trunk
- tinderbox staying green didn't guarantee stability
- most of the testing was manual, not much automated testing
Objectives of the new release process
- release more often so we get bugs fixed by the users sooner
- features requested by users can also be delivered sooner
- manage expectations better from PM/Marketing standpoint
- making room for experimenting more on some of the features
- get contributor's code in faster and this would motivate internal and external motivators
- long period of debug/stabilization
- contributors can develop in branches and create their own branch releases
Risks
- destabilized trunk
- less automated test coverage
- lower quality levels
- implement the wrong stuff (not what users' have demanded)
- we let user's bugs fall thru the cracks
- orphaned code (code that exists only in a single developer branch and never landed on trunk)
- low developer morale
- scheduling difficulties
- merge errors/duplicated patches
- lack of clarity about when/which bug fixes/features go in
- underwhelming releases(not many features but just random bug fixes)
- overwhelming our users with the number of releases
- difficulty in doing large scale refactoring or big code projects
- could cause lower productivity because test writing is hard and time consuming as things are right now.
Current Plan
- monthly stable release
- follow the svn s3 process as proposed by Grant. Develop on branches and keep the trunk green. Merge branch work into trunk on a regular basis.
- more unit and functional tests
Comments on the current plan
- Robin had a comment about keeping all the unstable code in the branches so trunk stays stable. Having done so for wxwidgets has been quite useful.
- don't see how we could write more tests in the current plan. The code as is, is untestable or highly difficult to write tests on. Script/Recording may be part of the solution but clearly there is more than that can be achieved with this tool. We need a more general meeting to address testability, to see if there is any middle ground that can be achieved which doesn't require full-blown architecture rewrite or only being focused on the UI level. Aparna to plan for this meeting to happen this/following week.
- we need to follow processes which mitigate the above risks and only those.
Risks mitigated by the current plan
- destabilized trunk
- less automated test coverage
- implement the wrong stuff
- we let user's bugs fall thru the cracks
- orphaned code (code that exists only in a single developer branch and never landed on trunk)
- low developer morale
Unofficial releases
- release process involves creating a distribution and then a binary from the source code
- if we do development on branches for features and then create releases on those branches and developers should be testing that and publicising that release
- should run functional and unit tests against a release
- it's ok to keep the branch broken so PPD can look at the feature
- we should make the branch development and release process transparent to outsiders as well so that users can also be involved in this process
- there was consensus that we want tinderboxes to run on these branches
- bear will send out an email to the list about automatic branched releases
- bryan had a concern about conflicting schema revisions in the branches . Also certain branch code may or may not work with the current revision of cosmo
What gets into releases
- this is tied to how do manage it using bugzilla
- philippe's proposal is : create target milestone 0.7.future and move all the 0.7.1 bugs into that. Then move bugs into 0.7.x releases based on prioritization.
- PPD nominates a prioritized list (based on tenets) of bugs to be fixed in a certain 0.7.x release, sends that to the list and then go ahead and move those bugs to the targeted milestone in bugzilla
- if some bugs don't make it by the time we are ready to release, those get moved the next release. We don't block releases for bugs unless they are blockers.
- if people want to remove a bug from a specific 0.7.x release, they can untarget the bug and communicate on the list
- developers should still swag all the bugs because it affects how PPD prioritizes the bugs and what tradeoffs they need to make in the process
- there are still some details to be worked out and philippe who is the owner/driver of this will sort the rest of it out on the list
SVN approach (branches etc)
- how do people know that branches exist- possibly that information should be up on a wiki page.
- how should be name the branches? Should it be by bug numbers?
- features should also be in bugzilla as bugs
- consistent naming method to be followed for all branches
- philippe to write up a proposal about exact naming of the branches and send it to the list
- for not destabilizing the trunk at the near end of a release, all the branch merges should happen within 2 weeks of the last release. This also helps getting the branch code well tested before the release. Robin noted that there may be some exceptions to this in some cases.
- we don;t need branched for about everything. Tiny fixes can go straight into the trunk.
- restricted commit on the trunk is still in effect.
- Fixes associated with bug numbers and code reviews are also in effect
-- AparnaKadakia - 26 Sep 2007