Using debbugs to formalize and track etch goals
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
owner@debbugs 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
Reply to: