Re: [PATCH 1/1] Better document version ranking and 0
On Wed, 30 Apr 2008 12:22:53 -0700, Russ Allbery <rra@debian.org> said:
> Manoj Srivastava <srivasta@debian.org> writes:
>> I think the new commit goes on the branch, logically speaking, since
>> it is part of getting the branch ready. And we really have two
>> seconders sending in an ack, and we can record them separately,
>> unless they come in close together. In that case, the branch history
>> would be "proposed wording -- changes if any -- commit to show ack --
>> commit to show ack "; then git checkout master; git merge
>> bug12345-owner
> That makes sense, although we'll not want to commit changes to
> debian/changelog or a similar file on the branch until right before
> the merge or we'll get merge conflicts.
Good point. This is generally true of all ChangeLog style files
when you have development on different branches, and ./debian/changelog
is no exception.
> I'm still a little unclear on what commit messages the Acked-by lines
> go into if there are several staggered over a period of time. A
> typical working branch would have a few commits:
> 1. The initial wording proposal.
> 2. Additional tweaks to the wording as needed.
> 3. The final pre-merge commit with debian/changelog entires and
> whatnot.
> Adding the Acked-by lines into the commit message for 3 makes sense to
> me. That's the commit that declares the branch "final" and includes
> the metadata saying that it's going into the next Policy release (the
> debian/changelog and upgrading-checklist changes), so that's an
> appropriate point to record the seconds.
> But if we want to record a second in an intermediate commit between 2
> and 3, what would we actually be committing? Making some change to a
> shared file like debian/changelog seems to me to be just asking for
> merge conflicts.
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.
>> Under gitk, all the development, acks, etc can be seen on the line
>> belonging to the branch, and then when all is set, the branch is
>> merged in to master.
>>
>> At this point, master is merged into all the pending bug branches by
>> the owners, a git diff master bug12345-owner will show the exact
>> changes being proposed by the unmerged branch.
> Right. Something like:
> for branch in `git branch | egrep 'bug[0-9]+-rra'`; do
> git checkout "$branch" && git merge master
> done
> I'm not sure how to suppress the * in front of the default branch.
> I'm sure there's some way, but running the above from master should be
> safe.
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
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---
manoj
--
You are in a maze of little twisting passages, all alike.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: