More formal definition of minor changes

Joshua Root jmr at macports.org
Sun Dec 16 05:48:57 PST 2012


On 2012-12-16 20:51 , Andrea D'Amore wrote:
> I hit "send" by error.
> 
> On Sun, Dec 16, 2012 at 10:38 AM, Andrea D'Amore
> <and.damore at macports.org> wrote:
>> We should add a more explicit definition of what a "minor change" is
>> to both the non-maintainer update policy section in the Guide and to
>> the NewCommittersGuide page on wiki.
>>
>> I remember what a minor change is topic has been discussed but I
>> couldn't find it on the mailing list archive, possibly it happened on
>> IRC.
>>
>> The most similar topic I could find is [1]
> but this didn't lead to an actual change to three bullets list.

That discussion is about critical fixes that don't have to wait for
maintainer timeout, not minor changes. But yeah, the guide was never
changed, and should be. I really don't think it's useful to individually
enumerate all the kinds of changes that qualify though.

>>From what I remember a "minor change" is a change that doesn't alter
> the set of installed files.
> This means for example that adding comments, moving around a block of
> code in portfile, editing homepage's value or moving from plain
> portfile to a portgroup to thin the portfile all fall into the
> definition of minor change; whereas adding a xinstall line, or
> updating version don't since the set of installed files is being
> altered.

That's the first time I've heard that.

> I'd like to hear from the list, or PortMgr, if this definition is good
> to be accepted as official.

I don't think it's good. The guide only mentions "minor updates" in
relation to openmaintainer ports, so I assume that's what you're talking
about. To give some examples:

Version update that is highly unlikely to break anything: OK to commit.
Version update that breaks binary or source compatibility: Discuss with
maintainer first.
Updating from a stable release to a development snapshot because some
feature you want is not yet available in stable: Discuss with maintainer
first.

Clear-cut fix for a clear-cut bug: OK to commit.
Bug fix that involves tradeoffs: Discuss with maintainer first.

Typos: OK to fix.
Changing whitespace to your preferred style: Ask first.

- Josh


More information about the macports-dev mailing list