From owner-freebsd-ports@freebsd.org Mon Jun 27 14:25:48 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 5CA82B81CDF for ; Mon, 27 Jun 2016 14:25:48 +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 8DC5425FD; Mon, 27 Jun 2016 14:25:47 +0000 (UTC) (envelope-from adamw@adamw.org) Received: by apnoea.adamw.org (OpenSMTPD) with ESMTPSA id 28bdceb0 TLS version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO; Mon, 27 Jun 2016 08:25:25 -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 (was: svn commit: r417590 - in head/databases/db6: . files and 417595 (revert)) From: Adam Weinberger In-Reply-To: Date: Mon, 27 Jun 2016 08:25:42 -0600 Cc: 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: <2A4F1FFE-8B27-4569-8CCA-D498B5235D18@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> To: araujo@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 14:25:48 -0000 > 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: > > > > > > +--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: > > |> | > > |> = https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintainer > > |> | .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. > > > > 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. > > > > 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, > , 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 > 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 >=20 > - we discuss about an assisting set of "change these variables > foo.*regexp, and you also need to test 'make foo' and 'make bar'" = rules > in the form of a concise list. Maintainership too often means that change requests get ignored for two = weeks before they're committed. 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. Any committer should be able to commit to any port. That used to be what = ports@FreeBSD.org meant, that it was being maintained by everybody. But = somehow, in the last few years that turned into a message that it's = being maintained by nobody, so now ports *have* to be maintained by = somebody, even if that person never touches it again. # Adam --=20 Adam Weinberger adamw@adamw.org http://www.adamw.org