Merging pull requests before 72 hours

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Merging pull requests before 72 hours

Mojca Miklavec-2
Hi,

This conversation comes from
    https://github.com/macports/macports-ports/pull/2785
and I wanted to bring it up to the mailing list.

In summary: Ryan objected merging openmaintainer pull requests prematurely.
I'm with Ryan on this one.

On Fri, 12 Oct 2018 at 15:04, Perry E. Metzger wrote:
> On Fri, 12 Oct 2018 at 07:39, Ryan Schmidt wrote:
>> On Thu, 11 Oct 2018 at 18:01, Perry E. Metzger wrote:
>>>
>>> I had little confidence that he would know it happened,

If this is ever the case, we would need to change our system. But I
agree that the maintainer must have seen this. If he didn't, we need
to let him know about the problem (there are some who disabled all
email traffic and then never get any notifications; those maintainers
should fix their preferences to include email for cases when they are
mentioned).

>>> plus it's listed as
>>> openmaintainer, and, like it or not, your updates are almost always perfect,
>>> there's rarely any dissent against them, so you get treated differently.
>>
>> Why? I assigned the PR to him, and macportsbot also notified him.
>>
>>> plus it's listed as openmaintainer,
>>
>> Yes but in the past some maintainers have objected even to simple version
>> updates being performed on their openmaintainer ports without their consent.
>> Developers who are not the maintainer might not be aware all the implications
>> that updating the version of one port might have on other ports for example.

Precisely. What may seem like a totally trivial and straight update to
you, consisting of nothing else but version bump and checksum changes,
may introduce dramatic changes or incompatibilities.

