svn commit: r335281 - in head: . audio audio/gnump3d

[Philippe Audéoud]

On Mon, 02 Dec 2013, John Marino wrote:

> On 12/2/2013 15:52, Philippe Audéoud wrote:
> > On Mon, 02 Dec 2013, John Marino wrote:
> >>
> >> You are misrepresenting me.  I follow the rules, but they are crappy
> >> rules so I'm complaining about them.  Rene did not break any rules that
> >> I am aware of.  (You conveniently did not show me where this "rule" is
> >> documented, nor why you think port maintenance privilege extends past
> >> the expire deadline).
> 
> > 
> > 4. Respect existing maintainers if listed.
> > 
> > Many parts of FreeBSD are not "owned" in the sense that any specific
> > individual will jump up and yell if you commit a change to "their" area,
> > but it still pays to check first. One convention we use is to put a
> > maintainer line in the Makefile for any package or subtree which is
> > being actively maintained by one or more people; see
> > http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/developers-handbook/policies.html
> > for documentation on this. Where sections of code have several
> > maintainers, commits to affected areas by one maintainer need to be
> > reviewed by at least one other maintainer. In cases where the
> > "maintainer-ship" of something is not clear, you can also look at the
> > repository logs for the file(s) in question and see if someone has been
> > working recently or predominantly in that area.
> > 
> > Other areas of FreeBSD fall under the control of someone who manages an
> > overall category of FreeBSD evolution, such as internationalization or
> > networking. See http://www.FreeBSD.org/administration.html for more
> > information on this.
> > 
> > from :
> > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html
> > 
> 
> 
> 1. Clearly it does not address port deletion specifically.
> 2. I openly questioned whether or not the MAINTAINER line expired with
> the port.  I believe it should.  After the expiry date, it should be
> treated as if MAINTAINER=ports at freebsd.org (meaning anybody at all can
> delete it if they feel like it.)
> 3. This is the clause that needs updating.  It gives too much power to
> the listed MAINTAINER.  It could and should allow others to fix the port
> if it restores the port to how the maintainer intended.  People are
> abusing this clause and the result is that ports that could be fixed
> correctly on the spot are not fixed in a timely fashion (sometimes
> delaying weeks or months or perhaps never getting fixed).
> 
> Some of this "power" needs to be clawed back.  I will fully support any
> maintainer who is angry at another committer than "fixes" their port
> incorrectly though.  I think the benefits of allowing others to fix
> ports-with-listed-maintainers outweighs the negatives by a lot.
> 

Sure but it has to be written. We are both complaining about this point,
maybe we can work together and suggest somes rules/reflexion to
portmgr at .

-- 
Philippe Audéoud