Re: QA group best practice?
On Sat, Jul 26, 2003 at 10:42:38AM +0200, Andreas Barth wrote:
> > > section). So I hunted around to find the list of best practices for QA
> > > uploads that I could base my update on. But I can't find any. So, I'm
> > > going to make some up.
>
> > Cool, I thought about doing something similar yesterday :)
>
> Yes, this is very helpfull. Can someone please put this list on a
> website?
If someone will give me qa group access on klecker, I'm quite willing to put
it up. Otherwise, any of the QA group can use my list on the site (or
something better).
> > > * Make sure you keep the comments in the BTS up to date. If you're working
> > > on a fix, say so. If you've got an upload in the pipeline, tag the bug
> > > pending. This minimises duplicated effort, and keeps a record of work done
> > > (as such, I think it's better than coordinating on -qa@l.d.o, which was my
> > > other possible suggestion).
>
> > If you just begin working on a patch I would prefer "confirmed".
> > I would use "pending" only for problems that are fixed but not uploaded.
>
> IMHO it should be able to mark a package as "it is currently being
> updated by one member of the QA-group". But this could perhaps be done
> by mail to qa, whereas tackling single bugs is better done via marking
> bugs as confirmed, pending or by mail to the bug log entry.
I'd say that "working on it" should be an e-mail to the bug. "Fixed,
preparing[1] an upload" should be tagged pending, and the bug gets closed on
successful upload.
> > What to do with the bugs after upload?> Should they stay "fixed", since
> > it is some sort of NMU or should they be closed?
>
> If you consider yourself as part of the QA-group (and especially are
> reached by mail to qa) than this is IMHO a normal maintainer upload.
Agreed. I'm not part of QA myself, so obviously I can't make the rules, but
I think that if you're willing to put the time into it, then you're pretty
much able to call your QA uploads maintainer uploads. At least, I've been
doing that so far. Making NMUs only increases the work for someone else,
IMHO.
Of course, if I've overstepped there, someone can tell me to stop being so
damned arrogant. <g>
> > > I'm planning on making a short speil on QA uploads to put into the
> > > developers' reference to satisfy #202416. I'm more varied about putting the
> > > full rulebook into the dev-ref. Should we give QA a higher priority by
> > > putting more about it into DR, or should most of it stay on qa.debian.org?
>
> > IMHO there should be something in the ref. At least the version
> > numbering, the "QA Upload" and the Maintainer should go in. The
> > PTS subscription is normal NMU stuff and the BTS handling could
> > also an agreement between the people here.
>
> IMHO it's important that with reading the DR a maintainer can get all
> important information, either direct or via links to qa.d.o.
OK, I think the leaning is towards putting more into the DR. I guess I'm
off to do a spot of docbook.
[1] FVO 'preparing' which equal "I've got it fixed, it's part of a set of
changes that I'm putting together for upload Real Soon Now".
- Matt
Reply to: