> On 11 Jul 2017, at 11:11, Jeff King <p...@peff.net> wrote: > > On Tue, Jul 11, 2017 at 10:28:08AM +0200, Lars Schneider wrote: > >>> On 11 Jul 2017, at 00:48, Junio C Hamano <gits...@pobox.com> 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. :) > > 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). > > 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. The stopping point there is that things > stop getting marked as "will merge to master".
Thanks for the explanation! I looked at the Git release calendar [1] and realized that 2.14-rc0 is scheduled for this Thursday. My assumption was that either on this date 2.14 will be cut from the tip of master or master would not change significantly after the rc0 date until the 2.14 release. - Lars [1] http://tinyurl.com/gitCal
