couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [PROPOSAL] tag our commits
Date Sun, 05 Jan 2014 10:12:55 GMT
On Wed, Dec 4, 2013 at 6:45 PM, Noah Slater <> wrote:

> Consolidating my replies to a single email so as to limit mail churn. :)
> On 4 December 2013 18:33, Benoit Chesneau <> wrote:
> > Having tags force naturally people to[...]
> > Having tags force people to[...]
> > If the system if it's optional it lost any interest. People that don't
> want
> > to use it won't use it and we will stay with the same soup and
> meaningless
> > commit messages forcing people to read the full change to figure.
> Guidelines do not force anything. If something is confusing or people
> don't like it, it will be ignored.

If you ignore a guideline then it should be discussed rather than being
ignored. By forcing here I am just expecting that people really take care
about guidelines and their spirit and then pay attention to it even if they
don't follow them strictly.

> > a tag should be related to the feature it patches
> I think this sounds like a good idea. But we should recommend that
> people tag the one-line comment with any major system that is
> effected. But it should not be compulsory to do so.

Actually it should be good that we tag the commits. I can still see a lot
of commits that force me to look at the code because the description is
vague or lack of the context to see if I should backport it in a test
branch or not. Which is to say less a big time killer. I agree that
sometimes a tag is too much restrictive anyway so it may be just a matter
of having for rule to make the first line really descriptive (a tag most of
the time will figure what is the comment context).

If we are speaking of guideline I really think that a code should go in a
review branch before landing in the master so eventually the comment could
be corrected and some patches rebased. It's really painful to handle a
change is that is fixing a change that was fixing a change that was fixing
another.... Each time  you backport it (for tests or productions) it imply
that you relaunch tests. And I am pretty sure that most of the time such
commits could be skipped in the master if the code was reviewed.

> >> And let's say we want to accept a pull request on Github that adds foo
> >> atomically. Are we really going to send the person away and ask them
> >> to decompose the commit into many commits, each one with a tag?
> >>
> >
> > yes. This is a good practice.
> This is the opposite of every pull request I've ever seen. (Which is,
> admittedly, not many.)

You can see on github that a lot of PR are composed of many commits, most
of the time corresponding to one change that can affect the code deeply. It
is really a good practice to separate commits in an atomic way, so a
serious review can be done so that the accepted  changes (if any) don't
imply to have to review another big patch.

- benoit

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message