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

Hi,

On Wed, Aug 1, 2012 at 2:18 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
> On 8/1/12, Arnaud Lacombe <lacombar_at_gmail.com> wrote:
>> Hi,
>>
>> On Wed, Aug 1, 2012 at 12:40 PM, Attilio Rao <attilio_at_freebsd.org> wrote:
>>> On Wed, Aug 1, 2012 at 5:32 PM, Arnaud Lacombe <lacombar_at_gmail.com>
>>> wrote:
>>>> Hi,
>>>>
>>>> On Tue, Jul 31, 2012 at 4:14 PM, Attilio Rao <attilio_at_freebsd.org>
>>>> wrote:
>>>>>
>>>>> You don't want to work cooperatively.
>>>>>
>>>> Why is it that mbuf's refactoring consultation is being held in
>>>> internal, private, committers-and-invite-only-restricted meeting at
>>>> BSDCan ?
>>>>
>>>> Why is it that so much review and discussion on changes are held
>>>> privately ?
>>>
>>> Arnaud,
>>> belive me, to date I don't recall a single major technical decision
>>> that has been settled exclusively in private (not subjected to peer
>>> review) and in particular in person (e-mail help you focus on a lot of
>>> different details that you may not have under control when talking to
>>> people, etc).
>>>
>> Whose call is it to declare something worth public discussion ? No one.
>>
>> Every time I see a "Suggested by:", "Submitted by:", "Reported by:",
>> and especially "Approved by:", there should to be a public reference
>> of the mentioned communication.
>
> Not necessarilly. Every developer must ensure to produce a quality
> work, with definition of "quality" being discretional. Some people
> fail this expectation, while others do very good. As a general rule,
> some people send patches to experts on the matter and they just trust
> their judgment, others also full-fill testing cycles by thirdy part
> people, others again ask for public reviews. Often this process is
> adapted based on the dimension of the work and the number of
> architectural changes it introduces.
>
> As a personal matter, for a big architectural change things I would
> *personally* do are:
> - Prepare a master-plan with experts of the matter
> - Post a plan (after having achived consensus) on the public mailing
> list for further discussions
> - Adjust the plan based on public feedbacks (if necessary)
> - Implement the plan
> - Ask the experts if they have objections to the implementation
> - Ask testers to perform some stress-testing
> - Ask testers to perform benchmark (if I find people interested in that)
> - Send out to the public mailing list for public review
> - Integrate suggestions
> - Ask testers to stress-test again
> - Commit
>
> I think this model in general works fairly well,
>
I agree.

> but people may have
> different ideas on that, meaning that people may want to not involve
> thirdy part for testing or review. This is going to be risky and lower
> the quality of their work but it is their call.
>
>>> Sometimes it is useful that a limited number of developers is involved
>>> in initial brainstorming of some works,
>>>
>> Never.
>>
>>> but after this period
>>> constructive people usually ask for peer review publishing their plans
>>> on the mailing lists or other media.
>>>
>> Again, never. By doing so, you merely put the community in a situation
>> where, well, "We, committers, have come with this, you can either
>> accept or STFU, but no major changes will be made because we decided
>> so."
>
> 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* ?

>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.

>> The callout-ng conference at BSDCan was just beautiful, it was basically:
>>
>> Speaker: "we will do this"
>> Audience: "how about this situation ? What you will do will not work."
>> Speaker: "thank you for listening, end of the conference"
>>
>> It was beautiful to witness.
>
> Not sure if you realized but I was what you mention "Audience". I
> think you are referring to a specific case where a quick heads-up on a
> summer of code project has been presented, you cannot really believe
> all the technical discussion around FreeBSD evolve this way.
>
indeed, but that was still the case back then.

>>> If you don't see any public further discussion this may be meaning:
>>> a) the BSDCan meetings have been fruitless and there is no precise
>>> plan/roadmap/etc.
>>>
>> so not only you make it private, but it shamelessly failed...
>
> 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.

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.

>>> 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.

 - Arnaud