From owner-freebsd-ports@freebsd.org Mon Jun 27 15:49:21 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 799CFB84EA2 for ; Mon, 27 Jun 2016 15:49:21 +0000 (UTC) (envelope-from adamw@adamw.org) Received: from apnoea.adamw.org (apnoea.adamw.org [204.109.59.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "apnoea.adamw.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A08F220E; Mon, 27 Jun 2016 15:49:20 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by apnoea.adamw.org (OpenSMTPD) with ESMTPSA id 125a260d TLS version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 27 Jun 2016 09:48:57 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: blanket portmgr approval vs. non-fixing changes From: Adam Weinberger In-Reply-To: <9364c255-9733-b1a0-68a1-a058ca78d95e@FreeBSD.org> Date: Mon, 27 Jun 2016 09:49:15 -0600 Cc: araujo@freebsd.org, Matthias Andree , Mathieu Arnold , marino@freebsd.org, Sunpoet Po-Chuan Hsieh , ports-committers , FreeBSD Ports Management Team , freebsd-ports Content-Transfer-Encoding: quoted-printable Message-Id: <031F150B-A701-405E-AE9B-62EC548CF8A2@adamw.org> References: <201606261724.u5QHOLdG081392@repo.freebsd.org> <57701AEB.1050001@tu-dortmund.de> <5770A392.6010605@tu-dortmund.de> <84e4fcf5-7b99-1cc6-e6bd-d3c594a5d102@marino.st> <91BC5F8F9FDB9246529D0693@atuin.in.mat.cc> <5770EAD2.4060302@tu-dortmund.de> <2A4F1FFE-8B27-4569-8CCA-D498B5235D18@adamw.org> <9364c255-9733-b1a0-68a1-a058ca78d95e@FreeBSD.org> To: koobs@FreeBSD.org X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:49:21 -0000 > On 27 Jun, 2016, at 9:22, Kubilay Kocak wrote: >=20 > On 28/06/2016 12:25 AM, Adam Weinberger wrote: >>> On 27 Jun, 2016, at 3:27, Marcelo Araujo >>> wrote: >>>=20 >>>=20 >>>=20 >>> 2016-06-27 16:58 GMT+08:00 Matthias Andree >>> : Am 27.06.2016 um 10:16 schrieb >>> Mathieu Arnold: >>>>=20 >>>>=20 >>>> +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo >>>> wrote: | 2016-06-27 16:02 GMT+08:00 >>>> Mathieu Arnold : |> | Read here for reference:=20 >>>> |> | |> >>>> = https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer >>>>=20 >>>>=20 > |> | .html >>>> |> |> That pages says, exactly the opposite of what you are >>>> trying to says: |> | | No it doesn't! | | And this is the normal >>>> workflow: | 1) Port has a maintainer, and it needs update. | 2) >>>> Open a PR with the patch. | 3) After 2 weeks, and with timeout; >>>> anybody can commit it. | | | And about the ownership and belong >>>> to the community, I do believe in that, | that is the basic in a >>>> legal point of view. >>>>=20 >>>> That page says that the maintainer has to be consulted, except >>>> for changes covered by the blanket approval, where the change can >>>> be committed immediately. >>>>=20 >>>> In this case, Sunpoet had every right to commit the thing he did >>>> without asking or notifying the maintainer. >>>=20 >>>=20 >>> TL;DR given at the very end. >>>=20 >>>=20 >>> 1. Given the portmgr@ rules, that is our current policy, that >>> portmgr@ as the overseers of the ports system have delegated, by >>> the blanket approval, part of their ultimate responsibility to the >>> public. >>>=20 >>> 2. What I was meaning to state was that (and I'll not pick at the >>> kind soul who has modernized the port) we should only apply the >>> blanket approval if ports have fallen into disrepair. >>>=20 >>>=20 >>> 2b. This was not the case with db6, the port wasn't known broken to >>> me, so why do we permit and encourage going the fast path for >>> changes that do not /repair/ a port (for instance, if it's not >>> building, to fix misspellings), and I'm surprised because some two >>> months ago, it has already gone through a modernization round after >>> gahr's PR,=20 >>> , that >>> also combined a feature addition and required a bit more work to >>> get right, see changesets 415741 and 415743. >>>=20 >>>=20 >>> 3. What would have been bad about filing a PR in this case? >>>=20 >>> The argument "maintainers aren't doing it" is covered by the >>> maintainer timeout. Anything that does not need the fast path >>> should go through some form of review, most naturally through a PR >>> filed to the port's maintainer. >>>=20 >>>=20 >>> 4. Do we need to tighten up the set of required tests a committed >>> does before committing non-maintainer updates? >>>=20 >>> I'm scratching my head over this one since the failure in r417590 >>> that got remedied in r417595 was rather peculiar, and I'm not sure >>> if anyone, including myself, would have figured that out. It might >>> have slipped through the cracks even if I'd reviewed it. >>>=20 >>> 4b. It's probably better to extend the committer's guide and/or >>> porter's handbook and have a list of test recommendations where we >>> list things that trigger a certain test requirement. I. e. things >>> to test IN ADDITION to the usual "poudriere testport" or "make >>> DEVELOPER=3Dyes clean all check-plist package" and portlint = coverage. >>> Meaning that if someone tweaks any of the WRK* and >>> *DIR/*SRC-related variables, "also test 'make clean extract >>> do-patch makepatch' on a copy of the port directory" or=20 >>> thereabouts. >>>=20 >>> mat@ thanks for all the explanation and time. >>>=20 >>> Unfortunately, I still make things a bit manual at my side, but >>> usually my testbed is: 1) Portlint. 2) Make and likes on i386 and >>> amd64(clean vm). >>>=20 >>> I think, include more information about test recommendations is >>> always good. >>>=20 >>>=20 >>>=20 >>> There seem to be at least two distinct camps, in one camp, >>> maintainers go along Marcelo's and my trains of thought, in the >>> other, maintainers cherish fast and low-ceremony progress, marino >>> has argued along these lines, and some other portmgr@ members have >>> pushed for progress in the past. >>>=20 >>> I don't mean to bikeshed or split up our project here, just refine >>> our existing policies. >>>=20 >>>=20 >>> TL;DR: I propose: >>>=20 >>> - the blanket approval should be tightened up a bit and encourage >>> that non-trivial and non-urgent changes go through the PR and >>> invoke mantainer timeout after the shortest possible period. >>>=20 >>> Personally, I like the first option! And in addition, we have >>> phabricator as an option too, at least for src, the reviews are >>> made very quickly. So, could be defined a short timeout, at least >>> for those that are active and would like to help make a review, >>> seems something reasonable. >>>=20 >>> Also I do understand about all the modernization and definitely we >>> need it, maybe 2 days timeout is enough for an active maintainer to >>> reply that he is busy or he is working on that. >>>=20 >>>=20 >>>=20 >>> - we discuss about an assisting set of "change these variables=20 >>> foo.*regexp, and you also need to test 'make foo' and 'make bar'" >>> rules in the form of a concise list. >>=20 >> Maintainership too often means that change requests get ignored for >> two weeks before they're committed. >>=20 >> Aside from large, complex, interconnected systems, I think that we >> should do away with ports maintainership entirely. Maintainership >> serves absolutely no purpose that peer-review wouldn't do better. >=20 > There's two senses of 'ownership' that are often conflated, or at = least > almost never made explicit. >=20 > The kind we want, more of, and would hate to lose: >=20 > - responsibility, accountability, pride in 'looking after' something >=20 > The other we don't: >=20 > - territorial, xenophobic (mine/yours, ours/theirs), hoarding, = exclusive use >=20 > Which one we have, get, or foster, has everything to do with how we > teach people we do things around here, how clearly we articulate our > goals and intentions, and nothing to do with MAINTAINER intrinsically. >=20 > All: How did you feel the first time you saw your email on a = maintainer > line? That is priceless and shouldn't be confused with the 'bad' kind = of > ownership. You're a wise man, koobs. What I said was a classic nirvana fallacy. = That feeling of seeing my name on a maintainer line is precisely why I = contributed to FreeBSD a second time. And you're completely right that = there is a difference between owning a toy and being the only one = allowed to play with it. I am a huge fan of the blanket. I'd sent an email to portmgr requesting = it shortly before it got announced. So whether or not one had anything = to do with the other, I like to pretend that I played a part in its = creation. I guess I just don't understand why it really bothers some = others. # Adam --=20 Adam Weinberger adamw@adamw.org http://www.adamw.org