Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 27 Jun 2016 09:49:15 -0600
From:      Adam Weinberger <adamw@adamw.org>
To:        koobs@FreeBSD.org
Cc:        araujo@freebsd.org, 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:  <031F150B-A701-405E-AE9B-62EC548CF8A2@adamw.org>
In-Reply-To: <9364c255-9733-b1a0-68a1-a058ca78d95e@FreeBSD.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> <9364c255-9733-b1a0-68a1-a058ca78d95e@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
> On 27 Jun, 2016, at 9:22, Kubilay Kocak <koobs@FreeBSD.org> wrote:
>=20
> On 28/06/2016 12:25 AM, Adam Weinberger wrote:
>>> On 27 Jun, 2016, at 3:27, Marcelo Araujo <araujobsdport@gmail.com>
>>> wrote:
>>>=20
>>>=20
>>>=20
>>> 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:
>>>>=20
>>>>=20
>>>> +--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:=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
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208740>, 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






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?031F150B-A701-405E-AE9B-62EC548CF8A2>