Bug#374738: developers-reference: [5.8.4] Only most recent section of changelog is considered
On Wed, Jun 21, 2006 at 07:47:43AM -0500, Kevin Glynn wrote:
> Justin Pryzby writes:
> > On Tue, Jun 20, 2006 at 08:48:08PM -0500, Kevin Glynn wrote:
> > > Package: developers-reference
> > > Severity: normal
> > >
> > > Section 5.8.4 should make it clear that only the most recent section
> > > of the changelog is significant for closing bugs. So, if one uploads
> > > version -11, followed by -13 bugs closed in the -12 section will not
> > > be picked up by daks and closed automatically.
> > This is controllable to various options to the dpkg-dev tools, eg.
> > dpkg-buildpackage -v, which presumably just passes it on to
> > dpkg-parsechangelog.
> It would be nice if this section explained that it was controllable at
> upload time.
> > > I suppose this is the scenario addressed by the line "To close any
> > > remaining bugs that were fixed by your upload, email the .changes
> > > file to XXXfirstname.lastname@example.org, where XXX is your bug number.",
> > > but I think this requires a bit more explanation.
> > Of course using the changelog is commonly preferred, for conformity;
> > this suggestion is just for the case that a previosly-reported problem
> > turns out to have been fixed which wasn't known to be so at thet time
> > of upload, especially for a package with many bugs, or for a new
> > upstream release.
> Aaah, I think I see. The .changes file doesn't have to explicitly say
> that it closes that bug.
Right; any message to -done will close a bug.
> The advantage of mailing the .changes is that it will nail the
> version where the bug was fixed, (and maybe give a hint why it was
Not really. The advantage of mailing the .changes file is that you
don't have to provide a different expalantion about why the bug was
closed to the submitter, and that it "looks" more uniform to the
normal (?) case that a bug is closed by an upload.
Mail to -done should include a "Version:" pseudoheader, now that the
BTS supports version tracking. This lets eg. the release team check
how many RC bugs are in the testing version, and does so without extra
work. In the .changes mails from katie (or whoever), this is:
Usually it is specified manually as just "Version: ". See: