[ Please don't Cc: me when replying to my message on a mailing list. ] I reply to and quote Brian C. White. Since there are so many different points, I've added a clarifying note to each quote (this allowed me to reduce the amount of quoting). I hope I didn't misunderstood anything while editing. (I should learn to write shorter rants. :) About only accepting bug fixes into frozen: > There is also the case of dealing with new code. If a new upload > is a new upstream version that contains new features as well as > fixes old bugs, what happens? If the bugs can be fixed without upgrading to a new upstream version, they should be (possibly by finding someone to do a non-maintainer release, if the primary Debian maintainer doesn't have the time). If upgrading to a new upstream version is necessary, then either accept the bugs or test the new version thoroughly. About release schedules: > I believe that the 3-month goal is achievable. I think so too, but not the way we've been doing it so far. However, I'd rather stress reaching goals than reaching time tables, and then work on setting such goals that can be done in three months. About mailing lists, and having separate policy and technical lists: > Of course, the problem with new mailing lists is that it doesn't > help anything if everybody has to subscribe to all of them. I suspect most people won't subscribe to both lists, especially the policy one. I'd suggest the following procedure: debian-devel-policy would discuss things freely when some kind of consensus is reached, the BoD makes sure someone writes down a concrete proposal for the new policy this proposal is announced on debian-devel-announce, and comments are made to the editor of the proposal, or on debian-devel-policy proposal is modified based on comments Repeat up to three times, and have the BoD make and announce a formal decision if they accept the final draft. This procedure would mean that most people wouldn't need to follow the discussions on debian-devel-policy, but would still be able to comment on proposals before they're decided on. On dividing: > project leader > testing manager > policy manager > security manager I assume the last three won't need to be on the BoD. It's probably not a good idea to collect volunteers yet, until the BoD starts working and there is a more complete proposal on how to divide work from now on. > You CANNOT give responsibility without authority and expect things to > work out. I agree. -- Please read <http://www.iki.fi/liw/mail-to-lasu.html> before mailing me. Please don't Cc: me when replying to my message on a mailing list.
Attachment:
pgpNi2fhmJfk8.pgp
Description: PGP signature