Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)
- Date: Tue, 11 Jul 2017 08:50:33 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: What's cooking in git.git (Jul 2017, #03; Mon, 10)
Jeff King <peff@xxxxxxxx> writes:
> On Tue, Jul 11, 2017 at 10:28:08AM +0200, Lars Schneider wrote:
>> > On 11 Jul 2017, at 00:48, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> > * ls/filter-process-delayed (2017-06-30) 7 commits
>> > (merged to 'next' on 2017-07-05 at a35e644082)
>> > + convert: add "status=delayed" to filter process protocol
>> > + convert: refactor capabilities negotiation
>> > + convert: move multiple file filter error handling to separate function
>> > + convert: put the flags field before the flag itself for consistent style
>> > + t0021: write "OUT <size>" only on success
>> > + t0021: make debug log file name configurable
>> > + t0021: keep filter log files on comparison
>> > The filter-process interface learned to allow a process with long
>> > latency give a "delayed" response.
>> > Will merge to 'master'.
>> Hi Junio,
>> can you already tell if this topic has still a chance to be part of 2.14?
> I'm not Junio, but we should be able to reason it out. :)
I am ;-).
> It's marked as "will merge to master", which typically means it will
> happen during the next integration cycle (i.e., within a few days when
> the next "What's cooking" is written).
Just like being in 'next' is not a promise for a topic to be in the
upcoming release (or any future one for that matter), "Will merge to
X" merely means "With the current shape of the series and with the
best of our current knowledge, this is thought to be mergeable to X
at some point in the future". When a more urgent topic that
conflicts heavily with it appears, when a serious bug is found in
the topic, etc., "our current best knowledge" may be invalidated.
Anticipating such an event that changes our assumption happening, I
try to keep a topic in 'next' for at least a week, if it is a
non-trivial topic that changes more than a few dozen lines (not
counting tests and docs). For things that touch deeper guts of the
system, I'd prefer to cook it longer. For more trivial things, it
may only be a day or two. So "at some point in the future" varies
depending on the weight of a topic.
> Since 2.14 will be cut from the tip of master in a few weeks, once
> it's merged it will definitely be in 2.14 (barring a revert, of
> course). This holds true during release freeze, too. Anything
> that makes it to master is part of the release.
This is correct.
> The stopping point there is that things stop getting marked as
> "will merge to master".
This is correct, if you allow the possibility that a thing that used
to be marked as "Will merge to 'master'" gets demoted to "Will cook
in 'next'" (and you need to anticipate that possibility---I try to
demote topics that got in to 'next' just before -rc0 to to "Will
cook" when tagging -rc0, unless they are fixes that are not too
I probably should have marked this as "Will cook in 'next'" in the
first place. The practice has been to blindly promote "Will merge
to 'next'" to "Will merge to 'master'" by default when a topic gets
merged to 'next', and then inside of the first week try to find a
chance to re-read the topic to decide to demote it to "Will cook".