Allowing more non-maintainer updates

[Bryan Blackburn]

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>

> 
> * Required port variable missing (e.g. platforms or long_description)

If required, I'd technically call that broken.

> * Syntax error

If it causes something like PortIndex to fail, again, broken.

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

> * Hardcoded /opt/local

Again, broken.

> * Forgot to bump revision or epoch after change that requires it

I'd call that broken as well.

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

> * Build fix for pre-release Mac OS X version

Broken, just for that platform, so anything outside making that work would
be off limits.

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

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

> 
> 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'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 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?

Bryan