Re: The way to the next dpkg release
Hi, On Thu, Jan 19, 2006 at 08:16:10AM +0100, Christian Perrier wrote: One of the difficulties that I see with dpkg at the moment is that it has a very large bug list. Many of those bugs are very old, the use of tags is sometimes different from bug to bug, and the database could probably use either a good set of usertags or some bug title massaging (or possibly both). This is not exactly true. Scott did a huge amount fo bug triaging. He had his own ways to do so and I even imagine he documented them. Something may be lying around on www.dpkg.org...otherwise we'll ask him whether he has something written. There's debian/pseudo-tags in the sources, which some bugs report are using. That could be converted to usertags instead probably. I'm not sure if Scott was using that previously. regards, guillem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
On Wed, Jan 18, 2006 at 05:12:58PM -0800, Russ Allbery wrote: One of the difficulties that I see with dpkg at the moment is that it has a very large bug list. Many of those bugs are very old, the use of tags is sometimes different from bug to bug, and the database could probably use either a good set of usertags or some bug title massaging (or possibly both). I've been looking a little for a package to do bug triage on when I have the time, and this always looked like an excellent target if I had some guidelines as to what the maintainers wanted. Now seems like a great opportunity to come up with some guidelines so that some of the rest of us can pitch in and start getting the bug list down to something more reasonable. So, any general thoughts on a bug policy? Use of confirmed / patch / etc? Categories of bugs that we should create with usertags? One thing you probably could safely do it converting the current subject based tags to real usertags. That is mostly a assignment to certain programs and a few others (like assert). I think the use of unreproducible/moreinfo/patch/wontfix should be obvious. IMHO patch should be used rather defensively i.e. only if there is really a patch in there that is almost ready for inclusion. What do the others think about the use of confirmed? It could be used to have the bugs categorised in three categories (confirmed - unclassified - unreproducible) instead of two (unclassified - unreproducible). In case we want to use this tag I would propose that to tag a bug confirmed you need to add an explanation how to reproduce it. Especially for the old bugs in dpkg this sometimes is a big problem (as I know from my own triaging efforts on dpkg-dev) and so it might be worthwile to seperate those bugs that are definetly reproducible. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
There's debian/pseudo-tags in the sources, which some bugs report are using. That could be converted to usertags instead probably. I'm not sure if Scott was using that previously. No, he wasn't. The majorbug triage he did was before usertags existed. So, he used pseudo-tags and I agree those could be converted to suertags. About usertags, we should probably agree on one e-mail address to use, probably [EMAIL PROTECTED]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
Christian Perrier wrote: About usertags, we should probably agree on one e-mail address to use, probably [EMAIL PROTECTED]. Best thing is to use whatever address is listed in the Maintainer field then the usertags will be visible by default. -- see shy jo signature.asc Description: Digital signature
Re: The way to the next dpkg release
I intend to commit all translation updates that are lying currently in my archive, which will fix all bugs tagged ad l10n,pending Done in r15. I also commited a few other pending patches for translated man pages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
On Wed, Jan 18, 2006 at 06:07:39PM +0100, Christian Perrier wrote: Fair by me. And thanks for the great work. I intend to commit all translation updates that are lying currently in my archive, which will fix all bugs tagged ad l10n,pending I suggest that someone familiar with dpkg-dev has a look at #345475 and possibly commits the patch. It is currently badly needed for g-i, the graphical version of Debian Installer, as stated by Frans Pop, the D-I release manager... Of course you may already have done so, Frank, but, really, getting this bug fixed would be great for d-i development. Yeah, Frans also asked me a few days ago to look at it, so I already went in with r9 Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
On Wed, Jan 18, 2006 at 10:21:09PM +0100, Christian Perrier wrote: I also commited a few other pending patches for translated man pages. A question about man pages: Is there anything I need to do with the translated man pages when the English original changes? Or should I just wait for the translators to note by themself? (e.g. r9 and r12 changed English man pages) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
Frank Lichtenheld [EMAIL PROTECTED] writes: I propose the following timeline for the next release: Commit patches until Sunday January, 22th (5 days from now). This should give plenty of time to at least work through the backlog some of us have aquired (My own one can be seen at http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=fixed-in-my-arch-branch). Give a few days of testing at the beginning of next week. Upload around Thursday January, 26th. Comments, objections? I'm not entirely sure that I'm going to have time, so I'm a little hesitant to be volunteering, but since the details may help someone else even if I turn out not to have the time One of the difficulties that I see with dpkg at the moment is that it has a very large bug list. Many of those bugs are very old, the use of tags is sometimes different from bug to bug, and the database could probably use either a good set of usertags or some bug title massaging (or possibly both). I've been looking a little for a package to do bug triage on when I have the time, and this always looked like an excellent target if I had some guidelines as to what the maintainers wanted. Now seems like a great opportunity to come up with some guidelines so that some of the rest of us can pitch in and start getting the bug list down to something more reasonable. So, any general thoughts on a bug policy? Use of confirmed / patch / etc? Categories of bugs that we should create with usertags? -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The way to the next dpkg release
One of the difficulties that I see with dpkg at the moment is that it has a very large bug list. Many of those bugs are very old, the use of tags is sometimes different from bug to bug, and the database could probably use either a good set of usertags or some bug title massaging (or possibly both). This is not exactly true. Scott did a huge amount fo bug triaging. He had his own ways to do so and I even imagine he documented them. Something may be lying around on www.dpkg.org...otherwise we'll ask him whether he has something written. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
