Re: BTS and unreleased changelog entries
On Sun, Oct 15, 2017 at 12:14:59AM +0200, Mattia Rizzolo wrote:
> > Thanks for the hint. dpkg-genchanges(1) says -c requires a version. Is
> ~~~~^
> I'll assume this is a typo and you meant -v
whoops yes!
> > there a downside to always starting from the first release?
>
> Yes, you'd always be putting in the .changes all of the changelog, spam
> debian-devel-changes@ with all the changelog all of the time, and trying
> to close all the bugs you closed in the past with every each upload.
Oh I didn't know about debian-devel-changes - spamming folks who'd like
to read such things would be a bummer.
I asked because I was surpsied this isn't automatic - as an
inexperienced packager, it's sometimes frustraing to learn about yet
another obscure flag to yet another dpkg-something that is only
occasionally needed.
> Rather, I have a counter-question for you: why are you keeping entries
> for unreleased uploads in d/changelog? I find it rather confusing,
> mostly useless and with no real upsides as opposed to cohalesce the
> entries.
Good question. I guess I think of a changelog as history - so changes I
made on 1.15 go with 1.15 whether it was released or not. But if I
think of the changelog as telling others about changes in a release,
then it makes sense to squash them.
Either way, I try to avoid it now. So it's really just dealing with the
previous entries. Sounds like I just need one upload to be done with an
early enough -v. And then avoid keeping unreleased versions around in
the future.
> To avoid doubts: the -v option is there because of how in the past NMUs,
> experimental uploads (and few other things) were handled. And currently
> it's useful for backports (despite (sadly, imho) not required anymore),
> and for stable uploads when the upload takes all the uploads done to
> unstable, not to deal with UNRELEASED entries.
Ah interesting, the context here is useful to know.
Thanks for the help,
Ross
Reply to: