Re: [Audacity-devel] Feature freeze (semifredo) from 24th Jan to 2nd Feb
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2010-01-13 05:24:51
|
| From James Crook <cr...@in...> | Mon, 11 Jan 2010 22:53:46 +0000 | Subject: [Audacity-devel] Feature freeze (semifredo) from 24th Jan to 2nd Feb > Gale, you're sounding miffed about me announcing a semifredo for the 1st > February release. If you are, don't be. I think it has become clear > that we do need freezes just before a release, and I wanted to make > really sure that that happens for that one. I don't want us to skip > that date too. No problem at all with a "two-committers-agree" code freeze (which I assume is what you mean, covering both bug fixes and "improvements"), but excluding a string freeze (which we will only have for the final Beta before 2.0). Part of the reason this particular "partial selections" problem happened is that I should have picked up on its likely impact when it became known and asked if there was a chance of holding release to fix it. It didn't seem "too bad" given we were then intending to release January 1st, but with hindsight it now seems a poor decision not to have waited. Would we have agreed to hold though, even if we knew another Beta was two months off? I'm worried we'd have released due to "dates on the calendar", which is really why I am raising this. > Having released 1.3.10, there shouldn't be a need to release 1.3.11 as a > matter of urgency. If we are releasing betas that need updates real > soon to fix them then we are releasing too quickly or not giving the > right information to users about the betas. I am thinking that one > possible solution to that aspect besides releasing a little less > frequently is to try to let users know that if they only see 50,000 > downloads for a beta then they are in Audacity terms 'early adopters' of > the beta. Beyond that number we should already know the big issues, and > downloaders should be directed to look and see the issues on release > notes on wiki, so they can see if they want to download. > > We can thrash out wording if you and others think that is a good plan > and would help. The e-mail release announcement already has a direct link to the Release Notes. The front page announcement has a link to "new features": http://audacity.sourceforge.net/download/features-1.3-a#details which links at the bottom to the "Known Issues" part of the online Release Notes. We could link directly off the front page announcement to the Release Notes (I'm already figuring to get rid of that "features" page after 2.0 and link straight to release notes anyway). But that's not a big change. I can't see suggesting that downloading Betas early on in their lifespan may entail more risk is useful, given (especially pre-2.0) we want to encourage uptake. And in any case, only a small proportion of users will have the gumption to find "Known Issues since Release": http://wiki.audacityteam.org/index.php?title=Known_Issues We could try integrating that into the online Release Notes to make people more aware, but generally I think the onus is on us, not the users. > Looking at audacity-feedback email, it does look as if the > export-regression in 1.3.10 is causing many people problems. Should we > deprecate 1.3.10 and direct people to 1.3.9? Is it that serious? If > the best solution is not to pull 1.3.10 but to get 1.3.11 out there > instead asap, then do a little more lobbying please. You know what is > causing users problems. If you have the team on board for a release > real soon, then a 3 day freeze from the point it is clear it is going to > happen is (IMO) just about OK. I guess if there is agreement that > 1.3.10's problem is that serious I would then say skip the 1st Feb > release, since we'll have had one in Jan and move it to 1st March, but > for now I am holding to the idea that we will do a 1st Feb release. We > also would need to look at how to avoid getting into this situation again. James, I think the lobbying and main arguments were clear on Team. Steve has amplified on them, and I'd add the "damage to reputation" from the unknown number of users who haven't written in, but will have gone back to a previous Beta (or 1.2) and had doubts sown about Betas. IMO we should have released about the 3rd or 4th, but from where we are now (a 1.3.11 couldn't be before about the 18th), I think we could hang on for the 1st February, to aid consensus. As a one-off response between now and then, I suggest adding a note about the problem to the three Beta download pages on the main site, suggesting those who export partial selections use 1.3.11 Alpha (1.3.9 will throw them back to "disk full when saving"). As to how to avoid these sort of issues in future, I'm still saying the best way is to target release dates to the "bugs fixed and outstanding" position, not to circles on a calendar. How many more Betas do we need and do users have patience for, before our final Beta? Can we target 1st April for final Beta? Can we target 1st April for clearing up the Windows P2s? Can we target 15th March for either, to save ourselves a couple of weeks? Gale > On 10/01/2010 22:08, Gale (Audacity Team) wrote: > > James Crook wrote: > > > >> Advance warning of a feature freeze (semifredo) for 24th Jan to 2nd Feb > >> to enable a new beta release on 1st Feb. > >> > > Just to put on record that the majority vote in Team was actually for a > > release in early January in order to get high priority bug fixes out there. > > Totally irrelevant IMO that it might have been happened to be the 5th or 6th > > of January rather than the 1st. While Beta releases about every month > > probably are too much overhead as a general rule, we should still in my very > > strong opinion target releases to bugs and decide dates to aim for > > (announced in advance) on that basis. > > > > > > Gale > > |