Allowing more non-maintainer updates

[Ryan Schmidt]

On Jul 22, 2009, at 16:34, Bryan Blackburn wrote:

> On Wed, Jul 22, 2009 at 03:57:30PM -0500, Ryan Schmidt said:
>> The Non-Maintainer Port Updates section of the guide lists conditions
>> when we may update ports that have a maintainer:
>>
>> http://guide.macports.org/#project.update-policies.nonmaintainer
>>
>> The existing conditions are:
>>
>> * The maintainer does not respond within 72 hours
>> * A port is abandoned by its current maintainer
>> * A critical port is broken that affects many users
>>
>> There are some conditions I would like to add to these:
>
> The NewCommittersGuide page documents such things to some degree:
>
> <http://trac.macports.org/wiki/NewCommittersGuide>

Ok, I had forgotten about NewCommittersGuide. It says you may fix a  
broken port. The Guide only says you may fix a broken port if it is  
"critical" and affects many users. So these documents somewhat  
contradict each other. We need to document committer guidelines in a  
single place, not two.

If we're going to allow fixing any broken port, we need to define  
what constitutes "broken". I also want to allow some changes to ports  
that are not "broken".


>> * Required port variable missing (e.g. platforms or long_description)
>
> If required, I'd technically call that broken.

A port missing the platforms line will still install fine. AFAIK no  
part of MacPorts currently uses it. But lint will complain about it  
and documentation says it must be there and MacPorts base might use  
it in the future so we should be allowed to add it to portfiles  
without consulting the maintainer.

>> * Syntax error
>
> If it causes something like PortIndex to fail, again, broken.

Right, that's what I meant. In addition to syntax errors, I'm  
thinking of an update which didn't test every available variant,  
leaving a problem in one of the variants, for example a patchfile  
that no longer applies.

>> * Spelling or grammar error in comments, descriptions, etc.
>
> That's pretty cosmetic, so definitely not broken, not sure this  
> would really
> be a big deal unless it makes things like 'port search' not find  
> proper
> ports.

Yes, it's cosmetic. But if it's an obvious typo, or if the wording  
doesn't make sense, I think we should be allowed to fix it without  
having to contact the maintainer. What is the likelihood the  
maintainer would reply "No, I want that typo to be there"?

>> * Hardcoded /opt/local
>
> Again, broken.

Yes, of course only for the minority of users running in a  
nonstandard MacPorts prefix.

>> * Forgot to bump revision or epoch after change that requires it
>
> I'd call that broken as well.

The port isn't broken as such, but whatever update was committed  
before won't be propagated to users who already had the port  
installed. So maybe one could say broadly that "the system" is broken.

>> * No $Id$ tag
>> * No svn:keywords or svn:eol-style properties
>
> Hmm, policy failures but the port should be working; I'd say for
> non-committer maintainers, perhaps go ahead and change it...

In fact I have been periodically fixing these issues across all ports  
for years now, not really considering those aspects to be part of the  
portfile, but realizing now that perhaps allowing these changes  
should be codified. Nobody has ever complained to me about making  
these changes, and I would be surprised to hear any complaint about  
it, since it is documented that we require these. I don't see a point  
in filing a ticket to fix these, since I don't see any valid reason  
for a maintainer to refuse such a change.

>> * Build fix for pre-release Mac OS X version
>
> Broken, just for that platform, so anything outside making that  
> work would
> be off limits.

Agreed.

>> * Removing code for very old versions of Mac OS X (I would currently
>> limit this to Jaguar and earlier; once MacPorts 1.8.0 is released,
>> make this Panther and earlier)
>
> To avoid any possible confusion (eg, seeing that there's a platform  
> variant
> for something and thinking that means it will work) this makes  
> sense to
> remove.

And to simplify the port. There's no point having a darwin 6 section  
in a port if MacPorts cannot be installed on darwin 6 anymore.  
Presumably anyone wanting to use MacPorts on darwin 6 today would  
have to get a historical version of MacPorts from that period, and a  
ports tree to match.

>> * Removing code for ports which will be deleted (e.g. removing mysql3
>> variants since I want to remove mysql3 port)
>
> Removal would then cause those ports referencing it to be broken.

Well true... though ideally one would want to remove all references  
to a port first before removing it. Hence the desire to call out this  
case specifically.


>> Thoughts? Additions?
>
> These policies have been listed on the NewCommittersGuide page for  
> ages so
> perhaps they should be moved to the guide?  There hasn't been a  
> huge amount
> of changes to it lately, so it may be safe (after the above updates).

I agree NewCommittersGuide should be merged into the Guide.


>> I'm thinking about whether we should also allow changes which
>> simplify ports, e.g. if a port sets distfiles and worksrcdir but this
>> could be changed to just set distname, or if a port uses "system" to
>> call some utility but the same could be achieved with a Tcl command,
>> or if a port overrides a phase but the same could be accomplished by
>> setting phase variables. But I'm not sure how to word it so as not to
>> be too ambiguous.
>
> I'd call that making the Portfile more efficient, since it  
> technically works
> but could work better.  Some of these would be obvious (system install
> changed to use xinstall, for example) but others may end up being  
> somewhat
> subjective.  Many cases simply tend to be lack of awareness of what  
> all can
> be used in a Portfile, so I'd guess that many would welcome the  
> improvement
> on the port.

I agree it's subjective which is why I'm hesitant. But my motivation  
is as you say, maintainers not being aware of what's possible, and  
doing something a complicated way when it can be done more simply.  
And since maintainers often look at other ports to see how to do  
things, we would want to get unnecessarily complicated code out of  
portfiles so those methods aren't then learned and copied by others.


>> I might also want to allow changes which implement common MacPorts
>> idioms, e.g. defining and using a ${branch} variable.
>
> Or perhaps any of the various bits on the PortfileRecipes wiki page?

That could be a good idea, yes.