The way to the next dpkg release

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

The way to the next dpkg release

Frank Lichtenheld
Hi.

I've now committed the current release 1.13.11.1 to
svn+ssh://svn.debian.org/svn/dpkg/trunk which we will use
as a preparation ground for the next upload. Guillem,
Christian, Brendan and I have been added to the Alioth
project and should have commit access.

I like to point the commit messages somewhere, either
the existing [hidden email] or a list set up
via the Alioth project. Currently I send them to
[hidden email] but I've yet to see a mail
arriving from there in my inbox so I'm not sure it
is indeed working...

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/pkgreport.cgi?users=djpig@...;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?

P.S. It might be good to read
http://www.dpkg.org/ArchRepository/CommittingChanges
as a reminder about changelog formats before commiting.

Gruesse,
--
Frank Lichtenheld <[hidden email]>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Christian Perrier
> 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/pkgreport.cgi?users=djpig@...;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?

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.

I'm way too much incompetent for judging if the patch is "right" or
not, so leaving this to you....






--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Christian Perrier

> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Frank Lichtenheld
In reply to this post by Christian Perrier
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 <[hidden email]>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Frank Lichtenheld
In reply to this post by Christian Perrier
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 <[hidden email]>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Russ Allbery-2
In reply to this post by Frank Lichtenheld
Frank Lichtenheld <[hidden email]> 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/pkgreport.cgi?users=djpig@...;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 ([hidden email])               <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Christian Perrier
> 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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Guillem Jover
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 [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Frank Lichtenheld
In reply to this post by Russ Allbery-2
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 <[hidden email]>
www: http://www.djpig.de/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Christian Perrier
In reply to this post by Guillem Jover
> 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 "[hidden email]".



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: The way to the next dpkg release

Joey Hess
Christian Perrier wrote:
> About usertags, we should probably agree on one e-mail address to use,
> probably "[hidden email]".

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 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

E-mail address for usertags

Christian Perrier
Quoting Joey Hess ([hidden email]):

> Best thing is to use whatever address is listed in the Maintainer field
> then the usertags will be visible by default.


Ah, that's an interesting feature I wasn't aware of.

CC'ing the maintenance teams I'm part of....Do not CC them in answers,
please

I wonder then if bts could support displaying these "Maintainer"
usertags. I use it a lot while offline after caching bugs when I'm
online....



--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]