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.
