[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: QA group best practice?



On Sat, Jul 26, 2003 at 11:14:12AM +0200, Raphael Hertzog wrote:
> Le Sat, Jul 26, 2003 at 02:31:17PM +1000, Matthew Palmer ?crivait:
> > I want to supply a patch to #202416 (developers-reference: mention QA in NMU
> > 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.
> >
> > * All changelogs should start with an entry "QA Upload".
> 
> Not really needed. This can be deduced from the maintainer field beeing
> set to debian-qa.

But what about when someone adopts the package?  I think it'd be useful to
be able to quickly go back to a previous release and say "aah, that was a
release made while it was orphaned".

Assuming the rest of the changelog entries are correct, you could deduce it
was QA by the previous "orphaned" and subsequent "new maintainer" entries. 
I just think it's a nice, easy identification method.

> > * Subscribe (at least temporarily) to the PTS list for the package after the
> > upload, in case your upload causes severe haemmhoraging.
> 
> Not really needed ... it's too much for a package which has no
> maintainer. There are people who are receiving the bugs and who aren't
> MIA and who will notice that there's a problem.

You don't think a 1-2 week subscription would be a good idea?  There's
always the possibility that you might have b0rked something ($deity knows
I've mucked it up once or twice).  You can use 'at' to auto-unsubscribe
after a while.

> > * 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
> 
> This is not specific to QA ... it's common sense. :)

Well yes, but the thing about common sense is that it's so uncommon.  <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
> 
> There's no full rulebook, just try to be short and on the point. And put
> it in devel-ref.

Mmmmkay.  The devel-ref will never look the same again...

- Matt



Reply to: