git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 15, 2017, 21:22 UTC
Message-ID
<xmqq377nwtbe.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<alpine.DEB.2.21.1.1709152214100.219280@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 20 quoted lines
> On Sat, 16 Sep 2017, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 
>> > If you want *contributors* to ping the thread themselves, how about
>> > *posting your updates there, too*?
>> 
>> I do not understand this comment at all.  That is what I and others
>> already and always do by responding to the patches, and when trying
>> to see if a topic is still alive, with thread-specific responses and
>> pings.
>> 
>> If you are demanding that "What's cooking" report to be sent as a
>> response to all the topics, that will *NOT* going to happen.  It is
>> meant to give a summary of the current state to help contributors
>> and reviewers be aware of what is happening across the entire tree
>> and not limited to a specific topic.
>
> If that is the case, you will have to be okay with others responding to
> your "What's cooking" mails instead of the original threads.

Yes and no. When I say "This topic waits for a reroll" and somebody (not necessarily the author of the topic) wants to remind me that a reroll has already been posted (or worse--I queued the updated version but forgot to update the message), I do appreciate that the reply is made to the "What's cooking" report. When there is "This topic waits for a response to a review comment" and the responder wants to respond to the review comment, the reply should be made in response to that review comment. Otherwise, the discussion will lose the continuity.

And as you alluded to, we may need to see if we can help making it easier to do the latter when needed.

> That's what
> you are buying into by having these "What's cooking" mails that are in no
> usable way connected to the original threads.

For the above reason, I do not think this is a particularly useful stance to take. Do you have a concrete suggestion to make these individual entries more helpful for people who may want go back to the original thread in doing so? In-reply-to: or References: fields of the "What's cooking" report would not help. I often have the message IDs that made/helped me make these individual comments in the description; they alone would not react to mouse clicks, though.

Having said that, I'd expect that individual contributors have past messages pertaining to the smaller numbers of their own topics in flight in their mailbox than the project wide "What's cooking" report covers, so perhaps an affort to devise such a mechanism may result in an over-engineering waste nobody finds useful. I dunno.

Previous: Johannes SchindelinNext: Johannes Schindelin
Message 8 of 16 in “What's cooking in git.git (Aug 2017, #05; Tue, 22)”
  1. Junio C HamanoAug 22, 2017
  2. Brandon WilliamsAug 23, 2017
  3. Lars SchneiderAug 23, 2017
  4. Junio C HamanoAug 24, 2017
  5. Johannes SchindelinSep 15, 2017
  6. Junio C HamanoSep 15, 2017
  7. Johannes SchindelinSep 15, 2017
  8. Junio C HamanoSep 15, 2017
  9. Johannes SchindelinSep 18, 2017
  10. Junio C HamanoSep 19, 2017
  11. Johannes SchindelinSep 19, 2017
  12. Jonathan NiederSep 19, 2017
  13. Johannes SchindelinSep 29, 2017
  14. Jonathan NiederSep 19, 2017
  15. Nicolas Morey-ChaisemartinSep 19, 2017
  16. Johannes SchindelinSep 29, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.