git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: git@vger.kernel.org, Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH] config: Use parseopt.
Date: Sat, 14 Feb 2009 13:10:03 -0800	[thread overview]
Message-ID: <7vtz6wrahg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <94a0d4530902141209j7a3a9976l80355bee526852ed@mail.gmail.com> (Felipe Contreras's message of "Sat, 14 Feb 2009 22:09:59 +0200")

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> Unfortunately, not many patch authors write such a summary.  Sometimes we
>> see summaries on things that were discussed but nobody has followed
>> through posted by third parties (including myself), but we do not seem to
>> have enough helpers to do that either.  This does not take much technical
>> skills but is a good "trust point" earner.
>
> For me it's easier, and more fun to write a separate patch that fixes
> the issues than writing a summary,...

That certainly is something we should take into consideration.

I however think an unwritten assumption around here so far has been that
the patch author who gets review comments is expected to keep track of the
issues raised, both about the patch itself and about the similar breakages
in the existing code pointed out during the review process, if only
because the patch author is the focal point of the discussion.

We probably need to break that.

Because it is very likely that the reviewer does not even realize that
such similar breakages in the existing code when a review is made, we
cannot ask reviewers to always start a separate discussion.  Some reviews
do say "Admittedly, we already have the same pattern in here and there,
but this in your patch is wrong," but the way how we collectively realize
an existing breakage is often by hearing the patch author respond with
"but there already are this and that breakages in the existing code."

We do not want such knowledge of existing breakages go to waste in either
case.  Perhaps it would be a good start to make it the responsibility of
the first person who mentions an existing breakage (either the reviewer's
"Admittedly", or the patch author's "but there already are") to begin a
separate thread, so that mail archive would remember it.  It shouldn't
take more than 3 minutes.

  parent reply	other threads:[~2009-02-14 21:11 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-14  2:05 [PATCH] config: Use parseopt Felipe Contreras
2009-02-14  9:28 ` Junio C Hamano
2009-02-14  9:35   ` Junio C Hamano
2009-02-14 10:41     ` Felipe Contreras
2009-02-14 10:37   ` Felipe Contreras
2009-02-14 11:40     ` Johannes Schindelin
2009-02-14 12:03       ` [PATCH v2] " Felipe Contreras
2009-02-14 15:21         ` Jeff King
2009-02-14 15:24           ` Felipe Contreras
2009-02-14 19:59         ` Johannes Schindelin
2009-02-14 20:19           ` Junio C Hamano
2009-02-14 21:08             ` human readable diffs, was " Johannes Schindelin
2009-02-14 20:31           ` Felipe Contreras
2009-02-14 22:32             ` Johannes Schindelin
2009-02-14 22:36               ` Jakub Narebski
2009-02-14 22:54                 ` Johannes Schindelin
2009-02-15  9:04               ` Felipe Contreras
2009-02-15 11:26                 ` Johannes Schindelin
2009-02-15 12:07                   ` Felipe Contreras
2009-02-15 12:33                     ` Johannes Schindelin
2009-02-15 12:51                       ` Felipe Contreras
2009-02-15 13:38                         ` Felipe Contreras
2009-02-15 19:31               ` Junio C Hamano
2009-02-15 19:41                 ` Johannes Schindelin
2009-02-15 21:22                   ` Junio C Hamano
2009-02-15 21:29                     ` Johannes Schindelin
2009-02-17  0:50                       ` Felipe Contreras
2009-02-15 19:36               ` Junio C Hamano
2009-02-14 12:15       ` [PATCH] " Felipe Contreras
2009-02-14 19:11         ` Johannes Schindelin
2009-02-14 19:14           ` Felipe Contreras
2009-02-14 19:24             ` Johannes Schindelin
2009-02-14 19:26               ` Johannes Schindelin
2009-02-14 21:13                 ` Felipe Contreras
2009-02-14 19:29     ` Junio C Hamano
2009-02-14 20:09       ` Felipe Contreras
2009-02-14 20:35         ` Junio C Hamano
2009-02-14 21:01           ` Felipe Contreras
2009-02-14 21:10         ` Junio C Hamano [this message]
2009-02-14 21:24           ` Felipe Contreras
2009-02-14 21:15         ` Johannes Schindelin
2009-02-15  2:22           ` Junio C Hamano
2009-02-14 11:52 ` Jakub Narebski
2009-02-14 12:06   ` Felipe Contreras
2009-02-14 15:17   ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vtz6wrahg.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).