From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Google Doc about the Contributors' Summit
Date: Thu, 09 Feb 2017 11:09:56 -0800 [thread overview]
Message-ID: <xmqq7f4zqiyj.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1702021007460.3496@virtualbox> (Johannes Schindelin's message of "Thu, 2 Feb 2017 10:08:47 +0100 (CET)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I just started typing stuff up in a Google Doc, and made it editable to
> everyone, feel free to help and add things:
>
> https://docs.google.com/document/d/1KDoSn4btbK5VJCVld32he29U0pUeFGhpFxyx9ZJDDB0/edit?usp=sharing
Thanks for a write-up, Dscho.
List of bullet points just make non-attendees envious, imagining
that attendees had all the fun discussing what is behind these
bullet points, without being able to know what was discussed, if
they reached consensus and what the consensus was, but it is OK ;-)
A few items caught my attention, not because I found them more
important than other items on the page, but because they seem to
want my input without directly asking me ;-)
* If Junio would accept patches by replying to the sender with an
ID and/or a patch name. He picks this (branch) name when he gets
your patch.
I am not sure what exactly I am asked to "accept" here. I sometimes
forget to respond with "Thanks, will queue." to the patch message
and whoever said this wants me to consistently do so? I never say
"... will queue as js/difftool-builtin topic." mainly because I do
not know what the name of the topic branch should be at the point of
reading the patch. All I know is that decided that it may be worth
queuing, so it is a bit harder to arrange. But I can certainly try
if it makes the lives of contributors easier.
* Junio has a script for the todo branch which we can use to
generate the what's cooking branch. Perhaps we could continuously
generate this onto a webpage.
I have no objection, but I doubt that people find such an auto
generated version all that useful, as "git log --first-parent
origin/master..origin/pu" would tell exactly the same story. It
will lack the "topic summary" comment I have yet to write, if the
final 'pu' of the day that was pushed out was before my local update
to the draft of the next issue of "What's cooking" report [*1*], and
would not have any update on the next action (e.g. "Will merge to
...") relative to the latest issue of "What's cooking" report. IOW,
such an auto-generated report lacks all the added value over "git log"
output.
* Making the actual workflow more publicly known, e.g. document how
to generate the cooking email, to learn about the state of a
generation.
The exact mechanics of "how to generate" may be of less importance
than "how the information contained therein relates to their own
work" to the contributors, and I think MaintNotes that is sent out
at key milestones more or less covers the mechanics, but here is how
the sausage is made these days:
- I find a patch series on the list that is in good enough shape to
be in 'pu'. Perhaps it was already discussed and redone a few
times without hitting my tree. Or it may be the first attempt of
a new topic. I come up with a topic name, decide where the topic
should fork at [*2*], create the topic branch and queue the
patches. I may or may not test the topic in isolation at this
point.
- I may find an updated patch series of what has been queued. I go
to the existing topic branch and replace it (I try to keep it
forked at the same commit) after inspecting what got updated.
"git tbdiff" is a useful program to help this step. I may or may
not test the topic in isolation at this point.
- I repeat the above two for various topics during the day, and at
some point between 14:00-15:00 my time, stop taking new patches.
The day's integration cycle starts.
- If there are topics that have cooked long enough in 'next' and
planned to graduate to 'master', merge [*3*] them to 'master',
update the draft Release notes. Otherwise skip this step.
- If there are topics that have cooked long enough in 'pu' and
planned to graduate to 'next', merge them to 'next'. Otherwise
skip this step.
- If I updated 'master', merge its tip to 'next' (this should update
the draft release notes and nothing else, unless I took something
directly to 'master').
- Then I recreate 'jch', which is a point between 'master' and 'pu'.
This is the version I use for my own work, contains all topics in
'next' but a bit more. "git checkout -B jch master" begins it,
and then the topics that were in 'jch' are merged on top. The
latest version of updated topics that were already in 'jch' are
incorporated at this point, and "git diff jch@{20.hours}" would
show the effect of their interdiff (plus RelNotes update, if
'master' was updated during this integration cycle).
- I ran "git branch --no-merged pu --sort=-committerdate" to see the
topics that are new; the top of this list shows new topics and
updated topics (note that I just updated 'jch' but not 'pu' yet at
this point). Among them, I pick the ones that I am willing to be
a guinea-pig for before they hit 'next' and merge them to 'jch'.
Other topics that used to be in 'pu' may also be merged at this
point, when they turn out to be "interesting" enough.
- 'pu' is recreated on top of 'jch' [*4*]. "git checkout -B pu jch"
begins it, the topics that were already in 'pu' are merged on top
(some of them may have been merged to updated 'jch' in the above
step), together with the new topics we acquired.
- All integration branches are then tested (and installed for my own
use) at this point.
- While the tests are running, the draft "What's cooking" report is
updated. Here is where I write topic summary for new topics and
update topic summary for updated topics. The next action
(e.g. "Will merge to ...") may also be updated at this point.
- If the test notices problems, I go back to redo the day's merges
[*5*]. The first thing to do is to rewind the integration
branches back to the state before the day's integration started.
Trivial breakages are fixed-up in place with "rebase -i" or
queuing "SQUASH???" fix on top of the offending topic before
merging them back to 'master', 'next', 'jch' or 'pu'. A more
involved ones may force me to punt and eject the topic from the
integration branches. Or I may leave it in 'pu' so that others
who are more clueful in the area the offending topic touches can
notice the breakage and send in fix-up patches [*6*].
- If I have time, I redo 'jch' and 'pu' at this point once again,
because the merge commit for new topics we just tested do not have
their merge log message in sync with the topic summary in the
draft "What's cooking" report at this point [*6*]. I run the
tests for integration branches again, but the tree objects at the
tips of the integration branches are expected to be the same as
what was tested earlier, so it becomes a no-op.
- I push out the integration branches to the usual places [*7*].
- Then I go back to the very beginning. I start taking patches for
the next day's integration cycle.
Interested people are welcome to condense the above to update
MaintNotes in my 'todo' branch.
[Footnote]
*1* Merges that appear early in the "--first-parent master..pu"
carry the topic summary I have in the draft of "What's cooking"
report as its merge message.
*2* Sometimes a maint-worthy patch series is done in such a way that
it only applies to 'next'. I try to tweak such a patch series
to apply 'maint' and either use the result of my tweak, or ask
the submitter to base it on 'maint', depending on how confident
I am with the tweaked result.
*3* When I do this and any other "merge" of a topic branch into an
integration branch, the topic description in the draft "What's
cooking" report is used as the merge log message, if one already
exists.
*4* Readers would notice that 'jch' and 'pu' are not decendants of
'next'; this is very much deliberate, and it has helped me to
spot mismerges of tricky topics when they graduate to 'master' a
few times.
*5* IOW, I go back to the step "around 14:00-15:00".
*6* This is why the tip of 'pu' sometimes may not even build. IOW,
a broken 'pu' is an invitation for help, not complaint.
*7* Remember *3* above and also the fact that "What's cooking" draft
is updated only after everything is merged to 'pu'; there is a
small chicken and egg problem here and redoing 'jch/pu' will fix
it.
*8* Broken-out individual topics are sent to github.com/gitster/git
next prev parent reply other threads:[~2017-02-09 19:11 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-02 9:08 Google Doc about the Contributors' Summit Johannes Schindelin
2017-02-07 11:51 ` Johannes Schindelin
2017-02-09 19:09 ` Junio C Hamano [this message]
2017-02-10 15:59 ` Johannes Schindelin
2017-02-11 3:26 ` Junio C Hamano
2017-02-15 12:02 ` Clarification about "Better tooling for reviews", was " Johannes Schindelin
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=xmqq7f4zqiyj.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--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.
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).