Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Tue, 3 Jul 2018, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > On Thu, 28 Jun 2018, Junio C Hamano wrote: >> > >> >> * as/safecrlf-quiet-fix (2018-06-11) 1 commit >> >> (merged to 'next' on 2018-06-13 at b163674843) >> >> + config.c: fix regression for core.safecrlf false >> >> >> >> Fix for 2.17-era regression around `core.safecrlf`. >> > >> > Is this `maint` material? >> >> Possibly. Why do you ask? > > This is my feeble attempt at helping you triage. My question was more like > a suggestion. Ah, thanks. That line of suggestion does help, and it would even be more helpful when given before the topic hits 'next' or after 'master' from the workflow's point of view. While the topic is in 'pu' I can change where the topic forks from, and to minimize temptation to stupidly merge an inappropriate topic (e.g. new developments and somewhat dubious fixes to commonly used part of Git) down to 'maint' during the pre-release freeze (i.e. when the tree is otherwise hopefully sleepily quiet and boring), I try to base the (beginning of) good 'maint' material on 'maint' or older, and everything else on the tip of 'master' (or the most recent feature release), when each topic is originally queued in my tree. If I missed a good topic and based it on 'master', it is easier to correct such a mistake before it hits 'next', and a suggestion like above would help me tremendously. After the topic hits 'next', its course is pretty much set, until it graduates to 'master'. About a week or two after such event, I'd go through "merge ... later to maint" entries in the draft release notes and if the topic still looked relevant to the maintenance branch, merge them to 'maint'. Before that happens is another chance to stop me from making a stupid mistake, or remind me of an urgent one that I've been letting wait in 'master' before merging to 'maint'. Thanks.
