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 involved). 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".
