Date: Tue, 28 Jun 2016 01:22:45 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: Adam Weinberger <adamw@adamw.org>, araujo@freebsd.org Cc: Matthias Andree <matthias.andree@tu-dortmund.de>, Mathieu Arnold <mat@freebsd.org>, marino@freebsd.org, Sunpoet Po-Chuan Hsieh <sunpoet@freebsd.org>, ports-committers <ports-committers@freebsd.org>, FreeBSD Ports Management Team <portmgr@freebsd.org>, freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: blanket portmgr approval vs. non-fixing changes Message-ID: <9364c255-9733-b1a0-68a1-a058ca78d95e@FreeBSD.org> In-Reply-To: <2A4F1FFE-8B27-4569-8CCA-D498B5235D18@adamw.org> References: <201606261724.u5QHOLdG081392@repo.freebsd.org> <57701AEB.1050001@tu-dortmund.de> <AABF87BCD32C14B8477C3620@atuin.in.mat.cc> <5770A392.6010605@tu-dortmund.de> <84e4fcf5-7b99-1cc6-e6bd-d3c594a5d102@marino.st> <CAOfEmZj3PzOgcpxb3WO%2B%2BSmSADf2sCt9_sKQ6dCbgwz6pRV4nQ@mail.gmail.com> <D9A4D908FD34A6F242BBD895@atuin.in.mat.cc> <CAOfEmZhzaM7K-L1gWO9%2Bc2s2nSsQaPr1eP=%2Bg65m6-brmEQd=Q@mail.gmail.com> <91BC5F8F9FDB9246529D0693@atuin.in.mat.cc> <5770EAD2.4060302@tu-dortmund.de> <CAOfEmZiSKSZMDs3vrpCn3mofY87U6w-kDoqq0X6b_fEpqgiCjQ@mail.gmail.com> <2A4F1FFE-8B27-4569-8CCA-D498B5235D18@adamw.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 28/06/2016 12:25 AM, Adam Weinberger wrote: >> On 27 Jun, 2016, at 3:27, Marcelo Araujo <araujobsdport@gmail.com> >> wrote: >> >> >> >> 2016-06-27 16:58 GMT+08:00 Matthias Andree >> <matthias.andree@tu-dortmund.de>: Am 27.06.2016 um 10:16 schrieb >> Mathieu Arnold: >>> >>> >>> +--On 27 juin 2016 16:10:36 +0800 Marcelo Araujo >>> <araujobsdport@gmail.com> wrote: | 2016-06-27 16:02 GMT+08:00 >>> Mathieu Arnold <mat@freebsd.org>: |> | 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. >> >> >> TL;DR given at the very end. >> >> >> 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. >> >> 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. >> >> >> 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, >> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208740>, that >> also combined a feature addition and required a bit more work to >> get right, see changesets 415741 and 415743. >> >> >> 3. What would have been bad about filing a PR in this case? >> >> 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. >> >> >> 4. Do we need to tighten up the set of required tests a committed >> does before committing non-maintainer updates? >> >> 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. >> >> 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=yes 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. >> >> mat@ thanks for all the explanation and time. >> >> 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). >> >> I think, include more information about test recommendations is >> always good. >> >> >> >> 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. >> >> I don't mean to bikeshed or split up our project here, just refine >> our existing policies. >> >> >> TL;DR: I propose: >> >> - 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. >> >> 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. >> >> 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. >> >> >> >> - 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. There's two senses of 'ownership' that are often conflated, or at least almost never made explicit. The kind we want, more of, and would hate to lose: - responsibility, accountability, pride in 'looking after' something The other we don't: - territorial, xenophobic (mine/yours, ours/theirs), hoarding, exclusive use 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. 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. > 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 > Having a discussion after an example of fallout (whether correct or not), is unfortunately, precisely the worst time (reactively) to be making well-informed, collaborative decisions. What we don't disagree on: - High quality changes, minimal user impact - Minimal latency and barriers to progress (not at the cost of quality) - Ways for contributors to specialise or take on greater responsibility if they want to and can. The above are *not* mutually exclusive goals, they do however require people to think beyond single priority solutions. Finally, if the question is: "How can we have all of them?", what are the possibilities? ./koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9364c255-9733-b1a0-68a1-a058ca78d95e>