(Oh, look, python 2.7 has now been update to python 3.x, let's update
it. Oh, see, a new version of poppler just came out. Let's update just
this one; the travis job succeeds, that's sufficient right?)

Also, many people hardly test anything when submitting a PR. I need to
confess that is often true for me even for commits that circumvent the
PR. If a version of a port I trust changes, I would often only check
whether the build succeeds, or if the test suite passes in case there
is one (which is most often not the case). The cases when I go to the
trouble of verifying the consequences on all the dependent ports
beyond whether or not they build are very very very rare.

A while ago we had something that looked like a completely innocent
update of Lua (5.2 to 5.3) which literally broke EVERY SINGLE
dependency, most of them beyond repair. I knew this would happen, but
someone simply went forward and committed the update without asking
anyone for opinion. Circumventing the maintainer might have similar
consequences.

>> And this PR was more than just updating the version: I also reformatted the
>> entire port's whitespace. While I stand by those changes, reformatting someone
>> else's port is not something we should probably do without asking permission first;
>> this PR was how I was asking Toby's permission, and by merging the
>> PR before he had a chance to look at it, he didn't get the opportunity to give it.
>>
>>> and, like it or not, your updates are almost always perfect, there's rarely any
>>> dissent against them, so you get treated differently.
>>
>> If I want to commit an update, I'll do that. If I go to the effort of filing a PR,
>> it's because I want to give the maintainer of the port the opportunity to be aware
>> of the proposed change and to voice any objections before it gets committed.
>> I appreciate that you reviewed my changes and found them suitable, but if a
>> port has a maintainer, we should really give them the opportunity to fulfill that role.

Agreed.

> Then they should remove openmaintainer from their port.

While I'm not entirely sure about the exact difference between
maintainer and non-maintainer, I disagree.

> openmaintainer means
> that you can perform simple version updates without explicit approval.

Simple changes. What looks like a simple version update might not be
that (let's update python 2.7 to python 3.7, just version change and
checksum updates, simple ...)

> If they don't want that, they can just commit a change removing it.
>
> We are in a situation where most, if not the overwhelming bulk, of our ports with
> maintainers are de facto abandoned.

Which means that we should address that particular problem (maybe more
aggressively than we do now) rather than ignore maintainer field. If
you commit within a few hours, we don't even know whether a port is
abandoned or not. Before PRs were a thing, we would always append
"maintainer timeout" to commit messages. This happened to be super
useful. When I would want to update a port, I would run svn/git log
and if all the commit messaged said "maintainer timeout" a couple of
times, this would send a very strong signal that I should probably
file a port abandoned ticket.

Maybe we should reintroduce this and always when there's a 72-hour
maintainer timeout:
- change the commit message
- check whether the person is otherwise (in)active (when was he/she
last active either or the list or doing a commit, ...)
- file a port abandoned ticket in case it seems appropriate

And maybe we should, just once:
- collect a list of all maintainers
- remove those whose last commit was within the last year
- send an email to everyone else, asking if they are still maintaining
their ports, repeat that email two or three times
- remove everyone else whose email bounced or got no reply

But let's not ignore our existing maintainer policy just because we
have issues elsewhere.

Our main problem are tickets which have been opened for 2-10 years. I
really really really do appreciate the work you Perry are doing to our
PR queue, but waiting 72 hours won't actually make the PR queue any
shorter. Yes, there might be 30 PR open for the last three days, but
those are usually not the problematic ones. After three days it's
perfectly fine to merge them.

> The fraction of the time when someone
> ever comments on a proposed update is very, very low.
> I don't know why this is, but it's indeed the case. Keeping MacPorts functioning
> requires that we operate even in the presence of this. openmaintainer means that
> we can keep the pull queue reasonably clear when we have relatively high
> assurance that an update is harmless and well tested. If it becomes meaningless,
> we'll have a lot of trouble functioning. If people don't want others touching their
> ports, they should remove openmaintainer and not insist that it means the same
> thing as closed maintainer.

Maybe we can discuss this again later, but let's first fix the real
problem (clean up the inactive maintainers etc) ...

Mojca

PS: I would actually be in favour of replacing openmaintainer by
closemaintainer. That is: to any port with missing "openmaintainer"
keyword, add "closemaintainer". Then remove the "openmaintainer" tag
from all other ports. The we wouldn't need to ask each individual
first-time contributor to please add the "openmaintainer" tag.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Blair Zajac
We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.

Blair

> On Oct 14, 2018, at 3:06 PM, Mojca Miklavec <[hidden email]> wrote:
>
> Hi,
>
> This conversation comes from
>    https://github.com/macports/macports-ports/pull/2785
> and I wanted to bring it up to the mailing list.
>
> In summary: Ryan objected merging openmaintainer pull requests prematurely.
> I'm with Ryan on this one.
>
> On Fri, 12 Oct 2018 at 15:04, Perry E. Metzger wrote:
>> On Fri, 12 Oct 2018 at 07:39, Ryan Schmidt wrote:
>>> On Thu, 11 Oct 2018 at 18:01, Perry E. Metzger wrote:
>>>>
>>>> I had little confidence that he would know it happened,
>
> If this is ever the case, we would need to change our system. But I
> agree that the maintainer must have seen this. If he didn't, we need
> to let him know about the problem (there are some who disabled all
> email traffic and then never get any notifications; those maintainers
> should fix their preferences to include email for cases when they are
> mentioned).
>
>>>> plus it's listed as
>>>> openmaintainer, and, like it or not, your updates are almost always perfect,
>>>> there's rarely any dissent against them, so you get treated differently.
>>>
>>> Why? I assigned the PR to him, and macportsbot also notified him.
>>>
>>>> plus it's listed as openmaintainer,
>>>
>>> Yes but in the past some maintainers have objected even to simple version
>>> updates being performed on their openmaintainer ports without their consent.
>>> Developers who are not the maintainer might not be aware all the implications
>>> that updating the version of one port might have on other ports for example.
>
> Precisely. What may seem like a totally trivial and straight update to
> you, consisting of nothing else but version bump and checksum changes,
> may introduce dramatic changes or incompatibilities.
>
> (Oh, look, python 2.7 has now been update to python 3.x, let's update
> it. Oh, see, a new version of poppler just came out. Let's update just
> this one; the travis job succeeds, that's sufficient right?)
>
> Also, many people hardly test anything when submitting a PR. I need to
> confess that is often true for me even for commits that circumvent the
> PR. If a version of a port I trust changes, I would often only check
> whether the build succeeds, or if the test suite passes in case there
> is one (which is most often not the case). The cases when I go to the
> trouble of verifying the consequences on all the dependent ports
> beyond whether or not they build are very very very rare.
>
> A while ago we had something that looked like a completely innocent
> update of Lua (5.2 to 5.3) which literally broke EVERY SINGLE
> dependency, most of them beyond repair. I knew this would happen, but
> someone simply went forward and committed the update without asking
> anyone for opinion. Circumventing the maintainer might have similar
> consequences.
>
>>> And this PR was more than just updating the version: I also reformatted the
>>> entire port's whitespace. While I stand by those changes, reformatting someone
>>> else's port is not something we should probably do without asking permission first;
>>> this PR was how I was asking Toby's permission, and by merging the
>>> PR before he had a chance to look at it, he didn't get the opportunity to give it.
>>>
>>>> and, like it or not, your updates are almost always perfect, there's rarely any
>>>> dissent against them, so you get treated differently.
>>>
>>> If I want to commit an update, I'll do that. If I go to the effort of filing a PR,
>>> it's because I want to give the maintainer of the port the opportunity to be aware
>>> of the proposed change and to voice any objections before it gets committed.
>>> I appreciate that you reviewed my changes and found them suitable, but if a
>>> port has a maintainer, we should really give them the opportunity to fulfill that role.
>
> Agreed.
>
>> Then they should remove openmaintainer from their port.
>
> While I'm not entirely sure about the exact difference between
> maintainer and non-maintainer, I disagree.
>
>> openmaintainer means
>> that you can perform simple version updates without explicit approval.
>
> Simple changes. What looks like a simple version update might not be
> that (let's update python 2.7 to python 3.7, just version change and
> checksum updates, simple ...)
>
>> If they don't want that, they can just commit a change removing it.
>>
>> We are in a situation where most, if not the overwhelming bulk, of our ports with
>> maintainers are de facto abandoned.
>
> Which means that we should address that particular problem (maybe more
> aggressively than we do now) rather than ignore maintainer field. If
> you commit within a few hours, we don't even know whether a port is
> abandoned or not. Before PRs were a thing, we would always append
> "maintainer timeout" to commit messages. This happened to be super
> useful. When I would want to update a port, I would run svn/git log
> and if all the commit messaged said "maintainer timeout" a couple of
> times, this would send a very strong signal that I should probably
> file a port abandoned ticket.
>
> Maybe we should reintroduce this and always when there's a 72-hour
> maintainer timeout:
> - change the commit message
> - check whether the person is otherwise (in)active (when was he/she
> last active either or the list or doing a commit, ...)
> - file a port abandoned ticket in case it seems appropriate
>
> And maybe we should, just once:
> - collect a list of all maintainers
> - remove those whose last commit was within the last year
> - send an email to everyone else, asking if they are still maintaining
> their ports, repeat that email two or three times
> - remove everyone else whose email bounced or got no reply
>
> But let's not ignore our existing maintainer policy just because we
> have issues elsewhere.
>
> Our main problem are tickets which have been opened for 2-10 years. I
> really really really do appreciate the work you Perry are doing to our
> PR queue, but waiting 72 hours won't actually make the PR queue any
> shorter. Yes, there might be 30 PR open for the last three days, but
> those are usually not the problematic ones. After three days it's
> perfectly fine to merge them.
>
>> The fraction of the time when someone
>> ever comments on a proposed update is very, very low.
>> I don't know why this is, but it's indeed the case. Keeping MacPorts functioning
>> requires that we operate even in the presence of this. openmaintainer means that
>> we can keep the pull queue reasonably clear when we have relatively high
>> assurance that an update is harmless and well tested. If it becomes meaningless,
>> we'll have a lot of trouble functioning. If people don't want others touching their
>> ports, they should remove openmaintainer and not insist that it means the same
>> thing as closed maintainer.
>
> Maybe we can discuss this again later, but let's first fix the real
> problem (clean up the inactive maintainers etc) ...
>
> Mojca
>
> PS: I would actually be in favour of replacing openmaintainer by
> closemaintainer. That is: to any port with missing "openmaintainer"
> keyword, add "closemaintainer". Then remove the "openmaintainer" tag
> from all other ports. The we wouldn't need to ask each individual
> first-time contributor to please add the "openmaintainer" tag.
>

Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Mojca Miklavec-2
On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:
>
> We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.

This is pretty useless general strategy as a general rule because
every project does the versioning in a different way. If we were to do
it this way, then every single port would need to specify what
precisely is allowed (to which versions it is ok to update).

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Joshua Root-8
I agree with the points in Mojca's first message in the thread.

On 2018-10-15 09:20 , Mojca Miklavec wrote:
> On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:
>>
>> We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.
>
> This is pretty useless general strategy as a general rule because
> every project does the versioning in a different way. If we were to do
> it this way, then every single port would need to specify what
> precisely is allowed (to which versions it is ok to update).

Perhaps we could add a checkbox for "I have verified that this update
does not introduce any API or ABI incompatibilities." I expect
contributors would be unlikely to check that off untruthfully.

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

On 15/10/18 06:41, Joshua Root wrote:

> I agree with the points in Mojca's first message in the thread.
>
> On 2018-10-15 09:20 , Mojca Miklavec wrote:
>> On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:
>>>
>>> We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.
>>
>> This is pretty useless general strategy as a general rule because
>> every project does the versioning in a different way. If we were to do
>> it this way, then every single port would need to specify what
>> precisely is allowed (to which versions it is ok to update).
>
> Perhaps we could add a checkbox for "I have verified that this update
> does not introduce any API or ABI incompatibilities." I expect
> contributors would be unlikely to check that off untruthfully.

I think in practise that is also not possible to always be determined,
nor I think should we make it a requirement of those submitting the PRs
to do it, as all it would become is a barrier to people submitting
contributions and we don't want that.

In my opinion, if the version of the package being installed changes at
all, the 72 hour timeout should apply.

We also I think need a clear set of guidelines of exactly what sort of
changes are allowed to be made without PR review, or sidestepping the 72
hour timeout . e.g.

- Changes that cannot in any way alter the installed port. Like
livecheck fixes, comments or descriptions.

- rev-bumps just to rebuild against some other change.

- Urgent bug fixes for otherwise broken ports.

and so on... Do we have a guide for something like this written done
anywhere ?

Chris

>
> - Josh
>
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Zero King-2
On Mon, Oct 15, 2018 at 09:58:59AM +0100, Chris Jones wrote:

>Hi,
>
>On 15/10/18 06:41, Joshua Root wrote:
>>I agree with the points in Mojca's first message in the thread.
>>
>>On 2018-10-15 09:20 , Mojca Miklavec wrote:
>>>On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:
>>>>
>>>>We could add a rule that should help a bit that openmaintainer only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one, but it would prevent the Python 2.7 to 3.7.
>>>
>>>This is pretty useless general strategy as a general rule because
>>>every project does the versioning in a different way. If we were to do
>>>it this way, then every single port would need to specify what
>>>precisely is allowed (to which versions it is ok to update).
>>
>>Perhaps we could add a checkbox for "I have verified that this update
>>does not introduce any API or ABI incompatibilities." I expect
>>contributors would be unlikely to check that off untruthfully.
>
>I think in practise that is also not possible to always be determined,
>nor I think should we make it a requirement of those submitting the
>PRs to do it, as all it would become is a barrier to people submitting
>contributions and we don't want that.
>
>In my opinion, if the version of the package being installed changes
>at all, the 72 hour timeout should apply.
>
>We also I think need a clear set of guidelines of exactly what sort of
>changes are allowed to be made without PR review, or sidestepping the
>72 hour timeout . e.g.
>
>- Changes that cannot in any way alter the installed port. Like
>livecheck fixes, comments or descriptions.
>
>- rev-bumps just to rebuild against some other change.
>
>- Urgent bug fixes for otherwise broken ports.
>
>and so on... Do we have a guide for something like this written done
>anywhere ?
"7.4.1. Non-Maintainer Port Updates" in our guide.
https://guide.macports.org/#project.update-policies.nonmaintainer

>Chris
>
>>
>>- Josh
>>

--
Zero

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones

>> and so on... Do we have a guide for something like this written done
>> anywhere ?
>
> "7.4.1. Non-Maintainer Port Updates" in our guide.
> https://guide.macports.org/#project.update-policies.nonmaintainer

That is not what I am asking for. Specifically it does not give any
guidance on exactly what constitutes 'major' or 'minor' changes. All it
says is

"If a port's maintainer contains the address
<[hidden email]>, this means that the author allows minor
updates to the port without contacting him first. But permission should
still be sought for major changes."

It leaves the interpretation of major and minor up to the reader, which
for me is the problem here.

We need a clear set of rules as to what this does and does not entail.

Chris
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Perry E. Metzger-2
In reply to this post by Mojca Miklavec-2
On Mon, 15 Oct 2018 00:20:53 +0200 Mojca Miklavec
<[hidden email]> wrote:

> On Mon, 15 Oct 2018 at 00:10, Blair Zajac wrote:
> >
> > We could add a rule that should help a bit that openmaintainer
> > only lets people do minor version bumps, e.g. X.Y to X.(Y+1) and
> > X.Y.Z to X.Y.(Z+1). This doesn’t solve the Lua 5.2 to 5.3 one,
> > but it would prevent the Python 2.7 to 3.7.  
>
> This is pretty useless general strategy as a general rule because
> every project does the versioning in a different way. If we were to
> do it this way, then every single port would need to specify what
> precisely is allowed (to which versions it is ok to update).

Typically I presume that

1. if the person doing the update is skilled (and at this point I
generally know the difference),
2. if they indicate that they've tested the result,
3. if it seems based on history that the listed maintainer is unlikely
to comment then or ever (and I usually guess right),
4. and that if what's being done seems to be a simple version bump

that it is okay to merge a request against an openmaintainer port. I
think I've guessed wrong only a few times in many hundreds of pull
requests.

If these sorts of things aren't okay to merge pretty quickly, then
why do we have an openmaintainer designation at all? I mean, if
there's really no distinction in how you treat an openmaintainer and
a non-openmaintainer port, why have openmaintainer? Why not just have
everything closed maintainer?


Perry
--
Perry E. Metzger [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

> 1. if the person doing the update is skilled (and at this point I
> generally know the difference),
> 2. if they indicate that they've tested the result,
> 3. if it seems based on history that the listed maintainer is unlikely
> to comment then or ever (and I usually guess right),
> 4. and that if what's being done seems to be a simple version bump

One of the issues is that last point. In general its not possible to be
100% sure whether or not a 'simple' version bump is a trivial change or
not, and what the impact of that would be. So either we accept that the
determination of what is or is not trivial is left to the member that is
reviewing the PR, at which point we have to accept that not everyone
will have the same opinion all the time, so sometimes there will be
disagreements (like the PR that started this), or we have some 'very'
clear guidelines to follow, which is what I brought up in my last mail.

> that it is okay to merge a request against an openmaintainer port. I
> think I've guessed wrong only a few times in many hundreds of pull
> requests.

Just for the record I have absolutely no problems with the way you have
been handling things, and am very appreciative of the fact you are
making the effort to review and merge PRs. More members should really
help out with this (myself included). So please do not take the above as
a complaint against what you have been doing. Just a comment that I
think the guidelines we are working under need clarification.

> If these sorts of things aren't okay to merge pretty quickly, then
> why do we have an openmaintainer designation at all? I mean, if
> there's really no distinction in how you treat an openmaintainer and
> a non-openmaintainer port, why have openmaintainer? Why not just have
> everything closed maintainer?

The way I view openmaintainer is ports that are labeled as such can have
(non trivial) PRs applied to them, *once the 72 hour timeout has
expired*, without the explicit consent of the maintainer, as long as
some sort of agreement of other members that the update is reasonable is
reached. But the 72 hour timeout should always be adhered to for
anything that does not classify as 'trivial' (whatever the rules are for
this).

I do agree though, as Mojca has already brought up, that perhaps we
should consider getting rid of the 'openmaintainer' tag and instead
consider everything open by default, unless explicitly flagged as
'closedmaintainer'. This could also be used as an opportunity to review
which ports really need to be closed...

Chris

>
>
> Perry
>
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Michael Dickens-4
In reply to this post by Christopher Jones
I'll second Chris' note of thanks for MP folks keeping the PR queue short. Since MP folks (especially Perry) have started stepping up to this task, I too have been trying harder to do my part.

Now my US$0.02 worth and all IMHO about PR commit timeouts & why. - MLD

-Any- non-urgent fix should go under a 72-hour timeout; urgent fixes should be given 24 hours. "Urgent" means that the port is clearly broken in any sense: fetch, patch, configure, build, destroot, install, activate, runtime -- on the most recent supported OSs (currently: 10.12-10.14). If a port works on recent OSs but is broken on an older OS, e.g., 10.6 or 10.8, then it goes under a 72-hour timeout.

Rationale: I like reviewing changes, even trivial ones, to my ports. I'm often unavailable on weekends (USA Sa/Su), so an issue filed on Saturday I generally won't get to until Monday. 72 hours gives any maintainer(s) a reasonable chance to review, request changes, discuss, decide to merge, and so forth. 24 hours just isn't enough most of the time, given our various work and family lives.

I, too, would like to see a clear set of guidelines, not just the use of "major" or "minor" since those are very subjective.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Leonardo Brondani Schenkel-3
In reply to this post by Mojca Miklavec-2
My two cents:

I'm a committer, and if I'm doing a trivial bump of an openmaintainer
port I'll push it directly. If I'm opening a GitHub PR for an
openmaintainer port this means that for some reason I want the
maintainer's opinion/review before it gets merged.

As a maintainer, I would be annoyed if I was notified of a PR and at the
time I look into it (within the 72-hour period) it was already merged.

My belief is that in general nobody else should merge the PRs besides
the submitter of the PR and/or the maintainer. They can merge at any
time of their choosing in case they want to proceed, and there is no
need to second guess their intentions. A third-party just needs to
intervene on maintainer timeouts or when neither participant is a
committer. And if a third-party always asks the participants for
confirmation before unilaterally merging, there's little room for
misunderstandings.

So I'm with Ryan and Mojca on this one.

// Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <[hidden email]> wrote:
>
> My two cents:
>
> I'm a committer, and if I'm doing a trivial bump of an openmaintainer port I'll push it directly.

Depends entirely on what you consider trivial. If you consider a version update a trivial bump then I disagree. This in my opinion is something that should also be submitted as a PR so the port maintainer always gets a chance to review it. If the port is open maintainer and they do not respond within the 72 hour timeout, it can then be merged without their comment, but not before. For a committer to directly commit an update to a port that isn’t trivial and they do not maintain is in my humble opinion an abuse of the member role. Members should not bypass the PR review stage just because they can.

> If I'm opening a GitHub PR for an openmaintainer port this means that for some reason I want the maintainer's opinion/review before it gets merged.

In my opinion the ‘rules’ for when this happens should not be subjective, as they currently seem to be. There needs to be a clear policy on what is and is not trivial and thus what does and does not require PR review.

> As a maintainer, I would be annoyed if I was notified of a PR and at the time I look into it (within the 72-hour period) it was already merged.

Agreed. I also would expect to be always given the opportunity to review a PR for any non trivial update, and not for another maintainer to just directly commit it by passing the review stage.

> My belief is that in general nobody else should merge the PRs besides the submitter of the PR and/or the maintainer.

Disagree. Any member with commit rights should be able merge PRs. As long as the procedures have been followed, so either the maintainer has oked the changes, or the 72 hour timeout has expired and another reviewer has agreed with the changes, it does not really matter who finally clicks merge.

( Its actually quite common practise in many circles for submitters of a PR to require third party approval, and for someone else to merge it, and for the submitter to simply do it themselves to be discouraged. )

> They can merge at any time of their choosing in case they want to proceed, and there is no need to second guess their intentions.

Only the maintainer of a port should be free to merge before the 72 hour timeout, if they have the rights to do so. If they do not have commit rights, then can signify they have agreed to the changes at which point any member could merge.

Just my views... take it or leave it.

Chris

>
> So I'm with Ryan and Mojca on this one.
>
> // Leonardo.

Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones


> On 15 Oct 2018, at 11:18 pm, Chris Jones <[hidden email]> wrote:
>
> Hi,
>
>> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <[hidden email]> wrote:
>>
>> My two cents:
>>
>> I'm a committer, and if I'm doing a trivial bump of an openmaintainer port I'll push it directly.
>
> Depends entirely on what you consider trivial. If you consider a version update a trivial bump then I disagree. This in my opinion is something that should also be submitted as a PR so the port maintainer always gets a chance to review it. If the port is open maintainer and they do not respond within the 72 hour timeout, it can then be merged without their comment, but not before. For a committer to directly commit an update to a port that isn’t trivial and they do not maintain is in my humble opinion an abuse of the member role. Members should not bypass the PR review stage just because they can.
>
>> If I'm opening a GitHub PR for an openmaintainer port this means that for some reason I want the maintainer's opinion/review before it gets merged.
>
> In my opinion the ‘rules’ for when this happens should not be subjective, as they currently seem to be. There needs to be a clear policy on what is and is not trivial and thus what does and does not require PR review.
>
>> As a maintainer, I would be annoyed if I was notified of a PR and at the time I look into it (within the 72-hour period) it was already merged.
>
> Agreed. I also would expect to be always given the opportunity to review a PR for any non trivial update, and not for another maintainer to just directly commit it by passing the review stage.

Correction.  .... and not for another MEMBER to just directly commit it by passing the review stage.

>
>> My belief is that in general nobody else should merge the PRs besides the submitter of the PR and/or the maintainer.
>
> Disagree. Any member with commit rights should be able merge PRs. As long as the procedures have been followed, so either the maintainer has oked the changes, or the 72 hour timeout has expired and another reviewer has agreed with the changes, it does not really matter who finally clicks merge.
>
> ( Its actually quite common practise in many circles for submitters of a PR to require third party approval, and for someone else to merge it, and for the submitter to simply do it themselves to be discouraged. )
>
>> They can merge at any time of their choosing in case they want to proceed, and there is no need to second guess their intentions.
>
> Only the maintainer of a port should be free to merge before the 72 hour timeout, if they have the rights to do so. If they do not have commit rights, then can signify they have agreed to the changes at which point any member could merge.
>
> Just my views... take it or leave it.
>
> Chris
>
>>
>> So I'm with Ryan and Mojca on this one.
>>
>> // Leonardo.
>

Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Zero King-2
In reply to this post by Christopher Jones
On Mon, Oct 15, 2018 at 02:16:48PM +0100, Chris Jones wrote:

>Hi,
>
>[...]
>
>>If these sorts of things aren't okay to merge pretty quickly, then
>>why do we have an openmaintainer designation at all? I mean, if
>>there's really no distinction in how you treat an openmaintainer and
>>a non-openmaintainer port, why have openmaintainer? Why not just have
>>everything closed maintainer?
>
>The way I view openmaintainer is ports that are labeled as such can
>have (non trivial) PRs applied to them, *once the 72 hour timeout has
>expired*, without the explicit consent of the maintainer, as long as
>some sort of agreement of other members that the update is reasonable
>is reached. But the 72 hour timeout should always be adhered to for
>anything that does not classify as 'trivial' (whatever the rules are
>for this).
"If a port's maintainer contains the address
<[hidden email]>, this means that the author allows minor
updates to the port without contacting him first. But permission should
still be sought for major changes."

According to our guide, 'minor' updates to the openmaintainer port
doesn't need to wait for the 72-hour timeout, it's not even required to
notify the maintainer.

"A critical port is broken that affects many users."

We often do revbumps without contacting the maintainer if a dependency
update causes breakage.

My two cents:

We also need to clarify what changes can be committed immediately
without maintainer review (even if not openmaintainer), e.g. security
fixes that doesn't break the port or its dependents. I would consider
fixing broken ports, addressing security issues and certain trivial
changes (e.g. fixing typos in comments and broken livecheck, updating
redirected or dead URLs and revbump broken ports) for this category.

>I do agree though, as Mojca has already brought up, that perhaps we
>should consider getting rid of the 'openmaintainer' tag and instead
>consider everything open by default, unless explicitly flagged as
>'closedmaintainer'. This could also be used as an opportunity to
>review which ports really need to be closed...
>
>Chris
>
>>
>>
>>Perry
>>
--
Zero

smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Leonardo Brondani Schenkel-3
In reply to this post by Christopher Jones
> On 15 Oct 2018, at 11:18 pm, Chris Jones <jonesc at hep.phy.cam.ac.uk> wrote:
>
>> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <lbschenkel at macports.org> wrote:
>> I'm a committer, and if I'm doing a trivial bump of an openmaintainer port I'll push it directly.
>
> Depends entirely on what you consider trivial. If you consider a version update a trivial bump then I disagree. This in my opinion is something that should also be submitted as a PR so the port maintainer always gets a chance to review it. If the port is open maintainer and they do not respond within the 72 hour timeout, it can then be merged without their comment, but not before. For a committer to directly commit an update to a port that isn’t trivial and they do not maintain is in my humble opinion an abuse of the member role. Members should not bypass the PR review stage just because they can.

Like it or not, that's the definition of 'openmaintainer': for simple
version bumps, no maintainer approval is necessary. Since the maintainer
is the one explicitly opting in to such policy, I don't see any issue
with respecting their wish. I deliberately added 'openmaintainer' to all
the ports I maintain so others are free to do version bumps without
going through me first, reducing friction (but not other changes, see
below).

Ports that tend to break on any minor version bump, or are problematic
in other ways, should probably not be marked as 'openmaintainer' -- and
I believe they aren't.

>
>> If I'm opening a GitHub PR for an openmaintainer port this means that for some reason I want the maintainer's opinion/review before it gets merged.
>
> In my opinion the ‘rules’ for when this happens should not be subjective, as they currently seem to be. There needs to be a clear policy on what is and is not trivial and thus what does and does not require PR review.

I agree that it looks like different people have different
interpretations for the scope of 'openmaintainer' (apart from simple
version bumps being allowed, which is the definition that is explicitly
written in the documentation).

My own interpretation is that any change that is not a simple version
bump, a simple revision bump due to a dependency being upgraded, or
fixing a livecheck or a typo, do not fall within the scope of
'openmaintainer' and should be cleared with the maintainer first.

>> My belief is that in general nobody else should merge the PRs besides the submitter of the PR and/or the maintainer.
>
> Disagree. Any member with commit rights should be able merge PRs. As long as the procedures have been followed, so either the maintainer has oked the changes, or the 72 hour timeout has expired and another reviewer has agreed with the changes, it does not really matter who finally clicks merge.

Naturally any member can merge PRs by virtue of having the rights to do
so, but my point was that when a PR is opened against a maintained port,
the recipient for that PR is the maintainer although it can be
additionally reviewed/commented by anybody else (I suspect most PRs
don't). Barring maintainer timeouts and other special circumstances,
it's the maintainer that ultimately decides if that PR should be merged.
At that point, they can signal it by approving the PR -- and depending
on who has commit rights they can merge it themselves, or ask the
submitter to merge, or ask any non-participant member to merge.

> ( Its actually quite common practise in many circles for submitters of a PR to require third party approval, and for someone else to merge it, and for the submitter to simply do it themselves to be discouraged. )

In the scenarios I have in mind and I participated in, the submitter
merges if they're asked to by the maintainer or when the PR is approved
without requests for changes or other concerns. Sometimes I submit PRs
to other ports maintained by non-members, and I'm the one who has commit
rights.

>
>> They can merge at any time of their choosing in case they want to proceed, and there is no need to second guess their intentions.
>
> Only the maintainer of a port should be free to merge before the 72 hour timeout, if they have the rights to do so. If they do not have commit rights, then can signify they have agreed to the changes at which point any member could merge.

I think I wasn't clear on that point. What I meant is that a PR is
either on a 'waiting for review/reviewing' phase, or an 'approved/ready
to be merged' phase, and once the PR is 'approved' then anybody can
merge. If it's on the 'review' phase, it's up to the participants to
transition that PR into 'approved' and merge (or ask for it to be
merged). I see very little room here for a non-participant third-party
to second guess a participant's intention and prematurely merge a PR --
and if this seems to be warranted, simply asking first will eliminate
the vast majority of misunderstandings.

// Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

On 16/10/18 07:37, Leonardo Brondani Schenkel wrote:

>> On 15 Oct 2018, at 11:18 pm, Chris Jones <jonesc at hep.phy.cam.ac.uk>
>> wrote:
>>
>>> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <lbschenkel
>>> at macports.org> wrote:
>>> I'm a committer, and if I'm doing a trivial bump of an openmaintainer
>>> port I'll push it directly.
>>
>> Depends entirely on what you consider trivial. If you consider a
>> version update a trivial bump then I disagree. This in my opinion is
>> something that should also be submitted as a PR so the port maintainer
>> always gets a chance to review it. If the port is open maintainer and
>> they do not respond within the 72 hour timeout, it can then be merged
>> without their comment, but not before. For a committer to directly
>> commit an update to a port that isn’t trivial and they do not maintain
>> is in my humble opinion an abuse of the member role. Members should
>> not bypass the PR review stage just because they can.
>
> Like it or not, that's the definition of 'openmaintainer': for simple
> version bumps, no maintainer approval is necessary.

Please point me to where this is documented ? i.e. where is it stated
that openmaintainer allows revision changes. This appears to be one of
the issues here since not everyone, myself included, agrees with you.
The only statement I have found is

"If a port's maintainer contains the address
<[hidden email]>, this means that the author allows minor
updates to the port without contacting him first. But permission should
still be sought for major changes."

which does not mention this point. It leaves the interpretation of minor
and major to the reader.

Chris

  Since the maintainer

> is the one explicitly opting in to such policy, I don't see any issue
> with respecting their wish. I deliberately added 'openmaintainer' to all
> the ports I maintain so others are free to do version bumps without
> going through me first, reducing friction (but not other changes, see
> below) >
> Ports that tend to break on any minor version bump, or are problematic
> in other ways, should probably not be marked as 'openmaintainer' -- and
> I believe they aren't.
>
>>
>>> If I'm opening a GitHub PR for an openmaintainer port this means that
>>> for some reason I want the maintainer's opinion/review before it gets
>>> merged.
>>
>> In my opinion the ‘rules’ for when this happens should not be
>> subjective, as they currently seem to be. There needs to be a clear
>> policy on what is and is not trivial and thus what does and does not
>> require PR review.
>
> I agree that it looks like different people have different
> interpretations for the scope of 'openmaintainer' (apart from simple
> version bumps being allowed, which is the definition that is explicitly
> written in the documentation).
>
> My own interpretation is that any change that is not a simple version
> bump, a simple revision bump due to a dependency being upgraded, or
> fixing a livecheck or a typo, do not fall within the scope of
> 'openmaintainer' and should be cleared with the maintainer first.
>
>>> My belief is that in general nobody else should merge the PRs besides
>>> the submitter of the PR and/or the maintainer.
>>
>> Disagree. Any member with commit rights should be able merge PRs. As
>> long as the procedures have been followed, so either the maintainer
>> has oked the changes, or the 72 hour timeout has expired and another
>> reviewer has agreed with the changes, it does not really matter who
>> finally clicks merge.
>
> Naturally any member can merge PRs by virtue of having the rights to do
> so, but my point was that when a PR is opened against a maintained port,
> the recipient for that PR is the maintainer although it can be
> additionally reviewed/commented by anybody else (I suspect most PRs
> don't). Barring maintainer timeouts and other special circumstances,
> it's the maintainer that ultimately decides if that PR should be merged.
> At that point, they can signal it by approving the PR -- and depending
> on who has commit rights they can merge it themselves, or ask the
> submitter to merge, or ask any non-participant member to merge.
>
>> ( Its actually quite common practise in many circles for submitters of
>> a PR to require third party approval, and for someone else to merge
>> it, and for the submitter to simply do it themselves to be discouraged. )
>
> In the scenarios I have in mind and I participated in, the submitter
> merges if they're asked to by the maintainer or when the PR is approved
> without requests for changes or other concerns. Sometimes I submit PRs
> to other ports maintained by non-members, and I'm the one who has commit
> rights.
>
>>
>>> They can merge at any time of their choosing in case they want to
>>> proceed, and there is no need to second guess their intentions.
>>
>> Only the maintainer of a port should be free to merge before the 72
>> hour timeout, if they have the rights to do so. If they do not have
>> commit rights, then can signify they have agreed to the changes at
>> which point any member could merge.
>
> I think I wasn't clear on that point. What I meant is that a PR is
> either on a 'waiting for review/reviewing' phase, or an 'approved/ready
> to be merged' phase, and once the PR is 'approved' then anybody can
> merge. If it's on the 'review' phase, it's up to the participants to
> transition that PR into 'approved' and merge (or ask for it to be
> merged). I see very little room here for a non-participant third-party
> to second guess a participant's intention and prematurely merge a PR --
> and if this seems to be warranted, simply asking first will eliminate
> the vast majority of misunderstandings.
>
> // Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Leonardo Brondani Schenkel-3
> Please point me to where this is documented ? i.e. where is it stated
> that openmaintainer allows revision changes. This appears to be one of
> the issues here since not everyone, myself included, agrees with you.
> The only statement I have found is
>
> "If a port's maintainer contains the address
> <openmaintainer at macports.org>, this means that the author allows minor
> updates to the port without contacting him first. But permission should
> still be sought for major changes."
>
> which does not mention this point. It leaves the interpretation of minor
> and major to the reader.

Based on your response I had to go to the website and check. To my
surprise you're right, I must have imagined or misread the rule and
somehow this definition got stuck on my mind.

To my defense, "minor updates to the port" could be interpreted as
either updates to the Portfile or to the software itself, but I must
concede that the second interpretation is not clear-cut. Mea culpa for
the misleading statement regarding the documentation.

But back to the topic at hand, 'openmaintainer' is somewhat of a
digression: if the port is not, then PRs have to wait for the
maintainer. If the port is, and a PR was opened by a member/committer,
then it must follow that the submitter understands that the change does
not fall within the definition (otherwise they would have pushed
directly) and wants to submit it to the maintainer. In either of these
scenarios, a premature merge seems not to be warranted. Doesn't that
make sense?

// Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

On 16/10/18 13:37, Leonardo Brondani Schenkel wrote:

>> Please point me to where this is documented ? i.e. where is it stated
>> that openmaintainer allows revision changes. This appears to be one of
>> the issues here since not everyone, myself included, agrees with you.
>> The only statement I have found is
>>
>> "If a port's maintainer contains the address <openmaintainer at
>> macports.org>, this means that the author allows minor updates to the
>> port without contacting him first. But permission should still be
>> sought for major changes."
>>
>> which does not mention this point. It leaves the interpretation of
>> minor and major to the reader.
>
> Based on your response I had to go to the website and check. To my
> surprise you're right, I must have imagined or misread the rule and
> somehow this definition got stuck on my mind.
>
> To my defense, "minor updates to the port" could be interpreted as
> either updates to the Portfile or to the software itself, but I must
> concede that the second interpretation is not clear-cut. Mea culpa for
> the misleading statement regarding the documentation.

Let me be clear, I was not blaming you for having the view you do, so no
need to apologize. The point I was making is simply we don't have a
clear policy on what is and is nor minor, it is left to the
interpretation of the reader as to what that means, which ultimately
means confusion on the point.

>
> But back to the topic at hand, 'openmaintainer' is somewhat of a
> digression: if the port is not, then PRs have to wait for the
> maintainer. If the port is, and a PR was opened by a member/committer,
> then it must follow that the submitter understands that the change does
> not fall within the definition (otherwise they would have pushed
> directly) and wants to submit it to the maintainer. In either of these
> scenarios, a premature merge seems not to be warranted. Doesn't that
> make sense?

openmaintainer is not a digression in a sense it is tied to what actions
can be made by members.

- If a port is open maintainer then it is allowed for 'minor' changes to
be directly committed by members, whilst 'majors' ones require an
attempt to give the maintainer a chance to comment (which to me means a
github PR must be opened for that change). The maintainer then has 72
hours to comment, at which point, under the agreement of those
commenting on the PR (I would say at least one more person than the
submitter) it can be merged. The question of what is 'minor' requires
clarification so we all know what it means... Critical security fixes
can also be directly merged. Also note that if a third party (non
member) submits a PR than is determined to be 'minor', then a member
should be free to merge that PR before the 72 hour timeout, as its
equivalent to allowing the member to directly commit the changes themselves.

- If a port is not open maintainer then only 'trivial' (e.g. live check
fixes, comment typos etc.), or urgent security related changes can be
made directly. Again here I would suggest we need a precise written down
definition of what this means, just to avoid ambiguities. Everything
else must go via a PR. If the maintainer fails to respond in some
reasonable time (what is this ? presumably longer than 72 hours) the
presumably some other mechanism kicks in, like port abandonment, to
eventually allow the PR to be merged.

Chris

>
> // Leonardo.
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Rainer Müller-4
In reply to this post by Christopher Jones
On 2018-10-16 10:06, Chris Jones wrote:

> On 16/10/18 07:37, Leonardo Brondani Schenkel wrote:
>>> On 15 Oct 2018, at 11:18 pm, Chris Jones <jonesc at
>>> hep.phy.cam.ac.uk> wrote:
>>>
>>>> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <lbschenkel
>>>> at macports.org> wrote:
>>>> I'm a committer, and if I'm doing a trivial bump of an
>>>> openmaintainer port I'll push it directly.
>>>
>>> Depends entirely on what you consider trivial. If you consider a
>>> version update a trivial bump then I disagree. This in my opinion is
>>> something that should also be submitted as a PR so the port
>>> maintainer always gets a chance to review it. If the port is open
>>> maintainer and they do not respond within the 72 hour timeout, it can
>>> then be merged without their comment, but not before. For a committer
>>> to directly commit an update to a port that isn’t trivial and they do
>>> not maintain is in my humble opinion an abuse of the member role.
>>> Members should not bypass the PR review stage just because they can.

What you describe would be the process without openmaintainer. With
openmaintainer, "minor updates" can be pushed directly by other project
members.

I would always assume that a project member was looking for explicit
maintainer approval when submitting a change to an openmaintainer port
as a pull request. Otherwise they could just have pushed it directly.
Therefore I would recommend not to merge them unless approved by the
port's maintainer.

>> Like it or not, that's the definition of 'openmaintainer': for simple
>> version bumps, no maintainer approval is necessary.
>
> Please point me to where this is documented ? i.e. where is it stated
> that openmaintainer allows revision changes. This appears to be one of
> the issues here since not everyone, myself included, agrees with you.
> The only statement I have found is
>
> "If a port's maintainer contains the address
> <[hidden email]>, this means that the author allows minor
> updates to the port without contacting him first. But permission should
> still be sought for major changes."

For the record, this is from the maintainer update policy in the guide:
https://guide.macports.org/#project.update-policies.nonmaintainer

> which does not mention this point. It leaves the interpretation of minor
> and major to the reader.

I always assumed that "minor update" means increasing version/revision
of a port. If you did not want that allowed, what else would
openmaintainer cover?

The problem has always been that the definition of what is considered a
minor or a major change largely depends on the software we are
packaging. It is hard to find a more specific rule that still applies
universally to all ports.

In general, if you as a maintainer do not want others to make updates,
you should not add the openmaintainer policy.

Rainer
Reply | Threaded
Open this post in threaded view
|

Re: Merging pull requests before 72 hours

Christopher Jones
Hi,

> On 17 Oct 2018, at 1:17 am, Rainer Müller <[hidden email]> wrote:
>
> On 2018-10-16 10:06, Chris Jones wrote:
>> On 16/10/18 07:37, Leonardo Brondani Schenkel wrote:
>>>> On 15 Oct 2018, at 11:18 pm, Chris Jones <jonesc at
>>>> hep.phy.cam.ac.uk> wrote:
>>>>
>>>>> On 15 Oct 2018, at 10:34 pm, Leonardo Brondani Schenkel <lbschenkel
>>>>> at macports.org> wrote:
>>>>> I'm a committer, and if I'm doing a trivial bump of an
>>>>> openmaintainer port I'll push it directly.
>>>>
>>>> Depends entirely on what you consider trivial. If you consider a
>>>> version update a trivial bump then I disagree. This in my opinion is
>>>> something that should also be submitted as a PR so the port
>>>> maintainer always gets a chance to review it. If the port is open
>>>> maintainer and they do not respond within the 72 hour timeout, it can
>>>> then be merged without their comment, but not before. For a committer
>>>> to directly commit an update to a port that isn’t trivial and they do
>>>> not maintain is in my humble opinion an abuse of the member role.
>>>> Members should not bypass the PR review stage just because they can.
>
> What you describe would be the process without openmaintainer. With
> openmaintainer, "minor updates" can be pushed directly by other project
> members.
>
> I would always assume that a project member was looking for explicit
> maintainer approval when submitting a change to an openmaintainer port
> as a pull request. Otherwise they could just have pushed it directly.
> Therefore I would recommend not to merge them unless approved by the
> port's maintainer.
What then about non-member git PRs, should they wait the 72 hours before merging or not ? Non-members have no othert option other than submit a PR (or a ticket).
If a member reviews one of these with the 72 hours and deems it ‘minor’, surely to be consistent with the
fact they could have just committed that change directly themselves, they should be free to merge it immediately ?

Allowing members to directly commit ‘minor’ changes directly but then complaining when ‘minor’ PRs get merged quickly to me is inconsistent.

>
>>> Like it or not, that's the definition of 'openmaintainer': for simple
>>> version bumps, no maintainer approval is necessary.
>>
>> Please point me to where this is documented ? i.e. where is it stated
>> that openmaintainer allows revision changes. This appears to be one of
>> the issues here since not everyone, myself included, agrees with you.
>> The only statement I have found is
>>
>> "If a port's maintainer contains the address
>> <[hidden email]>, this means that the author allows minor
>> updates to the port without contacting him first. But permission should
>> still be sought for major changes."
>
> For the record, this is from the maintainer update policy in the guide:
> https://guide.macports.org/#project.update-policies.nonmaintainer
>
>> which does not mention this point. It leaves the interpretation of minor
>> and major to the reader.
>
> I always assumed that "minor update" means increasing version/revision
> of a port. If you did not want that allowed, what else would
> openmaintainer cover?
This is the problem. What is written is not explicit and open to interpretation. I, for instance, have always felt version updates generally are not minor updates.
>
> The problem has always been that the definition of what is considered a
> minor or a major change largely depends on the software we are
> packaging. It is hard to find a more specific rule that still applies
> universally to all ports.

That is understood. Either we allow ‘minor’ version updates directly, and accept that there will always be disagreements on what this means exactly, and sometimes a ‘minor’ update will be made that turns out not to be so minor, or we don’t allow any version updates under the ‘minor’ tag, and accept the additional work as members that *every* update has to then go via a PR. The guide also could perhaps be improved to be a bit more explicitly on what minor means. For instance, if we agree that includes minor version updates, then that should be stated.

Chris

>
> In general, if you as a maintainer do not want others to make updates,
> you should not add the openmaintainer policy.
>
> Rainer


smime.p7s (2K) Download Attachment
12