git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
	Duy Nguyen <pclouds@gmail.com>
Subject: Re: [PATCH 00/11] Moving global state into the repository object (part 2)
Date: Wed, 28 Feb 2018 11:19:31 -0800	[thread overview]
Message-ID: <20180228191931.GF251290@aiede.svl.corp.google.com> (raw)
In-Reply-To: <CAGZ79kaDVrn6Qw_xsdyBST6XfJMXs43qDWx8jY2J9VsXwDKm5Q@mail.gmail.com>

Hi,

Stefan Beller wrote:
> On Wed, Feb 28, 2018 at 9:57 AM, Junio C Hamano <gitster@pobox.com> wrote:

>> Wait a minute.  Is that topic ever shown to work well together with
>> other topics in flight and are now ready to be built upon?  I had an
>> impression that it is just starting to get serious reviews.
>
> And I had the impression the serious reviews were done and fine;
> the only issue would be demonstrating its working fine with other
> series, where I was also worrying about conflicts with
> brians series. And to address that, I'd just send series in small sizes.

Some of the patches looked cooked to me and others still do not look
cooked yet.  I marked the former with Reviewed-by.  In general, a few
things can help to make the process easier for me:

 1. Giving a quick reply to a review to say how the comments were
    resolved, sometimes even with a resend of that one patch to
    illustrate.  That way the conversation can continue and the
    individual patch can get to a reviewed state faster, without
    having to chase between different rerolls of the entire series.

    This also has an effect of making the review process more
    collaborative: perhaps after seeing how you address their
    comments, a reviewer may have another idea that they suggest via a
    patch to squash in, etc.

 2. In a reroll, summarizing the result of previous reviews by
    including acks as appropriate and Reviewed-by if a reviewer
    granted it.  This helps with reviewing the reroll since it tells
    people where to focus their attention.

[...]
> Is there anything that a contributor can help with that eases
> refactoring series in flight?

For helping reviewers, see above.

For helping Junio, what I've seen people occasionally do is to locally
run a "trial merge" against next and pu and see what semantic or
lexical conflicts arise.  In the cover letter you can describe these
and give Junio advice to make applying the patch easier for him.

[...]
> Sorry for the miscommunication, though,

FWIW, even though part 1 doesn't look done to me yet, it looks *close*
to done, and I was happy to see the sneak peek at part 2.

Thanks,
Jonathan

  reply	other threads:[~2018-02-28 19:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-28  1:05 [PATCH 00/11] Moving global state into the repository object (part 2) Stefan Beller
2018-02-28  1:05 ` [PATCH 01/11] packfile: allow prepare_packed_git_mru to handle arbitrary repositories Stefan Beller
2018-02-28  1:05 ` [PATCH 02/11] packfile: allow rearrange_packed_git " Stefan Beller
2018-02-28  1:06 ` [PATCH 03/11] packfile: allow install_packed_git " Stefan Beller
2018-02-28 14:38   ` Derrick Stolee
2018-02-28  1:06 ` [PATCH 04/11] packfile: add repository argument to prepare_packed_git_one Stefan Beller
2018-02-28  1:06 ` [PATCH 05/11] packfile: add repository argument to prepare_packed_git Stefan Beller
2018-02-28  1:06 ` [PATCH 06/11] packfile: add repository argument to reprepare_packed_git Stefan Beller
2018-02-28  1:06 ` [PATCH 07/11] packfile: allow prepare_packed_git_one to handle arbitrary repositories Stefan Beller
2018-02-28  1:06 ` [PATCH 08/11] packfile: allow prepare_packed_git " Stefan Beller
2018-02-28  1:06 ` [PATCH 09/11] packfile: allow reprepare_packed_git " Stefan Beller
2018-02-28  1:06 ` [PATCH 10/11] packfile: add repository argument to find_pack_entry Stefan Beller
2018-02-28  1:06 ` [PATCH 11/11] packfile: allow find_pack_entry to handle arbitrary repositories Stefan Beller
2018-02-28  2:15 ` [PATCH 00/11] Moving global state into the repository object (part 2) Duy Nguyen
2018-02-28 14:47   ` Derrick Stolee
2018-02-28 17:59   ` Junio C Hamano
2018-02-28 18:59     ` Stefan Beller
2018-02-28 19:09       ` Junio C Hamano
2018-02-28 17:57 ` Junio C Hamano
2018-02-28 18:56   ` Stefan Beller
2018-02-28 19:19     ` Jonathan Nieder [this message]
2018-02-28 19:02   ` Junio C Hamano
2018-02-28 19:09     ` Stefan Beller
  -- strict thread matches above, loose matches on Subject: below --
2018-03-03  2:54 Duy Nguyen

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=20180228191931.GF251290@aiede.svl.corp.google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=sbeller@google.com \
    /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).