Re: Migrating debian policy into a git repository
On Mon, 21 Apr 2008 20:39:19 -0700, Russ Allbery <rra@debian.org> said:
> Manoj Srivastava <srivasta@debian.org> writes:
>> The next proposal was to have per-member topic branches -- in other
>> words, every team member opens a new branch for each topic they are
>> working in, using branch names like bug12345-manoj. This way, it is
>> easy to see who is working on what, and which issues are being
>> considered for inclusion in the next release of policy.
>>
>> While usually only one of us works a topic for packaging, this scheme
>> allows there to be multiple solutions that can be discussed in
>> parallel, in case of need. It also allows people to create branches
>> without name space conflicts, simply.
>>
>> The topic branch bug12345-manoj is public, allowing for discussion;
>> people on the policy team can voice their approval on the mailing
>> list, and the branch owner can use git --amend to add in the approves
>> line into the HEAD.,
>>
>> When a consensus emerges, and the final wording exists in one of
>> these topic branches, it can be squished/rebased into master, and we
>> move on to the next issue.
> This sounds very good to me (I think the diagram included wasn't the
> right one, though). I like this idea.
First proposal: (too many repositories)
http://people.debian.org/~srivasta/policy_repo.png
Second proposal:(too much clutter in each devel branch, not
using cheap branches that git gves us)
http://people.debian.org/~srivasta/policy_repo_1.png
Current proposal:
http://people.debian.org/~srivasta/policy_repo_2.png
> Are we generally standardizing on using git merge --squash to merge
> those per-bug branches onto master?
That makes sense. No one needs to see the details of the chnages
we went through in the mainline; they can just go through the branch.
> Also, are we rebasing bug branches? Since they're public, I wasn't
> sure if that was a good idea, but I'm still a bit fuzzy on the
> strategies.
Well, we should not really need to rebase. If there are changes
in master; merge master into the bug branch. Fix any overlap
issues. _then_ merge --squash back into master. This will work, I
think.
> For simple build-system changes, typo fixes, fixes for references to
> external man pages and other informative changes, and the like, do we
> still use a branch or should Policy team maintainers just commit
> directly to master?
Depends on you, I guess. If feel like you want a review, create
a branch. Or else, just commit to master directly.
> What would help me a lot is if someone wrote up specific step-by-step
> git commands for the common operations on the repository. I want to
> understand the theory too, but I always understand theory better by
> starting from a practical set of instructions and then investigating
> further why things are working that way.
Well, I'll try and see if I can tackle a few bug reports this
weekend on policy. I'll post the steps after that.
manoj
--
If you can lead it to water and force it to drink, it isn't a horse.
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: