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

[John Marino]

On 12/2/2013 14:12, Philippe Audéoud wrote:
> On Mon, 02 Dec 2013, John Marino wrote:
> 
>> On 12/2/2013 11:43, Philippe Audéoud wrote:
>>> I don't do a big deal but I like the idea to respect others job. If i
>>> was known to not update my ports when needed, I can understand that
>>> someone is doing my job.
>>
>> Well, actually you did make a big deal about it, but let's talk about
>> the other thing.
>>
> 
> Excuse me to tell my opinion! I just asked for an explanation and I didn't
> reproach anything. But ok, if you want I'm making a big deal with it.


Yes, that's my definition of a big deal.  The port was deleted as
desired and on-time.  The correct thing happened, but Rene was
challenged as if he did something wrong.  Hundreds of ports have been
deleted in the last few months and this is the first challenge I've seen.


>>> When i take the maintainership of a port, I interpret it as "I'm taking
>>> care of this port and thanks to let me know if you want to do something
>>> with".
>>> If I follow your idea, ok, let's commit on all maintainer's port without
>>> approval. Then, the idea of maintainer is useless.
>>
>> Let me be clear:  If the change is a patch to make it work better, or
>> improve the functionality, address options, or basically any change to
>> what the maintainer *intended* then of course it needs the permission of
>> the maintainer.
>>
>> However, if it's a missing dependency, or a typographical error, or
>> something really REALLY obviously and it's *broken* because of it, then
>> no, I don't think those cases should require writing a PR and
>> potentially waiting 2 weeks for it to time out.  The number of
>> non-responsive maintainers vastly outnumbers those that respond quickly
>> and that includes those with @freebsd.org addresses.
> 
> Agree but it's not our case. It's not a big issue neither a broken
> change.


Right, it's even more trivial.


> 
>>> So, again, i don't do a big deal but as an active maintainer, I don't
>>> like someone else is doing my job whitout asking.
>>
>> Port deletion isn't necessarily "your job".  The vast majority of ports
>> are deleted by someone other than the maintainer.
>>
> 
> Deleting a port *I maintain* is my job as to mark it deprecated.


I have never seen it documented that port deletion is solely the
responsibility of the (previous) port maintainer.  Can you point to
where this is documented?  I'd even argue that after the expiration
date, the port is unmaintained by definition.


> 
>> I really hope portmgr@ starts addressing cases where other maintainers
>> can help with obvious breakage.  Obviously it needs to be written and
>> defined clearly so that we have something to point to when the listed
>> maintainer gets touchy about it (which they should not be).
>>
>> Now, I will say that if one dares to touch a port maintained by another,
>> the change he or she makes had better be correct!  Making the wrong
>> change to someone else's port is justification for them getting upset.
> 
> Then, you can send a PR and wait for a time-out.
> 
> Now, to close this debate: I don't care that rene@ deleted this port, I
> just think that we (as committer) don't have full right on all ports.
> You want a change (minor or major) for a port that you don't maintain and
> not in ports@, you have to send a pr except for changes describe in
> committer guide. Or maybe you can send an email, communication doesn't
> cost but it's good to use it.

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.

> Ok, now, can we please stop this debate and work on freebsd?

I'm not stopping you, but this is a perfect example of somebody way too
protective of their own ports which is to the detriment of the project
as a whole (that's my opinion of course, but I know that opinion is
shared by others.)  The point is that the current policy favors *your*
position, I think that's bad as this policy causes a lot on
unnecessarily bureaucracy and hurts users with longer-than-needed
downtime and I think it needs to be revised.  Also assume that there are
cases where a port would have been fixed on the spot, but the hoop
jumping of writing a PR and waiting too weeks is too substantial and
results in that person not fixing the port at all.  Nobody wins.