svn commit: r412296 - head/lang/rust

[Thomas Zander]

On 1 April 2016 at 14:56, Erwin Lansing <erwin at freebsd.org> wrote:
>
>> On 01 Apr 2016, at 15:06, Mathieu Arnold <mat at FreeBSD.org> wrote:
>>
>> +--On 1 avril 2016 12:05:47 +0200 Thomas Zander <riggs at freebsd.org> wrote:
>> | On 1 April 2016 at 11:45, Mathieu Arnold <mat at freebsd.org> wrote:
>> |
>> |> It is documented in the porter's handbook, where it all belongs:
>> |> <https://www.freebsd.org/doc/en/books/porters-handbook/makefile-maintain
>> |> er.html>
>> |>
>> |> And, it is covered by the "Trivial and tested build and runtime fixes."
>> |> bullet point.
>> |
>> | Thanks for stepping in, but I am a 100% sure that this statement will
>> | not put the case to rest. Based on this statement:
>> | - John will maintain his position that this commit was trivial, tested
>> | and fixes a problem *on DragonFly* and hence *is* covered by the
>> | blanket
>> | - I will maintain my position that this commit does *not* fix a
>> | problem *on FreeBSD* and hence is *not* covered by the blanket
>> |
>> | I am totally fine accepting any verdict from portmgr, but I want it to
>> | be inescapably clear. Please review the commit and let us know once
>> | and for all: Is this particular one covered by the blanket or not?
>>
>> *I* would say that you are right and it's not a FreeBSD fix, and thus, is
>> not covered by the blanket.  But I don't know what portmgr as a whole
>> thinks about it.
>
> Rather than nitpick what the rules say exactly, I’d take a step back and consider how we like to work together.  On the surface, it indeed seems a trivial commit, but on the other hand the port has an active maintainer, from whom a quick reply could be expected.  Taken together, I would have chosen to ask the maintainer first, out of respect for the maintainer.  In a similar situation, I would imagine myself as the maintainer and how I would feel if I saw a commit happen to my port and wonder why the change was so important it couldn’t wait for me to have a look at it first.  We have this great technological platform, but in the end it’s the people that make this project.  Just because there is a rule or policy that might allow one to do something, does not mean it’s the right thing to do.

Thank you for sharing these thoughts.
Frankly, I didn't expect this discussion to continue for so long, and
I want to be clear about one thing: I have no doubt that Jan did this
commit with best intentions, and totally convinced that he is
following the rules and conventions. Exactly this is the reason why I
was so picky asking about what the rules were. It is not uncommon for
patches intending to fix something to introduce a more substantial
change, and it is very clear that there is no one true golden rule
that tells us what exactly is a trivial fix. There is room for
interpretation, as with most human language expressions. I lean
towards requesting maintainer approval for almost any change, but this
apparently varies from person to person. Within the project we should
try converge to a common understanding. This discussion just shows
that there is still some converging to do :)

Riggs