Use of "UNRELEASED" in debian/changelog
Hello.
I asked Andreas if it was acceptable to join this team
just to work on minor QA issues, and he said yes,
so here I am :-)
To start, I want to fix #1030885 in python-cogent, in both
unstable and stable. This is in fact the prototype
of thing I want to do, mainly to ensure that there
are no FTBFS bugs in stable.
I have a minor doubt: If I follow debian-med policy strictly,
or just try to imitate what I see in other commits, this would
involve the following two commits:
- One commit to fix the bug and add a new debian/changelog entry
saying "UNRELEASED".
- Another one which changes "UNRELEASED" to "unstable" for the upload.
My question: Would it be acceptable to do this instead?
- One commit fixing the bug and doing nothing else.
- One commit which updates debian/changelog for the
new upload.
I believe, but I'm not sure, that some teams, or some tools,
allow this workflow, where the debian/changelog is automatically
populated from the git changelog entries themselves only at
upload time.
The advantage would be that I could just cherry-pick the
commit which actually fixes the problem when I do
the same for bookworm.
So: Would this be ok? I can think of several possible answers:
(A) No.
(B) Yes, but only if you don't keep the package in a half-fixed state,
i.e. only if you do all that at nearly the same time, including the tag
and the new upload, so that we don't have changes in master
without their debian/changelog entries.
(C) Yes in either case.
My second and last question:
To fix this in stable, I would create a branch called "bookworm"
from the master commit matching the stable version and put
the appropriate changes there.
Just to be sure: The name of the branch would be "bookworm",
not "master/bookworm" or anything like that, right?
Is there any caveat I should take in account for the stable fix?
Thanks.
Reply to: