On Jun 8, 2009, at 14:54, vincent habchi wrote:
thank you for all your advice. I clearly copied the portfile of the
old versions, converted them to my own conventions (e.g. tabs
instead of spaces) and then tested them. They were by no means
meant to be drop-in replacement for the old Portfiles, but just
transitory files for those eager to upgrade by a semi-official way.
Note that for MacPorts we have standardized on spaces instead of
tabs, so a commit to reverse that would not be ideal. Many ports were
written before this policy went into effect, which is why you still
see ports with tabs in the tree, but if anything we should be
changing tabs to spaces, not the other way around.
I'm a bit baffled that saispo is not the maintainer of py26-sip
since I did not alter that line in any way.
:) In the case of py26-sip it was easy to check, since there has only
been one version of the port.
http://trac.macports.org/log/trunk/dports/python/py26-sip
The two additional commits were by me and were just to set svn
properties that were forgotten initially.
I have some new ports ready, but they are based on SVN versions.
Shall I commit them anyway?
If they are your ports, or openmaintainer or nomaintainer ports, then
by all means yes! But do keep in mind the rule of one logical change
per commit. If they are not your ports and are not openmaintainer,
then file a ticket, assign it to the maintainer, and attach your
proposed changes. If the maintainer does not respond within 72 hours
you can commit your changes.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
