Bug 229859

Without getting drawn into a bikeshed, wouldn't the easiest thing have been to add a note to the commit, something along the line "commmited (N.B. Newer version committed than in the original submission)" or something like that?

I've often seem commit statements like

"Maintainer update committed. (plus various style changes by me)

Thanks!"

Comment 2 Mathieu Arnold 2018-07-18 15:41:42 UTC

I completely disagree with this change.

Comment 3 Mathieu Arnold 2018-07-18 15:43:14 UTC

What this change does is that it allows committers to simply do whatever they want.  If they want to upgrade a port, all they need to do is find a PR about it fixing a typo, and then they can say, "oh, while I changed that typo, I upgraded to the newest version".

Comment 4 Yuri Victorovich 2018-07-18 17:10:09 UTC

+1

Comment 5 Kurt Jaeger 2018-07-18 18:53:37 UTC

(In reply to Mathieu Arnold from comment #3)
Yes, this can happen. I hope and guess that this would not be the 'new normal'.

Is there an easy way to detect this case ? In which cases would it be
'very-bad', in which cases would it be 'unfortunate' ? How many times
would the maintainer 'not care' ?

Do I understand you correctly that you suspect that it would undermine
the role of the maintainer, so that in the long run being a maintainer
would not be seen as a useful role ?

On the other hand, do we really have the problem that we move too fast ?
To be honest, some DEPRECATE and EXPIRE runs in the past ran into opposition...

Comment 6 Mathieu Arnold 2018-07-19 08:20:07 UTC

(In reply to Kurt Jaeger from comment #5)
> Do I understand you correctly that you suspect that it would undermine
> the role of the maintainer, so that in the long run being a maintainer
> would not be seen as a useful role ?

The change you proposes creates a very bad precedent. It would mean that committers are somehow above other people, and can decide to do whatever they want and the maintainer would have to check that the change they wanted to make to the port that they maintain (and thus, know better than the committer) was actually made the way they wanted.

The policy in place says that submissions can be linted by committers, and this is because committers are supposed to know how to use the framework better than contributors. It is their main reason we have committers, a small group of people who know how the framework works and make sure submissions conform with its policies.

But maintainers know their ports better than committers.

If a committer want to change something that is not covered by the blanket approval, they can do like every other contributor, create a patch and open a PR.  I do this regularly, I then use the snoozetab firefox extension to recall the tab with that PR in two weeks, and then I go do something else while it stews.  Then I either get the tab back a couple of weeks later, or get an email from bugzilla if someone commented on the PR to say yes, no or whatever.

Comment 7 Yuri Victorovich 2018-07-19 08:44:45 UTC

Maybe this should be limited to the port submission process, since this is a special case.

> Committers will take liberty to extensively check newly submitted ports,
> and may fix any issues and make any alterations they see fit before comitting
> ports.

This happens anyway, this clause is just to officially state that this is what should be expected.

Comment 8 Mathieu Arnold 2018-07-20 12:21:16 UTC

I do not see the new port submission to be anything special.  A maintainer spent time working on a port, a committer cannot simply rip everything apart and do whatever they want.

When a new port is submitted, a committer has the exact same liberties they can have than when an update is submitted. They can fix whatever issues are in the blanket approval, and that is it.

Maybe that is not what *you* are doing, but in that case, you are wrong in doing what you are doing.

I do not say the maintainer will not want the extra changes you want to make, but they should be consulted first.

Comment 9 Kurt Jaeger 2018-07-29 09:37:45 UTC

(In reply to Mathieu Arnold from comment #8)
In general, committers have no intention to rip every submission apart.
And maintainers/submitters see the work of committers as helpful, not as
dis-owning. So the question is: does the trust between maintainer/submitter and committer exist or does it need strict rules ?

With a group of approx. 200 ports committers, and from what I can see,
we can still build on mutual trust. Even if we expand the number of committers, it would still work out for a while.

Comment 10 Mathieu Arnold 2018-08-03 07:33:17 UTC

The current rules are just fine, so, I am rejecting this change.