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