Talk:Release Process

From Audacity Wiki
Jump to: navigation, search

Release Process, now we have Git

James has outlined a release process that is different from the one described on the main page.

  • It has a soft freeze of one week. Last minute fine tuning of wording is OK. The only big changes allowed are removing or reverting a feature.
  • It has a hard freeze of two weeks. In those two weeks we can make and try out alphas with installers, but these are NOT regarded as actual release candidates. Translators and technical writers can work on the translation and manual during this time.
    • Gale 16Jun15: You say to "test installers etc (using old manual and translations)" but given this is only about Windows I suggest testing with the latest Manual dump and latest available translations. In particular, during runup to 2.1.0 it was very flaky as to whether the Manual actually completed dump or not (at least on Windows and Mac).
    • James (talk) 14:53, 17 June 2015 (EDT) 'Old' in the sense not yet fully updated. Totally agree, we should use the latest available, and that is what I meant.
  • Git makes this long freeze more acceptable as it is easy/natural to have parallel branches progressing whilst audacity master is frozen. Unlike past freezes, discussions on audacity-devel of branches which aren't going into the release will be perfectly OK.
    • Gale 16Jun15: QA Team could be at a disadvantage in those discussions if decisions are made that they don't have time to give input on. It's the non-developers who are at risk of "delaying the release" after we're in freeze, so they have little time in this period.
    • James (talk) 14:53, 17 June 2015 (EDT) QA is busy all the time. After a release there is often a surge of support requests. In the run up to Semifreddo, RM is looking for QA opinions on all DEVEL-FIX MADE bugs. I think a level of trust in the team is needed. At this stage in the maturity of the project we know where there are conflicting pulls, and in those cases we try to find new options that make both pulls win. There is very little risk of decisions being set in stone on new features on entry to a new release cycle.
    • Gale 18Jun15: As you say, those who do support are also busy after a new release, and are always busy. Again, the issue is that we do not have people who only do QA. We have one support person who does nothing else. We should stop thinking that QA == support. It is good that QA and support should be aware of each other. It is not good that we have no people who only do QA.
  • RC1 gets a week of testing. If it is OK it becomes the release.

James believes that release process described on the main page makes multiple release candidates almost inevitable, and that it creates additional work. He thinks the release process needs to change, and for us to have an expectation that RC1 will be the release, if we are to actually achieve releases to a three month schedule.

  • Gale 16Jun15: I remain of the opinion that we should target and achieve four month releases given we do not have a dedicated QA Team that *only* do that.
  • James (talk) 14:53, 17 June 2015 (EDT) Let us discuss this at the start of 2.1.2. We've had multiple 'whammies' in this release, from shifting to GitHub, to Sourceforge blowing us off, to the wx3 fiasco. AND we have a lot of new stuff in 2.1.1 too. I think 3,4 or 6 month cycles could work well. I do much prefer the longer freeze, and it is possible with Git now.
  • Gale 13Apr15: What about code fixes for bugs in soft and hard freeze periods? Currently in the period leading up to end of GUI freeze/start of code freeze, any bugs of any priority are regarded as fixable, especially if they are on a "release agenda".
  • James 13Apr15: P1s are fine throughout freeze. If you have a fix just check it in (and if it is not the right fix we will deal with that). Anything else is ask RM. If it's on the release agenda, it's already OK during soft freeze according to RM. Small fixes and especially P2 fixes will likely be accepted during soft freeze anyway. Larger P3 and below fixes, especially if they involve GUI change, likely not. During hard freeze a P2 fix would likely only be accepted by RM if RM had decided to block on it, otherwise it would wait to the next release. The P2s are the only edge case about what to do during hard freeze, and RM decides. Note that Leland's text-to-binary speed up of autosave would likely not be accepted during soft freeze, even though it further improves on a P2 fix. It's a risky change that if it is in needs to be in earlier.

Old discussions about Vaughan's process

Gale 06April11: My reading of the otherwise very clear article is that there is no margin for QA testing of DEVEL-FIXED bugs. Fixes could theoretically be posted right before start of code freeze, yet testing of these probably affects the README which is also supposed to be ready just before start of code freeze.

  • Gale 12Jul11: Release Process now suggests "Code/string freeze is first. Manual/Release Notes freeze happens 24 hours later" so this is largely resolved unless there are a large number of last-minute commits requiring heavy testing.