Lucid Packaging and QA

[Harald Sitter]

Am Montag, 11. Januar 2010 00:26:39 schrieb Richard JOHNSON:
> QA. Everyone's favorite topic, but a topic that hasn't been carried through
> with in some time. I was going through some bug reports messing around with
> a script or 2 from Brian Murray and friends, and something I noticed was
> prior uploads/releases should have closed out reports. I would greatly
> appreciate it, and I am sure everyone else would as well, if you could go
> through the bugs for the package you are uploading, and see if it fixes any
> of the open issues. If it does, close the bug via the Debian changelog.
> Granted this will take a little more time, but I don't see why we are
> constantly rushing to get packages uploaded.

Most of the time you do not know which bugs might be fixed by just looking at 
their subject, so you need to digg in and check (which in case of say kdebase-
workspace will take at least a day).
So I think in order to carry that out first strong bug triage must be 
established so that the triagers have time to care about stuff like making the 
subject reflect a bug's actual root.

> Speaking of bug reports, we have a ton, and then another ton that seem
> stale/outdated/no longer an issue. Seeing as we do have a small developer
> team, maybe it is time we start doing some Hug Days and trying to get
> people involved. It is working quite well with KDE, and typically the group
> that shows up isn't always the largest, but they are all working together
> and cleaning up the bug lists. We need this badly, and I would be wicked
> happy to help out however I can. With that said, I know I need to put up or
> shut up, and would be happy helping lead a Hug Day and what not. With out
> current development configuration with bzr and all of that, I find it a bit
> of a pain to really do work that is as efficient as possible. I am trying
> to get a good workflow going, and that will help me with working on bug
> reports and fixing stuff at the same time.

We could always start off with triage-only I suppose?

> Another thing I am finding difficult is trying to work on a bug, checking
> out the source, only for it to change while working on fixes. This kind of
> goes hand-in-hand with trying to push packages a bit to fast and without
> much of any QA going on in that process. I found myself rushing a package
> recently and uploaded it without even looking at the copyright file, which
> means the copyright file was never touched after doing a dh_make. One thing
> I have noticed is it seems we have gotten better of not uploading packages
> that are trying to overwrite another one, but on some things I worked on
> recently, there was an exhaustive list of list-missing items that should
> have either a) been included or b) documented in a not-installed file.

If I had server resources and what not I would have dropped a QA suite months 
ago, epsecially the list-missing stuff is pretty easy.

-- 
Harald Sitter
Kubuntu Core Developer
http://www.kubuntu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20100113/5145b2e9/attachment-0001.pgp