Re: [PATCH 1/1] Better document version ranking and 0
Manoj Srivastava <srivasta@debian.org> writes:
> We can adopt a policy of recording the proposer and seconder of
> an change in ./debian/changelog; as well as the commit message; since
> really, unlike code, wording proposal and review are integral to good
> policy development, and people who do so deserve to be visble in the
> Changelog. This gives us a snippet to add to the changelog, but then it
> means as we merge in different branches, we get conflicts in the
> changelog.
>
> The only clean way I can see is a departure from convention:
> create ./debian/changes/YYYY-MM-DD-Bug1234 files, in which we
> record proposer, and seconder, and title of the change. Each branch
> then introduces a new file, which is added to by every second, and can
> be used later for copyright. It also gets all the other
> ./debian/changelog contributions, and thus ./debian/changelog is not
> changed in any branch. When branches are merged in, ./debian/changelog
> is edited, bugs are closed, and we add a tag, and upload -- and then
> push.
>
> But while clean, this seems very heavy handed, we can just keep
> the seconds in uncommited changes around, and only merge them in step
> 3 above. I am unsure which way to go.
To keep things simpler to start with, what I propose is that we track
seconds in the BTS until we've gotten enough to warrant merging the
proposal. Then, right before merging, we'll make a final change to the
branch to add the debian/changelog entry with proposer and seconds, add
the seconds to Acked-by lines in the commit message, and add the
upgrading-checklist entry if appropriate. Then we'll immediately merge
that branch and update the BTS tags.
So, for example, with this bug, I propose a changelog entry of:
* Policy: better document version ranking and empty Debian revisions
Wording: Russ Allbery <rra@debian.org>
Seconded: Raphaël Hertzog <hertzog@debian.org>
Seconded: Manoj Srivastava <srivasta@debian.org>
Seconded: Guillem Jover <guillem@debian.org>
Closes: #186700, #458910
or in general:
* <document>: <brief change description>
Wording: <author of wording>
Seconded: <seconder>
Seconded: <seconder>
Closes: <bug numbers>
This may be more verbose and more formal than is really necessary, but
it's also clear and simple and easy to do without having to think about
"okay, what should the changelog entry be," which is an advantage. It's
also potentially something we can generate from the Git log if we ever
wanted to later.
> How about this:
> --8<---------------cut here---------------start------------->8---
> for i in .git/refs/heads/*; do
> j=$(basename $i)
> if [ "$j" != "master" ]; then
> git checkout $j && git merge master
> fi
> done
Oh, yeah, that works. This looks right for doing after every commit or
merge to master.
> sensible_editor ./debian/changelog # add in ./debian/changes/<newfiles>
> <<build and test here>>
> git tag -s v3.8.0.0
> git push origin
> --8<---------------cut here---------------end--------------->8---
Yup, that looks right for a release, although as noted above, I propose
that we not use debian/changes for right now and instead just do a final
commit to the branch before merge that includes the changelog entry. So
for a release, the changelog change would only be to finalize the
changelog entry (add the correct date, etc.).
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: