Commit netiquette.

Commit netiquette.

[Óscar Fuentes]

It would be a Good Thing (TM) to explicitly set good practices for
commits. People is accustomed to CVS and following those customs with
changeset-based systems like Bazaar is counterproductive. VC history,
like code, is written once but read a thousand times, so it is worth to
write it with some care. A correct VC history can be exploited by tools
that traverses it doing useful things (i.e. `bisect').

Let's look at one example:

revno: 99513
committer: Mark A. Hershberger <mah@everybody.org>
branch nick: local
timestamp: Wed 2010-02-17 16:39:21 -0500
message:
  2010-02-17  Mark A. Hershberger  <mah@everybody.org>
  
  	* vc-bzr.el: fix typo in Known Bugs section.
  
  	* isearch.el (isearch-update-post-hook): New hook
  	(isearch-update): Use the new hook.
modified:
  lisp/ChangeLog
  lisp/isearch.el
  lisp/vc-bzr.el

The Committer used the full Changelog entry as the commit message, so on
interfaces that just shows the first line of the commit (like the
emacs-diffs mailing list or the output of `bzr log --short' or `qlog')
you see

2010-02-17  Mark A. Hershberger  <mah@everybody.org>

which is hardly indicative of the change.

Ideally, the commit message should be made of a first line indicating
the *purpose* of the change plus a longer text with a more complete
explanation. Usually the changelog entry is good enough as the complete
explanation (without the changelog's entry header!). If the changelog
entry contains only one line and it is descriptive of the purpose of the
change, it can be used as the commit message. In this case, it is
preferable to remove the leading asterisk because it just adds noise and
some text-based tools use asterisks for denoting nodes on the DAG.

Another very important thing is to realize that a changeset-based VCS
presents a view of the progress as a series of atomic steps that changes
the content of the project. This is good because it allows to
unambiguously establish the state of the project at certain point and
identify the steps that caused that state. For this to be really useful,
it is very important to not divide a change among several commits
(i.e. by doing a commit for each edited file) and to not mix different
changes on the same commit, as the case above.

Re: Commit netiquette.

[Glenn Morris]

Óscar Fuentes wrote:

> It would be a Good Thing (TM) to explicitly set good practices for
> commits.

Like admin/notes/commits?

But nobody reads admin/notes/.

Re: Commit netiquette.

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> Óscar Fuentes wrote:
>
>> It would be a Good Thing (TM) to explicitly set good practices for
>> commits.
>
> Like admin/notes/commits?

It's good, although I miss there some statement about not mixing
heterogeneous changes on the same commit.

> But nobody reads admin/notes/.

It is not the most visible place. And how many Emacs hackers watch it
for changes?

Re: Commit netiquette.

[Glenn Morris]

Óscar Fuentes wrote:

> And how many Emacs hackers watch it for changes?

No idea. But anyone who doesn't know by now what they are supposed to
do probably either doesn't read emacs-devel, or has tuned out all the
version control discussion, so you might just want to mail Mark and
anyone else who slips up directly, or at least cc them.

(I don't know what isearch-update-post-hook has to do with a feature
freeze either.)

Re: Commit netiquette.

[Chong Yidong]

Glenn Morris <rgm@gnu.org> writes:

> (I don't know what isearch-update-post-hook has to do with a feature
> freeze either.)

Mark, can you explain the motivation for this change?  If not, I am
going to revert it.

Re: Commit netiquette.

[Alfred M. Szmidt]

   revno: 99513
   committer: Mark A. Hershberger <mah@everybody.org>
   branch nick: local
   timestamp: Wed 2010-02-17 16:39:21 -0500
   message:
     2010-02-17  Mark A. Hershberger  <mah@everybody.org>

	   * vc-bzr.el: fix typo in Known Bugs section.

	   * isearch.el (isearch-update-post-hook): New hook
	   (isearch-update): Use the new hook.
   modified:
     lisp/ChangeLog
     lisp/isearch.el
     lisp/vc-bzr.el

   The Committer used the full Changelog entry as the commit message, so on
   interfaces that just shows the first line of the commit (like the
   emacs-diffs mailing list or the output of `bzr log --short' or `qlog')
   you see

   2010-02-17  Mark A. Hershberger  <mah@everybody.org>

   which is hardly indicative of the change.

This seems more of a short comming in `bzr log --short' than in the
way one writes commit messages.  A commit message is more than a
single line.  And the purpose of a change is always more suitable in
the actual code as a comment.

Re: Commit netiquette.

[Mark A. Hershberger]

Chong Yidong <cyd@stupidchicken.com> writes:

> Mark, can you explain the motivation for this change?  If not, I am
> going to revert it.

I wasn't aware of the freeze.  I do scan emacs-devel, but I don't have
time to keep up with every message.

The motivation for the change was to allow the user to modify how the
display is updated after each successive keystroke to isearch.

The specific case that I was looking at using loccur.el
(http://sf.net/projects/loccur) to display only lines that match the
current string.  This allows you to easily see all matches in the
current buffer without scrolling around too much.

This specific case seemed to point to hint at other ways the isearch
display could be updated dynamically, so I thought a hook would be
useful.

If causes a problem WRT the freeze, then it should be reverted.

Mark.

-- 
http://hexmode.com/

The only alternative to Tradition is bad tradition.
                          — Jaraslov Pelikan

Re: Commit netiquette.

[Juanma Barranquero]

On Thu, Feb 18, 2010 at 15:45, Alfred M. Szmidt <ams@gnu.org> wrote:

> This seems more of a short comming in `bzr log --short' than in the
> way one writes commit messages.  A commit message is more than a
> single line.  And the purpose of a change is always more suitable in
> the actual code as a comment.

You're conflating quite different things. If I update my tree with
"bzr up", obviously I'm not going to go looking at the code to know
which changes were made, but I certainly will do "bzr log --line -l10"
to see recent changes and their purpose.

And it is ridiculous to say that it is a "shortcoming" of log --short.
--short or --line are a convenience; making sure that the first line
of the commit log summarizes the change is just being nice to fellow
developers. You can always see the full log if you want; is not like
following the recommendation somehow impedes you from writing as long
a commit message as you want.

We currently *have* policies about ChangeLog entries and commit logs,
so I agree with Óscar: it is a good practice and we should require
people to follow it; and treat people who doesn't the same way we
treat people who mangles ChangeLog entries (that is, a gentle but firm
reminder that we have guideliness and we're all expected to follow
them).

    Juanma

Re: Commit netiquette.

[Mark A. Hershberger]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Let's look at one example:
>
> revno: 99513
> committer: Mark A. Hershberger <mah@everybody.org>

Can I just say how honored I am to serve as an example, twice now, for
everyone?

Hopefully everyone else can learn from my mistakes and avoid them!

Mark.

-- 
http://hexmode.com/

The only alternative to Tradition is bad tradition.
                          — Jaraslov Pelikan

Re: Commit netiquette.

[Óscar Fuentes]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    The Committer used the full Changelog entry as the commit message, so on
>    interfaces that just shows the first line of the commit (like the
>    emacs-diffs mailing list or the output of `bzr log --short' or `qlog')
>    you see
>
>    2010-02-17  Mark A. Hershberger  <mah@everybody.org>
>
>    which is hardly indicative of the change.
>
> This seems more of a short comming in `bzr log --short' than in the
> way one writes commit messages.  A commit message is more than a
> single line.

This is like saying that "Subject" fields on e-mail messages are of
little use, that one always ought to look at the body of the message
before deciding if it is an interesting one.

> And the purpose of a change is always more suitable in the actual
> code as a comment.

Sure, but describing the purpose on the commit message is useful too,
mostly when the change is not circumscribed to a single point on one
file. Very handy for using with `annotate'.

On this respect I find changelog entries as a lame way of documenting
changes. Most of the time a changelog does not give more information
than what I quickly get combining `log' and `annotate', except when the
changelog entry documents the purpose of the change (not only *what*
changed) but this rarely happens. On projects that extensively use the
commit messages for documenting changes, using `log' and `annotate' is a
great learning tool when you are getting familiar with the code base.

Re: Commit netiquette.

[Stefan Monnier]

>> This seems more of a short comming in `bzr log --short' than in the
>> way one writes commit messages.

Not really: it's the whole idea behing "bzr log --short".

> We currently *have* policies about ChangeLog entries and commit logs,
> so I agree with Óscar: it is a good practice and we should require
> people to follow it; and treat people who doesn't the same way we
> treat people who mangles ChangeLog entries (that is, a gentle but firm
> reminder that we have guideliness and we're all expected to follow
> them).

Yes, please, we should require the first line of commit messages to be
an acceptable summary of the whole changeset.

Could someone update log-edit-mode's font-lock patterns so that the
first line is highlighted specially (at least in the Bzr and Arch
cases)?

I think log-edit-mode should even go further in this direction.
The buffer should be created as

  ----------------
  Author: 
  Summary: 

  blablabla
  ----------------

where <blablabla> is the text taken from the ChangeLog.  Then for
backends which support the notion of summary-line, C-c C-c could just
signal an error if the Summary line is still blank.
After that, empty header entries will get removed and the text is passed
as-is to the backend who is then free to pass it as-is to the underlying
VCS or to extract the various fields and do whatever it feels like
with them.


        Stefan

Re: Commit netiquette.

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > On this respect I find changelog entries as a lame way of documenting
 > changes.

Some senior developers are used to this method, and they are already
familiar with the code base.  It works well enough, regardless of your
opinion.

The real issues you should be pointing to are (1) accurate commit log
messages are an excellent way to learn about the code base, so the
Emacs infrastructure (edit-log, vc) should try to ensure that commit
logs are as detailed as ChangeLog entries, and (2) ChangeLogs are a
minor but very persistent annoyance (especially to people doing
integrative work, like the maintainers) because they *very* frequently
require special handling, such as merge conflict resolution.

(1) should be easy enough to achieve, but (2) will require balancing
the interests of those used to ChangeLogs with their deficiencies.

Re: Commit netiquette.

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

On Feb 18, 2010, at 11:14 AM, Stefan Monnier wrote:
> After that, empty header entries will get removed and the text is passed
> as-is to the backend who is then free to pass it as-is to the underlying
> VCS or to extract the various fields and do whatever it feels like
> with them.

Could one not just add all new commit messages to the appropriate ChangeLogs automatically, maybe once a day?
With the switch to Bzr, the ChangeLog files are the anachronisms, so they could be what's derived from the primary log.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: Commit netiquette.

[Stefan Monnier]

> Could one not just add all new commit messages to the appropriate
> ChangeLogs automatically, maybe once a day?  With the switch to Bzr,
> the ChangeLog files are the anachronisms, so they could be what's
> derived from the primary log.

Please people stop it.  We said we'll first switch to Bzr without
changing the ChangeLog policy.
Many people haven't yet figured out how to use Bzr on their system to
access the repository, so clearly it's not yet time to look at the
next step.


        Stefan

Re: Commit netiquette.

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>    2010-02-17  Mark A. Hershberger  <mah@everybody.org>
>
>    which is hardly indicative of the change.
>
> This seems more of a short comming in `bzr log --short' than in the
> way one writes commit messages.  A commit message is more than a
> single line.

It's also more or less a universal convention among all modern
source-control systems, so it would be pretty silly to ignore it...

-Miles

-- 
Run away!  Run away!

Re: Commit netiquette.

[Alfred M. Szmidt]

   >> This seems more of a short comming in `bzr log --short' than in the
   >> way one writes commit messages.

   Not really: it's the whole idea behing "bzr log --short".

bzr log could create a short output in some other fashion, one line is
always often to short to explain a change anyway so this option does
not do much good.

   Could someone update log-edit-mode's font-lock patterns so that the
   first line is highlighted specially (at least in the Bzr and Arch
   cases)?

   I think log-edit-mode should even go further in this direction.
   The buffer should be created as

     ----------------
     Author: 
     Summary: 

     blablabla
     ----------------

   where <blablabla> is the text taken from the ChangeLog.  Then for
   backends which support the notion of summary-line, C-c C-c could
   just signal an error if the Summary line is still blank.

That seems overly forceful, emacs is not just by emacs developers, it
is used by an immense number of people.  There have been many changes
done recently that have not been thought through, nor discussed with
those who use emacs.  Please stop making such rash decisions; remeber
such changes not only affect you by anyone who uses emacs.

   After that, empty header entries will get removed and the text is
   passed as-is to the backend who is then free to pass it as-is to
   the underlying VCS or to extract the various fields and do whatever
   it feels like with them.

This will not help those who use C-c C-a in vc-mode.

A sensible way of attacking the problem would be to have a frob,
log-edit-message-style, this could be set using .dir-locals.el, per
file, or in .emacs.  It would affect how C-c C-a behaves, if it
inserts a ChangeLog entry the standard way, or if it also adds an
header.

Re: Commit netiquette.

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 594 bytes --]

   > This seems more of a short comming in `bzr log --short' than in
   > the way one writes commit messages.  A commit message is more
   > than a single line.  And the purpose of a change is always more
   > suitable in the actual code as a comment.

   You're conflating quite different things. If I update my tree with
   "bzr up", obviously I'm not going to go looking at the code to know
   which changes were made, but I certainly will do "bzr log --line
   -l10" to see recent changes and their purpose.

That is the whole idea of a ChangeLog, a short message doesn't
substitute it.

Re: Commit netiquette.

[Juanma Barranquero]

> That is the whole idea of a ChangeLog, a short message doesn't
> substitute it.

"bzr log --line" and "C-x C-f ChangeLog <RET>" are different
operations. We're talking about the use of the bzr tool (including
graphical interfaces), not about ChangeLog.

Most people seem to agree that the one-line summary is a nice thing to
have in some contexts. Are you going to go against policy?

    Juanma

Re: Commit netiquette.

[Stefan Monnier]

>      ----------------
>      Author: 
>      Summary: 

>      blablabla
>      ----------------

>    where <blablabla> is the text taken from the ChangeLog.  Then for
>    backends which support the notion of summary-line, C-c C-c could
>    just signal an error if the Summary line is still blank.

> That seems overly forceful, emacs is not just by emacs developers, it
> is used by an immense number of people.

I don't see a problem with that.  Some people already asks to be able to
commit without having to go through the log-edit step, so the same
config var can be used to decide whether empty commit messages are
accepted (since they currently are, that would most likely be the
default value, which we could modify in the emacs/.dir-locals.el).

BTW, such "enforcement" is useful for a lot more than Emacs's developers.

>    After that, empty header entries will get removed and the text is
>    passed as-is to the backend who is then free to pass it as-is to
>    the underlying VCS or to extract the various fields and do whatever
>    it feels like with them.

> This will not help those who use C-c C-a in vc-mode.

I don't see how that interacts.  Clearly C-a C-a would bring the text
into the body part of the message.  Am I missing something?


        Stefan

Re: Commit netiquette.

[Chong Yidong]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>      ----------------
>>      Author: 
>>      Summary: 
>
>>      blablabla
>>      ----------------
>>
>>    After that, empty header entries will get removed and the text is
>>    passed as-is to the backend who is then free to pass it as-is to
>>    the underlying VCS or to extract the various fields and do whatever
>>    it feels like with them.
>
>> This will not help those who use C-c C-a in vc-mode.
>
> I don't see how that interacts.  Clearly C-a C-a would bring the text
> into the body part of the message.  Am I missing something?

Also, this kind of behavior works perfectly fine in message-mode, in
commands such as C-c C-y.  So there is ample precedent.

(I wonder if it might not be possible to re-use some of the mail-header
code to implement this idea.)

Re: Commit netiquette.

[Chong Yidong]

"Alfred M. Szmidt" <ams@gnu.org> writes:

>      ----------------
>      Author: 
>      Summary: 
>
>      blablabla
>      ----------------
>
>    where <blablabla> is the text taken from the ChangeLog.  Then for
>    backends which support the notion of summary-line, C-c C-c could
>    just signal an error if the Summary line is still blank.
>
> That seems overly forceful, emacs is not just by emacs developers, it
> is used by an immense number of people.

I don't think it should issue an error, but it should prompt the user.
This is similar to how message-mode prompts if you mess up the mail
headers, like having a bogus email address in the To: header.

Re: Commit netiquette.

[Alfred M. Szmidt]

   > That is the whole idea of a ChangeLog, a short message doesn't
   > substitute it.

   "bzr log --line" and "C-x C-f ChangeLog <RET>" are different
   operations. We're talking about the use of the bzr tool (including
   graphical interfaces), not about ChangeLog.

The two contain the same information, so essentially they are the
same.

Re: Commit netiquette.

[Miles Bader]

"Alfred M. Szmidt" <ams@gnu.org> writes:
>    "bzr log --line" and "C-x C-f ChangeLog <RET>" are different
>    operations. We're talking about the use of the bzr tool (including
>    graphical interfaces), not about ChangeLog.
>
> The two contain the same information, so essentially they are the
> same.

No.

The short summary represents _extra_ information.  It may be derived
from the same original source in many cases, but the editorial decisions
required to construct a summary are non-trivial and useful.

Of course, people could also provide summary lines in a ChangeLog --
e.g., prefix a classic ChangeLog entry with a "SUMMARY:"  line.  Indeed,
I'd recommend that people do this, even though it's not a part of the
classic ChangeLog format (I do this sometimes when adding a single
cohesive change that touches many files); it makes ChangeLogs easier to
read and more useful.

-Miles

-- 
80% of success is just showing up.  --Woody Allen

Re: Commit netiquette.

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Date: Sat, 20 Feb 2010 23:13:31 +0900
> Cc: ofv@wanadoo.es, Juanma Barranquero <lekktu@gmail.com>, emacs-devel@gnu.org
> 
> Of course, people could also provide summary lines in a ChangeLog --
> e.g., prefix a classic ChangeLog entry with a "SUMMARY:"  line.  Indeed,
> I'd recommend that people do this, even though it's not a part of the
> classic ChangeLog format (I do this sometimes when adding a single
> cohesive change that touches many files); it makes ChangeLogs easier to
> read and more useful.

However, the "SUMMARY:" part just wastes precious real estate of the
single line produced by "bzr log --line".

Re: Commit netiquette.

[Juanma Barranquero]

On Sat, Feb 20, 2010 at 13:37, Alfred M. Szmidt <ams@gnu.org> wrote:

> The two contain the same information, so essentially they are the
> same.

I disagree, and Miles has answered that in detail.

But I find interesting that you didn't answer the main question in my message.

    Juanma

Re: Commit netiquette.

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:

>> Of course, people could also provide summary lines in a ChangeLog --
>> e.g., prefix a classic ChangeLog entry with a "SUMMARY:"  line.  Indeed,
>> I'd recommend that people do this, even though it's not a part of the
>> classic ChangeLog format (I do this sometimes when adding a single
>> cohesive change that touches many files); it makes ChangeLogs easier to
>> read and more useful.
>
> However, the "SUMMARY:" part just wastes precious real estate of the
> single line produced by "bzr log --line".

Eh?  I'm confused... I don't mean they should literally write the string
"SUMMARY:", and I was talking about ChangeLog files, not commit-logs.

What I was advocating was, _in ChangeLog files_, a style like:

   2010-02-22  Miles Bader  <Miles Bader <miles@gnu.org>>

           Frobbed the grot system:
           * grot-blah.el (fun1, fun2): Blurged frebly.
           * grot-zung.el (fun3): Nug n ug.
           * some-grup.el (zoon): Wabawaba.

This isn't always necessary for small/trivial changes, but for longer
ones, i think it's a useful addition.

Indeed, one can imagine a ChangeLog style where the commit-log text
(following typical commit-log conventions) is used a prefix for
traditional ChangeLog-type per-file entries.  For instance:

   2010-02-22  Miles Bader  <Miles Bader <miles@gnu.org>>

           Frobbed the grot system
           
          The Grot system was blorked, so rewrite all the zoong-nurbs
          using an explicit snood cache.

           * grot-blah.el (fun1, fun2): Blurged frebly.
           * grot-zung.el (fun3): Nug n ug.
           * some-grup.el (zoon): Wabawaba.

Again, all the comments above pertain to ChangeLog files, not
commit-logs [for commit-logs, of course I recommend the standard 1-line
(without period) summary followed if necessary by a more verbose
description in additional paragraphs].

-Miles

-- 
"... The revolution will be no re-run brothers; The revolution will be live."

Re: Commit netiquette.

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: ofv@wanadoo.es,  lekktu@gmail.com,  ams@gnu.org,  emacs-devel@gnu.org
> Date: Mon, 22 Feb 2010 11:17:23 +0900
> 
> > However, the "SUMMARY:" part just wastes precious real estate of the
> > single line produced by "bzr log --line".
> 
> Eh?  I'm confused... I don't mean they should literally write the string
> "SUMMARY:"

