Talk:Developer News

From Audacity Wiki
Jump to: navigation, search

Links to home page

  • Feb 2010: Agreed that if we link to individual news items from the home page, these must be anchor links so people see the news item they clicked on.


Releasing to Fixed Dates

  • Gale: Re the "Change to releasing to fixed dates" that doesn't seem to be on the current Roadmap and I thought the policy was now more like "about every two months +/- a couple of weeks depending how many changes are ready to go"...
    • James: My understanding of the policy is that we fix a date for the next release, usually about two months away. We double freeze at least a week before, and try to make the date. If at the double freeze date it is obvious there is not enough worthwhile to release, we don't just push the date a little at a time. Your description makes it sound like we do.
    • Gale: So what do we do, say if we found there wasn't enough to release at double freeze date? Set a date another two months' hence, even though a worthwhile release in two or three weeks was likely, perhaps with an important fix that needed user testing?
    • James: We could push the date by a month, if we were pretty confident of having good stuff by that time. What we (or maybe just I) would like to avoid is getting into double freeze, and then 'discovering' we need to extend the freeze by a week or maybe two, who knows. We should be organised enough not to need to do that.
    • Gale: Maybe unavoidable if we are bug fixing long-standing, difficult P2 issues on which we don't make the progress we hoped for. To me, release dates are motivational things for us, more than something for public announcement. They may at times directly conflict with pragmatic quality considerations e.g.
      • Sometimes we may actually have enough to release including an important fix for a newly discovered bug only one month into the cycle
      • A rush by coders to meet a freeze deadline may not be conducive to quality, nor may the problem necessarily be evident in the testing period. Try current Ubuntu 9.10 for an example of a balked fixed date release.
      There may be an argument that users find fixed release dates helpful, but it seems very secondary to me. I would like to record this on Roadmap.
    • James: I suggest adding a section 'Roadmap according to Gale' arguing for semi-deadlines rather than definite ones. It is good/useful to have more than one roadmap/opinion. To the overview section we could also add 'We are still working out just how fixed the fixed dates should be', to indicate that there is not a complete consensus, or indeed a clear policy, at this stage. This strikes me as better than having the interleaved deadlines-debate on the page.
    • Incidentally we have no policy on public announcement of next-release yet and we could keep release date plans' announcements strictly to audacity-devel and do a Google 'not announcing plans (to the outside world) in advance' if we wanted to.

Note tracks

Gale 30Jun08, 20:29 UTC: Thanks, James. The reason I had omitted note track support for this week was that it breaks compilation on Linux (and gives assertion errors on the other platforms), and partly because I could not see the experimental code working anyway because it looked to me that it was turned on in Experimental.h, but it seems not. My note to devel list suggesting this should be in the Wiki in the Feature Planning category so there can be discussion of its features and how to test it refers. So would you like to explain how to turn it on? Thanks.

  • Gale 01Jul08, 06:47 UTC: Problem was that although it was turned on in Experimental.h as I first thought, I was fooled by the disabled menus into thinking it wasn't on.


Archived notice for display on Developer News if devel or cvs lists fail

Suggestions for -devel list:
  • Register with the Nabble mirror  of the list, if you are not already, and complete the quick e-mail authentication. Then you can post to the list via Nabble and read any replies that are made via its web interface. This is preferred, as the messages will be preserved in the Nabble archives, even if not in SF).
  • Send an e-mail to the person you want to contact, cc'ed to the team forwarding address  (team_AT_audacityteam_DOT_org) so that at least all the team members can see it as well.
  • If all else fails, post to an appropriate page on this Wiki, or to your [[User:]] page. Keep a frequent eye on Recent Changes too.
  • As for -cvs list, perhaps try to keep a summary of anything you have committed and check the date-sorted CVS list on SF .