Migrating debian policy into a git repository
Hi,
I have imported all the arch history of the debian policy into a
git repository at http://git.debian.org/dbnpolicy/policy.git, and which
can now be browsed at
http://git.debian.org/?p=dbnpolicy/policy.git;a=summary
This repository contains three branches,
master -- The mailine branch which defines policy
rra -- A historical record of Russ's arch branch
srivasta -- A historical record of myarch branch
The last two branches are mostly for history; I do not expect to
update my branch moving forward.
Talking about moving forward, I have been thinking about how the
policy delegates should manage the git repository, and here follows my
proposal.
Firstly, let me mention that I have looked at the mailing list
centric work-flow used by the Linux kernel, and the development of git
itself. These development efforts revolve around a vigorous, rapid
action, low latency mailing lists, and involve development discussions
based on mostly private topic branches, with patches mailed to the
lists, and perhaps incorporated into local branches for testing. There
is an active manager (Linus for his tree, Andrew Morton for the mm
tree, etc).
Experience tells us that the Debian policy is not like that, we
have long hiatuses in moving a policy proposal forward, most of our
discussion is focussed around the BTS, and we have a policy process,
and usertags and categories to mark progress along that process. I do
not want to discard that.
Given that, this is the first workflow I can up with. This
proposes that the master branch on
http://git.debian.org/dbnpolicy/policy.git be the official policy, and
each develoepr gets a private branch, and each developer then publishes
their own branch on git.debian.org. This way, every one can see what
each person is working on, and we can ask for commentary on work in
progress.
The problem with this design is that there are too many
repositories, for N policy delegates, you have N + 1 public
repositories, along with N private ones, that is way too much. This
lead to the second draft, where we just have one public and N private
repositories, and every policy team member gets a branch in the public
repository. This also involves continuing the srivasta and rra branches
in the main repo, and adding branches for each team member.
This is better, but will lead to clutter in each developer
branch over time, as different topics get worked on. It is also harder
to see who is working on each topic.
You see, the way we process issues with Debian policy is by
assigning a bug report to each topic, and working our way through the
topic using BTS tags and such. But we work on each topic separately,
this will not be the case if each team member is using just one
branch -- and working several issues at one time. Therein lies madness.
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.
manoj
--
While in the same way that rain cannot break into a well-roofed house,
desire cannot break into a mind that has been practising meditation
well. 14
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: