Merging pull requests before 72 hours

Chris Jones jonesc at hep.phy.cam.ac.uk
Mon Oct 15 08:58:59 UTC 2018


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
> 


More information about the macports-dev mailing list