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