[Amavisd-new-debian-devel] Closing but reports #530745 and #599514

[Harald Jenny]

On Sun, Aug 07, 2011 at 03:10:15PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 07 Aug 2011, Harald Jenny wrote:
> > On Fri, Jul 29, 2011 at 10:42:28PM -0300, Henrique de Moraes Holschuh wrote:
> > > Oldstable is less of a problem (so I'm not
> > > going to complain about it), but can still mislead some users into not
> > > being able to find a problem in their oldstable installs.
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=530745
> > Here it's obvious that the bug was closed before stable
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599514
> > Here the info about the fix is in the bug report itself (and verified by
> > looking at the mailing list archives).
> > 
> > But if you think it's better to keep the bug reports open until support for
> > Lenny is being dropped that is ok for me too, I'm just an uploader who wants to
> > act policy compliant.
> 
> Well, if we always version the closing of a bug, the BTS will take care of
> the book-keeping itself, and eventually archive any bugs that are closed on
> all branches it knows about.

Ah ok so I will close the corresponding bugs but the won't get archived until
Lenny support ist dropped correct?

> 
> > Well to be honest I think that this problem was introduced before me getting
> > involved:
> 
> Probably.  I was just providing an example, since you asked about it.

Thanks

> 
> > I suspect that this message caused the wrong tree - I will correct it now, 
> > should I reopen the bug too?
> 
> The BTS is rather smart nowadays, it will reopen when necessary.

Yes I just realized it

> 
> Something else to keep in mind is that we have to be rather diligent on the
> changelogs, and never lose changelog entries.  When doing separate
> branches (e.g. stable-updates) which contains backports of other branches
> (e.g. unstable), we must include the relevant changelog entries, otherwise
> the BTS can get quite confused.   It depends entirely on the changelog to
> build the version graph.

Well in the automated case this is true for sure, but when necessary it can
also be done by hand.

> 
> I don't think we ever had such problems in amavisd-new, but I once screwed
> it up in intel-microcode, and suddenly some bugs started showing up as
> active again due to a missing changelog entry.  A new upload with a fixed up
> changelog took care of it.

Ok thanks for this information

> 
> -- 
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh