Telephone: +1 812 856 7060
- Conference Code: 348#
- PIN: 72524#
- Review of branch comparisons (2.6.x against 2.6.0 and 2.7.x against 2.6.0)
- Seth Theriault
- Pete Peterson
- Clay Fenlason
- David Horwitz
- David Haines
- Chuck Hedrick
- Adam Hocek
- Steve Smail
- Anthony Whyte
- Anthony talking to us about branch comparisons
- laptop disaster leaves numbers a little ad hoc (from memory)
- what's in 2.6.x as of Aug 30 vs. 2.6.0
- some 232 merges in 2.6.x not in 2.6.0
- of those over 100 involved translation updates
- others for help documentation, some 20+ commits or so
- another half-dozen or so i18n commits
- leaving 75 or so fixes to code
- osp has the largest portion
- osp will now merge their own fixes into 2.6.x (ie broadening branch management)
- a dozen or so chat fixes
- 8 or so assignment fixes
- another dozen or so fixes in trunk not yet merged in, but probably should be
- site-manage has another dozen or so recent merges
- Beth added about 25 i18n updates just in the last few days
- analysis hasn't provided a qualitative picture, but a sense of the volume of changes, and what 2.6.1 would be about if we cut it today.
- about 40 issues ready to be merged to 2.6.x, verified and closed.
- another healthy chunk of resolved issues that need testing and verification.
- Anthony would like to see a 2.6.1 by the second half of September, and a 2.6.2 before the Thanksgiving break.
- DH: assignments SAK-16921 blocker he wants to flag
- site-manage also has some issues
- should be more proactive with these project teams on their issues
- haven't had people running osp involved in branch management, which has made it harder to see appropriate and timely merges
- Anthony has script for branch comparisons
- Seth and UCT both will have 2.6.x branches running on QA server.
- important to distinguish known revision from the one running on nightly
- still need some documentation on what's changed
- Anthony feels fairly comfortable with his grasp of what's in 2.6.x. Still needs some JIRA cleanup, but can use svn logs to help do that.
- Looking at trunk vs. 2.6.x
- Over 800 issues closed, overlap with 2.6.x (since merged across)
- issues specific to 2.7, about 350-ish
- looks better to move ahead with 2.7 based on trunk rather than 2.6.x
- merges get a little more complicated
- If we don't have a branch manager for 2.7, might want to hold off on branching
- pick known revisions, wait until we get to a point that 2.7 is ready for its own branch
- call it trunk QA
- the one thing you don't get out of that approach is that you're not constraining work
- better for us for general QA if we have a better idea of the things that are going through on a regular basis. Can't do gatekeeping without branch manager.
- a lot of changes in 2.6.x also in 2.7
- 2.6.x a priority over 2.7?
- would be wise to focus QA efforts on 2.6.x
- Disadvantages with work we've done so far is that things get pushed off to last minute
- Does it make sense to have a single date? Can depend on project?