[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Migrating debian policy into a git repository


        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

        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

        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

PNG image

        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.

PNG image

        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. 

PNG image

        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.

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: