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

[Philippe Audéoud]

On Mon, 02 Dec 2013, John Marino wrote:

> On 12/2/2013 14:49, Philippe Audéoud wrote:
> > 
> > Ok, just calm down, every thing gonne be all right... I didn't challenge
> > him, but I won't debate anymore, you don't look to be opened to a
> > debate.
> > 
> > My personal think is : I was on week-end and i don't use computer on
> > week-end. I guess this delete commit could wait 2 days.
> 
> 
> Why should it?  It was the date you defined.
> Rene is right to assume that the port maintainer isn't intending to
> delete the port in a timely fashion because it almost never happens.
> Your desire to delete the port yourself on the expiration date is
> exceptional.
> 
> 
> >>
> >> This is the situation today.  My position is that this is a bad policy.
> >>  I say we should not have to wait 2 weeks to unbreak a port and your
> >> response is "wait up to 2 weeks to unbreak a port".  Perhaps I
> >> misunderstood you, but that's what I understood.
> >>
> > 
> > And, if rules are not good, i break them? I disagree with highway code,
> > and i should break it only because i'm not aware?
> 
> 
> 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

-- 
Philippe Audéoud