r3 - 26 Sep 2007 - 23:00:02 - AparnaKadakiaYou are here: OSAF >  Journal Web  >  ContributorNotes > AparnaKadakiaNotes > DesktopBuildReleaseProcessMeeting20070926

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

Edit | WYSIWYG | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r3 < r2 < r1 | More topic actions
 
Open Source Applications Foundation
Except where otherwise noted, this site and its content are licensed by OSAF under an Creative Commons License, Attribution Only 3.0.
See list of page contributors for attributions.