Date: Mon, 27 Jun 2016 12:02:46 +0200 From: Guido Falsi <mad@madpilot.net> To: freebsd-ports@freebsd.org Subject: Re: blanket portmgr approval vs. non-fixing changes Message-ID: <18e609c1-e095-99b0-893a-0bb30d3c3d45@madpilot.net> In-Reply-To: <5770EED4.1070202@tu-dortmund.de> 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> <5770EED4.1070202@tu-dortmund.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 06/27/16 11:16, Matthias Andree wrote: > [Sorry for this re-send, I feel we need to re-send thisto ports@ so the > discussion goes to a public and archived list.] > > 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. I'd say that it's a matter of urgency for the change. Need for urgency is evident for broken ports and also serious security issues. It could be less evident for infrastructure changes which need to be urgently deployed to a major number of ports, or changes to head which require patching a lot of ports (one good example could be the recent update to libc++ 3.8.0 in head, even if it could be accounted as "broken ports" case, so with a relatively high degree of urgency). > 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. > I agree with this, if there is no urgency there's no need to leverage a blanket. > 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. I agree on adding a note on the blankets encouraging patches to go through a PR whenever they are not urgent. This raises the problem of having a good definition of urgent. I have stated above what I think is urgent. I'd like to add that changes to the ports infrastructure aren't always urgent, the general blanket was created at a time when a lot of things were changing in the ports tree and there was a need for a fast application of those changes, since the state of the tree was hindering progress. We are now in a much better situation and most changes are less urgent, and can wait some time. I'd say usually such changes should go through bugzilla or phabric review, with portmgr adding special case blankets for specific changes which should hit the tree as soon as possible, if this is not an excessive burden on portmgr. I'm not sure I agree on lowering the 14 days timeout for bug reports. I usually reply in a matter of hours if at all possible, 2-3 days when I take a long time, at least with a "going to test" message, but not all people can manage this, lowering timeouts could raise the bar on being a maintainer which is something I think we should avoid. > > - 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. I think it could be enough to state a list of make targets which one must warrant keep working, it's obvious that make config, make install and make deinstall should work correctly, less obvious for other targets. -- Guido Falsi <mad@madpilot.net>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18e609c1-e095-99b0-893a-0bb30d3c3d45>