On Sun, Aug 23, 2009 at 11:45:18AM -0700, Don Armstrong wrote: > On Sun, 23 Aug 2009, Steve Langasek wrote: > > I am concerned that this has gone to a vote without any actual > > answers to the questions posed in > > <[🔎] 20090812062208.GF9480@rzlab.ucr.edu>. > I interpreted Andi's response as one answer, and the lack of any > additional messages as an indication that there wasn't any additions > to the set of bugs which needed to be fixed before allowing an upload > (though the set of bugs to allow it to transition to testing was > larger)... which apparently wasn't the case. Well, given the outcome of the DebConf TC BoF, where Ian said he would follow up regarding the other bug he's encountered which didn't make the referenced list of qmail bugs, I expected that we would wait for that information to come in before moving to a vote. > > I do agree that it's not fair to have a moving set of things to fix > > for uploading to the archive, but I think that just means we have an > > obligation to examine the package carefully and enumerate that set > > of critical bugs, not that we should call it good with the one > > critical bug that's currently been identified to this list. > I'm of the personal opinion that having the package in unstable and > enumerating the set of bugs using the BTS is (in general) the best way > to do just this, though the delayed bounce issue is serious enough to > delay the package. There are certainly serious bugs, but in my > opinion, they're not bugs that are severe enough to stop an upload of > qmail to unstable (or in my original thinking, to experimental.) I think that in general, any known bug of RC-severity should be sufficient grounds to keep a package from being accepted into the archive; tempered by concern that we not frustrate maintainers by moving the bar (i.e., if the maintainer has already had to reupload once to fix an RC bug, don't reject the package from NEW again because of other RC bugs that were overlooked in the first reject). So yes, if we're taking a decision delegated to us by the ftp team, I expect a certain measure of due diligence in identifying the critical bugs in the package. > It would have been nice for these issues to have been raised at some > point in the week which elapsed between me trying to advance the issue > and calling for votes or at least the two days between me sending a > ballot option and calling for votes so they could be properly > addressed. I thought a clear consensus had emerged from the BoF regarding the steps to be taken to move this bug forward, so I was unprepared for a change in status that required timely mail processing on my part. At any rate, having done my own review now of the data I'm mostly satisfied with moving this forward. I would still like to see Ian's input before I'm willing to change my own vote to move 'further discussion' down the list, though. > [As a process issue, is there some better way[1] to let > people know that someone is starting to get close to calling for > votes? Should we Cc: CTTE members directly or ping on IRC?] In my case, a subject line change marking out the fact that there's a draft up for consideration would go a long way to help me. Perhaps the "RFR" (request for review) ad "LCFC" (last call for comments) conventions in use by several of the Debian l10n teams would be suitable? But in general, any subject line change drawing attention to the fact that there's a draft would do the trick, so that it doesn't get lost amid an arbitrarily-sized set of other unprocessed mails on the thread. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature