svn commit: r330972 - stable/11/share/misc

[Warner Losh]

On Thu, Mar 15, 2018 at 11:23 AM, Rodney W. Grimes <
freebsd at pdx.rh.cn85.dnsmgr.net> wrote:

> > On Thu, Mar 15, 2018 at 10:31 AM, Warner Losh <imp at bsdimp.com> wrote:
> >
> > >
> > >
> > > On Thu, Mar 15, 2018 at 10:20 AM, Ian Lepore <ian at freebsd.org> wrote:
> > >
> > >> On Thu, 2018-03-15 at 09:14 -0700, Rodney W. Grimes wrote:
> > >> > >
> > >> > > On Thu, 2018-03-15 at 10:52 -0500, Justin Hibbits wrote:
> > >> > > >
> > >> > > > On Thu, Mar 15, 2018 at 10:46 AM, Ian Lepore <ian at freebsd.org>
> > >> > > > wrote:
> > >> > > > >
> > >> > > > >
> > >> > > > > I agree completely with all of this.??It bothers me how many
> > >> > > > > committers
> > >> > > > > have the attitude that handling MFCs is not part of being a
> > >> > > > > committer.
> > >> > > > Never attribute to arrogance that which can adequately be
> > >> > > > explained
> > >> > > > by
> > >> > > > sheer laziness ;)
> > >> > > >
> > >> > > > - Justin (guilty of marking changes as MFC after, and ignoring
> > >> > > > them
> > >> > > > for far too long)
> > >> > > >
> > >> > > Laziness and procrastination I understand -- I own a lovely glass
> > >> > > house
> > >> > > in that neighborhood. ?I tend to put off MFCs for way too long
> then
> > >> > > every few months have to spend a whole weekend catching up.
> > >> > MFC: 1 week (by pool|self)    #defaults to self if missing
> > >> >
> > >> > There is already a very nice tracking tool for outstanding MFC's,
> > >> > if we added a bit of smarts in its parser, and created a pool of
> > >> > MFC commiters (Eitan seems to have started one :-)) those who
> > >> > do not want to do there own MFC work could pass the hat.
> > >>
> > >> If you're talking about the MFC after: field in commits, I don't use
> > >> it. I have about zero tolerance for being nagged by anybody about
> > >> anything, and that goes double for robots nagging me with spam mail.
> > >>
> > >> The MFC tool that works well for me is gonzo's MFCTracker site [*]
> that
> > >> doesn't require extra markup in the commit messages.
> > >>
> > >
> > > I also have a MFC tool for git, but it's n
> > >
> >
> > [[ stupid track pad and too easy button pushes... ]]
>
> I close my lid and lay a standard 104 keyboard on top, and a nice
> mouse beside and just ignore the bad HID that is a laptop.
>
> > but it's not ready for prime time. It's useful if you have a list of
> things
> > you want to MFC for playing them onto the stable branch so you can test
> > before committing to svn stable. It shows the big issues with moving to
> git
> > as the source of truth, though. We have way too much traffic in the repo
> to
> > have git cherry to produce any kind of reasonable output (too many
> changes,
> > can't restrict to a subset of the tree, no way to check prior commits to
> > files affected, etc), and the git cherry-pick command relies a bit too
> much
> > on the merge magic, so it doesn't record merges (there is no merge-info
> in
> > git).
> >
> > However, I could dust off the tool and fix up the rough edges if there's
> > any interest at all. Kyle Evans used it to MFC my crazy src/stand
> stuff...
>
> This tool might be interesting for use when things get complicted
> like the stand code, or I think there was also a huge churn in
> Adrians wifi code that it may be useful for, but it sounds like
> it might be overkill for 90% of our needs.
>
> I shall ask, do you think it would be possible to re-implement
> this tool around svn?
>

No. That makes no sense. Sorry. The whole point of doing it in git was so
you could throw away all the failed attempts and use git's commit curation
tools (eg git rebase -i) to preen whatever you're going to eventually
commit. At most, it might make sense to create a script that would do the
MFC as a patch + git merge --record-only.

Warner