Date: Sat, 12 Apr 2025 13:46:58 +0300 From: Artem Bunichev <tembun@bk.ru> To: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> Cc: freebsd-hackers@freebsd.org Subject: Re: Forgotten MFC Message-ID: <20250412134658.e41004e25df0044a6f5498e6@bk.ru> In-Reply-To: <20250412040913.9fc4944e0cf6142e086f4bad@dec.sakura.ne.jp> References: <20250411204934.d574639172d393183ace4749@bk.ru> <20250412040913.9fc4944e0cf6142e086f4bad@dec.sakura.ne.jp>
index | next in thread | previous in thread | raw e-mail
> Me, too, not a developer, but you need to specify which commit you mean > to get answers from developer. Sure, here is a commit: https://cgit.freebsd.org/src/commit/?id=272b4b764bdfb563f655da37ef9ec8c01c77f386 But I would say that I was interested in general approach for MFC'ing, rather than a particular case. What I mean is how do developers keep track of which commits should be MFC in, say, 14-STABLE, because as I can see, not all of the commits in -CURRENT branch include "MFC after:" field. > More, even if the commit itself "looks" OK, in some cases, > prerequiresite commits for it violates POLA, avoiding it to be MEC'ed. Indeed, that makes sense. As I can see, POLA in this case basically means not to break ABI for a particular version. And if the commit _does_ break ABI it will never be landed in branches for previous releases and stable versions. But in case of the commit I'm talking about, as I can understand, it does _not_ break the ABI, but just fixes a minor bug. Nevertheless, it was not MFC'ed for so long. And basically my question is: is there a way or approach that developers follow to prevent or minimize such forgotten commits? Or this is a job that ought to be done manually only and such commits can not be found by some automation? Thank you.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20250412134658.e41004e25df0044a6f5498e6>