Then it is my misunderstanding, sorry.  I thought you did mean
"SUMMARY: bla-bla" literally.

> and I was talking about ChangeLog files, not commit-logs.

Most people simply copy the former into the latter.

> What I was advocating was, _in ChangeLog files_, a style like:
> 
>    2010-02-22  Miles Bader  <Miles Bader <miles@gnu.org>>
> 
>            Frobbed the grot system:
>            * grot-blah.el (fun1, fun2): Blurged frebly.
>            * grot-zung.el (fun3): Nug n ug.
>            * some-grup.el (zoon): Wabawaba.
> 
> This isn't always necessary for small/trivial changes, but for longer
> ones, i think it's a useful addition.

Right, and I think many, if not most, already do that.

Re: Commit netiquette.

[Stefan Monnier]

>> Frobbed the grot system:
>> * grot-blah.el (fun1, fun2): Blurged frebly.
>> * grot-zung.el (fun3): Nug n ug.
>> * some-grup.el (zoon): Wabawaba.
>> 
>> This isn't always necessary for small/trivial changes, but for longer
>> ones, i think it's a useful addition.

> Right, and I think many, if not most, already do that.

Not only that: it's recommended.  And this recommendation will only grow
stronger over time.


        Stefan

Re: Commit netiquette.

[Alfred M. Szmidt]

   >      ----------------
   >      Author: 
   >      Summary: 
   >
   >      blablabla
   >      ----------------
   >
   >    where <blablabla> is the text taken from the ChangeLog.  Then for
   >    backends which support the notion of summary-line, C-c C-c could
   >    just signal an error if the Summary line is still blank.
   >
   > That seems overly forceful, emacs is not just by emacs developers, it
   > is used by an immense number of people.

   I don't think it should issue an error, but it should prompt the
   user.  This is similar to how message-mode prompts if you mess up
   the mail headers, like having a bogus email address in the To:
   header.

