On Fri, Aug 3, 2018 at 1:07 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Brandon Williams <bmwill@xxxxxxxxxx> writes: > > > [1] https://public-inbox.org/git/CAGZ79kYGS4DvoetyGX01ciNrxxLCqgXoVSpLhmgYZ8B51LzhSg@xxxxxxxxxxxxxx/ > > 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@xxxxxxxxxxxxxxxxxxxxxxxxx/ 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
