Re: On cooperative work [Was: Re: newbus' ivar's limitation..]

On 8/1/12, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
> Hi,
>
> On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao <attilio_at_freebsd.org> wrote:

[ trimm ]

>> You are forgetting one specific detail: you can always review a work
>> *after* it entered the tree. This is something you would never do, but
>> sometimes, when poor quality code is committed there is nothing else
>> you can do than just raise your concern after it is in.
>>
> Unfortunately, not. First, the developer will certainly have moved on
> after the commit, API may have been changed tree-wide, etc. Then, time
> is likely to have passed between the time you figure potential
> regression or bugs, which makes the first point even more problematic.
> Finally, if my point of view is being ignored *before* it goes to the
> tree, do you really expect it will be considered *after* ?

There is one thing you are not considering: committers are as
powerless as non-committers in face of someone stuck on his own buggy
ideas/implementations. Often people are just convinced their idea is
better than your and they won't change their mind, regardeless their
status in the opensource community. And there is nothing more you can
do apart from learning how to deal with such situations. Granted,
there are projects blowing up and people abbandoning successful
opensource community because of this.

> From my external point of view, committers not only have the
> possibility, but *do* commit mess in the tree without non-committers
> could say or do anything, just as well as committers being able to
> arbitrarily close PR even if the original reporter disagree.

You should look at svn-src_at_ more often I suspect. You will see how
many discussions are in there.

>> And so? I think you have a wrong point of view of what is
>> shamelessly... I'm working on the same project since 6 months, i
>> thought I could finish it in 1 but then I understood that in order to
>> get the quality I was hoping I had to do more work... does it qualify
>> as failed, according to your standard?
>>
> not specifically, but at the end of that project of your, I would run
> a post-mortem meeting to see what went correctly and where things got
> out-of-control.

Arnaud, my friend, I have a new for you: this stuff is hard. I see the
brightest people I've ever met stuck for weeks on problems, thinking
about how to fix them in elegant way. Sometimes things get
understimated, sometimes not, this is just part of the game. But an
important thing is accepting critics in costructive way and learn.
This makes things much easier.

> As for the mbuf meeting, all I can find from it online is:
>
> http://lists.freebsd.org/pipermail/freebsd-arch/2012-June/012629.html
>
> which is not worth much... Rather than doing things internally, maybe
> it is time to open up... oh, wait, you will certainly come to the
> community with a design plan, figure out it's not gonna work while
> doing the implementation, change the design plan while implementing,
> go public with a +3k/-2k loc change patch, ask for benediction, go
> ahead and commit it up until someone comes with an obvious design flaw
> which would render the change pretty much useless, but there will be
> man-month of work to fix it, so it's never gonna be done.
>
> One obvious problem in FreeBSD is that committers are prosecutor,
> judge and jury altogether. That's not the first time I point this out.

You are drammatizing. As I already told, please, if you are interested
in this topic, ask for the state of the discussion and ask politely to
be included from now on. Nobody will reject you only because you don't
have a _at_freebsd.org.

>>>> b) there is still not consensus on details
>>>>
>>> Then the discussion should stop, public records are kept for reference
>>> in the future. There is no problem with this.
>>>
>>>> and you can always publically asked on what was decided and what not.
>>>> Just send a mail to interested recipients and CC any FreeBSD mailing
>>>> list.
>>>>
>>> This is not the way "openness" should be about.
>>
>> There is not much more you can do when people don't share details and
>> discussions automatically.
>>
> keep reporting regressions, interface flaws, POLA violations, ABI
> breakages, bugs, etc.

I agree. But with the correct and humble mindset and avoiding
aggressive behaviour.

Attilio


-- 
Peace can only be achieved by understanding - A. Einstein