[Top][All Lists]

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

Re: [Groff] commit policy

From: Meg McRoberts
Subject: Re: [Groff] commit policy
Date: Mon, 10 Mar 2014 22:22:49 -0700 (PDT)

Hi all,
I'm pretty much a lurker on the list -- I like to write using groff but I don't 
do macros and
tools work...

However, I am learning a bit about git, and working with some serious git 
masters.  The
flaw I see to Warner's proposed policy is that comments and discussions are not 
in the git repository for posterity.  We are using gerrit, which is a lovely 
review tool, in
conjunction with git and it's a rather lovely system.

Summary work flow:  when I commit something, it actually goes into a gerrit 
not the official git repository.  When I am ready, I do some rebasing and other 
and then type "git review" to put the document (or code) out for review.  I can 
people who need to review it but anyone is free to review it.

When you review, you can add comments to any line, and you can then mark your
review as a +1 ("Looks good to me but someone else needs to approve") or -1 (I'd
rather you not commit this in the current state).  The official approvers can 
also give
it a +2, which then moves it into the official git repository.

When you get -1 ratings, you can then go in and apply changes to satisfy the 
and do a commit --amend to amend that commit -- at that point, you can also 
modify the
comments associated with the commit -- either the short summary line or the 
commentary that can follow.

It all makes for a rather nice little system that preserves discussions and 
For example, you could add a comment to a commit like "Meg's suggestion to do 
was rejected because it would break 80% of the existing man pages in the world".

I'll go back to lurking now -- you guys who do the actual work should decide 
how you
do it but I think gerrit solves a major flaw that git has...


> From: Werner LEMBERG <address@hidden>
>To: address@hidden 
>Sent: Monday, March 10, 2014 9:41 PM
>Subject: [Groff] commit policy
>I suggest the following policy to avoid too much reverts in the
>repository: Global changes that influence the complete infrastructure
>of groff should be discussed on the list before committed.  In
>particular, this affects the build system, like compiler or Makefile
>settings, or libraries used by more than one application.
>Exceptions are trivial changes like fixing typos and the like.
>However, it's not easy to decide what is trivial and what not.  In
>case of doubt, please send the patch to the list for discussion.
>    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]