From owner-svn-src-all@freebsd.org Thu Mar 15 17:25:49 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70304313 for ; Thu, 15 Mar 2018 17:25:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF7616CFD0 for ; Thu, 15 Mar 2018 17:25:48 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id e30so9498521ioc.3 for ; Thu, 15 Mar 2018 10:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ezllr7eDiRUizNMTgjavroMASuo7yOtes/hxla0Sh7c=; b=dyTDfeSZ8uPTxRI//GN3qDij5aN1diUbXdmehOGIYl+39zLY8U7pWnDbT3nBpXOFMj kPB/uTyJun3hGxHx/t2mo2VUUIMeqgtg8jJasvircRa+ZN7IF94r7bbpCwk/3mnGextb yayndZRtEtQ4rpu2kUnnQcL/5WxJz7m1PioOtfumvS+ZKOhRtT0oDX5qx9P4flD3vUO3 jfZM2ykwkr7DT6+E6UaW1F6uG/wUc9seAwj5YkhLetyjQmraFeXr/eK+Y1EwYzTX+Tsr T8iMGRVAC+hDC1GbJ1TOiTNKorCEJAMTQFx1dhrI7LvxJz6mFJXMjKFeC6dmF27non2h p6xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ezllr7eDiRUizNMTgjavroMASuo7yOtes/hxla0Sh7c=; b=XvMMvuKyvxtl99UiwDmcQHNeyYONtyDTGrj+70gptKfmxK/DbFWwJf0ATeyI6OxQ8u 7IeK9ZnB5lMXS8QCjVeGc7fZf0WjF3PztzPMVsNhvMH7+ap/5akIplte4va6LFFXSlXa OCT1f9sKBrTulqJxY5gOglHWdsj4cXUFbU+MPdYL+P9V3dJmuYLfiyAFHis7oQE27xHV liS/rmbjKK/Rku8HXE6EPav2KdxLpvEN65DCUN9Go27NJscpxtI4pp97DM0tjOoLHHlD HXmVdvKOZnMkLiMW96AOURj8tCAg9S+Cndr3WzNm74KoPgMsIy6aiKsk2s6kthdMWihS 0YhA== X-Gm-Message-State: AElRT7FdMGH5aqaZJHkrdTJzIqp1NtQzBP+Wry/EqMP3Y7W1ZfGvn6Ws FzsqCO3pg4F5eYqNlt+kTyBZfItI/AjdltjTju8F9A== X-Google-Smtp-Source: AG47ELsyopP9E/nCFlhXl7ZrZg/77kUCQSom+4372/3BabOiJkmRZz7fa8ynmcZQt65x2sOxHmVIQDM5A4i7upnIoyk= X-Received: by 10.107.142.79 with SMTP id q76mr9729167iod.299.1521134748195; Thu, 15 Mar 2018 10:25:48 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.203.196 with HTTP; Thu, 15 Mar 2018 10:25:47 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201803151723.w2FHNJ5a094121@pdx.rh.CN85.dnsmgr.net> References: <201803151723.w2FHNJ5a094121@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Thu, 15 Mar 2018 11:25:47 -0600 X-Google-Sender-Auth: 7rUPyhDgdhxV6UwbdoDE9FWSxD0 Message-ID: Subject: Re: svn commit: r330972 - stable/11/share/misc To: "Rodney W. Grimes" Cc: Ian Lepore , Justin Hibbits , Andriy Gapon , Eitan Adler , src-committers , svn-src-all@freebsd.org, svn-src-stable@freebsd.org, svn-src-stable-11@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2018 17:25:49 -0000 On Thu, Mar 15, 2018 at 11:23 AM, Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Mar 15, 2018 at 10:31 AM, Warner Losh wrote: > > > > > > > > > > > On Thu, Mar 15, 2018 at 10:20 AM, Ian Lepore 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 > > >> > > > 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