git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Brandon Williams <bmwill@google.com>,
	"brian m. carlson" <sandals@crustytoothpaste.net>,
	git <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Aug 2018, #01; Thu, 2)
Date: Fri, 3 Aug 2018 13:43:07 -0700	[thread overview]
Message-ID: <CAGZ79kZdPP+q9iuQioUU+2JkfH4n1mkkHrXaJzxGVwhxvbKZ1Q@mail.gmail.com> (raw)
In-Reply-To: <xmqqftzvw6xi.fsf@gitster-ct.c.googlers.com>

On Fri, Aug 3, 2018 at 1:07 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Brandon Williams <bmwill@google.com> writes:
>
> > [1] https://public-inbox.org/git/CAGZ79kYGS4DvoetyGX01ciNrxxLCqgXoVSpLhmgYZ8B51LzhSg@mail.gmail.com/
> > This mail seems to counter that indicating that the "What's Cooking"
> > emails should not be used as a status update.
>
> You are the second one who were negatively affected by Stefan's
> "summary" that reads a lot more in what I said than what actually
> was said by me.  Stop paying attention to that message, but do go to
> the original if you want to hear what I actually said.

Please note that I put that one out to "in a deliberatly
outrageous way"[1] so that I get more arguments on why
this workflow is the best we have.

Personally I think the mailing list workflow could be improved
by having less manual work on your side.

That would (a) make the whole process from one end (of writing
the patch) to the other (of seeing its effect in a shipped binary
by a distribution) more transparent, as then DScho could build
his amlog consumer more easily for example.
And (b) it would be less work for you, though different work.
(i.e. instead of resolving conflicts yourself, you'd tell 2 people
to resolve conflicts between their series and you'd then fetch
from them; c.f. Linus lieutenants).

[1] https://public-inbox.org/git/xmqqo9ejwag9.fsf@gitster-ct.c.googlers.com/

I did miss the first person who was negatively affected?

> The mention of "discussion thread on the list is the authoritative"
> was said in the context where somebody refuted these "cf. <msg>" on
> a topic and I got an impression that it was done in the belief that
> doing so for each and every "cf. <msg>" would be enough to exonerate
> the topic of all the issues.  I was explaining that they were not
> meant to be exhaustive list, but rather are my personal reminder so
> that I can go back to the thread to recall why I said things like
> "Waiting for review to conclude", "expecting a reroll", etc.; as I
> do not need to point at all the review comments that matter for them
> to serve that purpose, these "cf. <msg>" must not be taken as the
> "clear these and you are home free" list.  To cover all the issues
> pointed out in the review process, you must go to the original.
>
> "What's cooking" primarily serves two purposes.
>
>  - After list of patches in a topic, I try to summarize what the
>    topic is about.  This is to become merge commit message for the
>    topic when it is merged to various integration branches, and also
>    to become an entry in the release notes.
>
>  - Then an immediate plan like "Will merge to 'next'", etc. for the
>    topic is announced, optionally with comments like "cf. <msg>" to
>    remind me why I chose to label the topic as such.
>
> The former is outside the topic of this thread, but both are *not*
> obviously written by everybody; the former is my attempt to
> summarize, and people are welcome to improve them.  If my attempted
> summary is way incorrect, that might be an indication that the
> topic, especially its log messages, is not clearly done.
>
> If my immediate plan contradicts the list concensus, it likely is an
> indication that I missed the discussion, and it is very much
> appreciated for those involved in the discussion to correct me.
> That may result in my dropping a "cf. <msg>" when an issue I thought
> to be blocking (or to require the topic to be fast-tracked) turns
> out to have been resolved already, or adding another one when it is
> pointed out to me that I missed an important issue to block (or
> fast-track) the topic.

Thanks for explaining the thoughts behind the cooking emails.

- The first part is very nice to have on the mailing list, but it is
  not strictly needed as you could just write the release notes
  and then people could send patches to the release notes as
  usual.

- The second part of having an immediate plan is *very* nice
  to see, though I would argue that it could be improved
  by having these updates in the thread instead of summarized
  unrelated to that thread.

  We do not do this for now due to tooling issues, I suppose.

  But I would think it makes the threads more discoverable if
  we'd have the status updates in each thread as then people
  would keep the discussion there and not jump on the cooking
  email to continue discussion there.

> Hope this clarifies a bit of the confusion caused by that summary.

I am sorry that this seems as if I would stir up the community
and cause troubles intentionally, but all I really want is a better
workflow process. And as I do not know what is better, I think out
loud trying to get a discussion going that point out things that are
good or bad.

Is there a better way to start a workflow discussion?

Thanks,
Stefan

  reply	other threads:[~2018-08-03 20:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-02 23:02 What's cooking in git.git (Aug 2018, #01; Thu, 2) Junio C Hamano
2018-08-03  0:05 ` Stefan Beller
2018-08-03 16:08   ` Junio C Hamano
2018-08-03  3:00 ` Pratik Karki
2018-08-03 16:09   ` Junio C Hamano
2018-08-03 18:09 ` brian m. carlson
2018-08-03 18:40   ` Junio C Hamano
2018-08-03 18:45     ` brian m. carlson
2018-08-03 18:51       ` Junio C Hamano
2018-08-03 18:56         ` Junio C Hamano
2018-08-03 19:32           ` Brandon Williams
2018-08-03 20:07             ` Junio C Hamano
2018-08-03 20:43               ` Stefan Beller [this message]
2018-08-03 21:45                 ` Junio C Hamano
2018-08-05  6:15                 ` Junio C Hamano
2018-08-05  0:30 ` pk/rebase-in-c, was " Johannes Schindelin
2018-08-05  6:08   ` Junio C Hamano
2018-08-09 13:24     ` Johannes Schindelin
2018-08-07 10:50 ` Jakub Narebski
2018-08-07 14:36   ` Junio C Hamano
2018-08-07 15:42     ` Jakub Narębski

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CAGZ79kZdPP+q9iuQioUU+2JkfH4n1mkkHrXaJzxGVwhxvbKZ1Q@mail.gmail.com \
    --to=sbeller@google.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).