Hi, As probably some have read in -project[1], there is a possibility of keeping track of release issues for etch using debbugs, considering that we're close to have bug dependencies[2] in debbugs (I'll be mailing [EMAIL PROTECTED] to ask him to apply and test the patch).
The "Bits from Vancouver..."[3] email brings an important point to make the release cycle more predictable, that is documenting what we expect to be in etch to start etch release process. And I do think it's very important to start that *before* sarge releases. The following suggestion is made before the debbugs patch is applied and before the creation of the pseudo-package etch in debbugs. I hope to mature the idea with your help, so after that, proceed with executing it. My suggestion is to initially submitting the "major package changes" as bugs to the (future) etch pseudo-package, allowing others to suggest expected features/changes in etch and finalizing the list of release issues for etch just after sarge is released. This would bring some good things: * People would know which changes will need to wait for etch+1 * People would know what are we waiting to be ready * People would know that some change will happen and work on fixing bugs that will appear after the documented changes. As I said first, I would like to start a discussion to mature an idea, and I hope you can help, actually, the release team is the team who actually can make it happen. []'s daniel [1] http://lists.debian.org/debian-project/2005/03/msg00078.html [2] http://lists.debian.org/debian-project/2005/03/msg00111.html [3] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
