More formal definition of minor changes

[Andrea D'Amore]

On Sun, Dec 16, 2012 at 2:48 PM, Joshua Root <jmr at macports.org> wrote:

> 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.

I too think the enumerate all items is not the right thing to do. The
right thing to do is to have a definition that is clear of what can
and what cannot be committed.

>>>From what I remember a "minor change" is a change that doesn't alter
>> the set of installed files.

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

Could be that this "informal" definition came from the revision bump
rule or that I blurred the two concepts. I definitely remember talking
inchannel about the need to have a formal definition in guide.

> 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.

In the same two-sentences paragraph the guide says "minor updates" as
opposed to "major changes", it's not even coherent but that made me
think that the two terms could be used interchangeably in this
context.

> To give some examples:

I'm more than happy to makes updates easier but what I'd like to see
is a rule, possibly clear and concise, rather than a set of 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.

So if current features or API are not break by the update/change it's
ok to commit the change, even if this is updating the version.
The bugfix with tradeoff would be excluded since probably the tradeoff
means there's a cost in features/API.
The stable-to-development change has to be discussed anyway since it
is something against the rule of thumb of putting stable releases in
ports.

Can we condense this furter?


On a slightly different topic: what about the default openmaintainership?



--
Andrea