Talk:Release Checklist

From Audacity Wiki
Revision as of 00:44, 18 October 2007 by Galeandrews (talk | contribs) (comment to James)
Jump to: navigation, search

Are we changing policy so that non-crashing issues are now included here (in the essentials section)? If so there are others that could be considered as candidates for this section. GA

  • We've never had and probably will never get watertight criteria for what is an essential and what isn't. Non crashing issues have always been candidates for being essentials. I'm sure we've had some as essentials in the past.
    • A reproducible crash is always an essential fix.
    • A regression in a previously working feature is generally an essential fix. It is much more serious than a defect in a new feature, since it is a reason a user might have to not upgrade.
    • An obvious bug anticipated to be relatively easy to track down and fix is generally an essential fix. An old bug that is hard to track down is generally not, unless its impact is severe. Obviously we'd like to clear hard to track down bugs and old bugs too, but we don't have the man power for that.
    • A feature that some users think does not behave as it should, but that is not actually a bug is generally just an aim to. It works as designed, but the design is being questioned. It doesn't reflect as badly on the project as a bug.
    • Some user issues that are 'cheaper' to fix than to use-as-is are candidates for being essentials. They need discussing on audacity-devel. For example, if lame installation were a hugely complex procedure for the user, we'd want to fix that - assuming a small amount of effort by the developers could save a very significant amount of work supporting users - that could justify holding up a release to fix. The idea is that we'd save a lot of time for the team as whole. Generally such issues are aim tos.

Gale, these are just my thoughts. If you or anyone else has suggestions for making it simpler or more effective, by all means suggest ways to change this.James 15:15, 17 October 2007 (PDT)

I don't think the last point ("cheaper" issues) is clear as to whether that should be essential or aim-to. The paragraph as written did not quite follow through for me. LAME is a good example though, as we did have definite plans for a Windows installer for LAME, which would save a great deal of support hassle. Basically it got sidelined due to the delays deciding on the location of an offshore LAME page, and then forgotten due to lack of manpower. In my view this should have been done for 1.4. As it is now, it should probably be a priority not aiming for 1.4, i.e. maybe it gets done in 1.5.0?

Generally I agree with what you've written about guidelines. IMHO though, up to a fortnight ago we were (wrongly?) interpreting essentials as "crash-only", but once a release timetable has been abandoned I suppose it makes sense in practical terms to take a slightly laxer view. The wording on the arrow key errors and what you now see on importing 1.2.x projects is verging on the bizarre IMO and reflects badly on the program, so I am going to have a go at the "destroy" message on the Wording page (even assuming it can be made to refer only to 1.1.x and earlier as intended).