I think user interactive promopts should be keep to a minimum.  Maybe
one could use font-lock, and just mark it visually.

Re: Commit netiquette.

[Alfred M. Szmidt]

   > Of course, people could also provide summary lines in a ChangeLog
   > -- e.g., prefix a classic ChangeLog entry with a "SUMMARY:" line.
   > Indeed, I'd recommend that people do this, even though it's not a
   > part of the classic ChangeLog format (I do this sometimes when
   > adding a single cohesive change that touches many files); it
   > makes ChangeLogs easier to read and more useful.

   However, the "SUMMARY:" part just wastes precious real estate of
   the single line produced by "bzr log --line".

I think Miles suggestion would strip `SUMMARY:' before putting it into
a log message.  Personally, I dislike this kind of behind-the-back
features.

Re: Commit netiquette.

[Alfred M. Szmidt]

   > The two contain the same information, so essentially they are the
   > same.

   I disagree, and Miles has answered that in detail.

   But I find interesting that you didn't answer the main question in
   my message.

If you feel I missed your main point, then you should repeat it, since
I cannot answer what I do not know.

Re: Commit netiquette.

[Juanma Barranquero]

On Tue, Feb 23, 2010 at 20:25, Alfred M. Szmidt <ams@gnu.org> wrote:

> If you feel I missed your main point, then you should repeat it, since
> I cannot answer what I do not know.

OK.

"Most people seem to agree that the one-line summary is a nice thing to
have in some contexts. Are you going to go against policy?"

    Juanma

Re: Commit netiquette.

[David Kastrup]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Tue, Feb 23, 2010 at 20:25, Alfred M. Szmidt <ams@gnu.org> wrote:
>
>> If you feel I missed your main point, then you should repeat it, since
>> I cannot answer what I do not know.
>
> OK.
>
> "Most people seem to agree that the one-line summary is a nice thing to
> have in some contexts. Are you going to go against policy?"

Policy is not the same as agreement.

-- 
David Kastrup

Re: Commit netiquette.

[Juanma Barranquero]

On Tue, Feb 23, 2010 at 23:09, David Kastrup <dak@gnu.org> wrote:

> Policy is not the same as agreement.

I agree.

You can read the two sentences as disjoint. Think of it as a conditional.

    Juanma