From owner-svn-src-stable-11@freebsd.org Thu Mar 15 17:25:49 2018 Return-Path: Delivered-To: svn-src-stable-11@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 7317E314 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 F12936CFD1 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 m83so9452300ioi.8 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=D3TQ6/rP2elLt4QXWKRo79KUbpC5rKLPAiF+rsBuWmr3hzEVb8bHCajpVnNF4DESDE wxVqoBDV+IWiy1hlV/oLE/sUu/UawDtJggtDoNpJWDvFkRBpTZZ23gCtAEAQXCleqqn0 +J+NA0YJ6icO7Tydlz7FRdI3dVw4ibLvcmnWnYVTYpjvmo3kwPMaZ5S8pOP6YadclZyb 78P2hCqe9Fmj/CEBoB6MyOn3rd6aACK2hziDmVB/ntyn7xFXZW1La0aYcPfBMxUSwcOo 9roQXcd4CWBtUnvDU1dg2nM05LQdKeZiG4ja41CEwB8xASac7eqFyhzCiBwpj9qScQH0 bQQw== X-Gm-Message-State: AElRT7E2a6mfGQUxIwR/ButPaDYESOrIyP4cxmmYH0zC3/fcTs2EUsWP t+Kgi63AZQLMHm+X2zPRJpSdzY8odzBqzeCEySzFSA== 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-stable-11@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for only the 11-stable src tree 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