[talk] FreeBSD Governance, Foundation/Project

[Edward Capriolo]

On Thursday, June 13, 2019, Edward Capriolo <edlinuxguru at gmail.com> wrote:

>
>
> On Thursday, June 13, 2019, Warner Losh <imp at bsdimp.com> wrote:
>
>>
>>
>> On Wed, Jun 12, 2019 at 9:47 PM Edward Capriolo <edlinuxguru at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 12, 2019 at 6:16 PM Warner Losh <imp at bsdimp.com> wrote:
>>>
>>>>
>>>> On Wed, Jun 12, 2019 at 1:45 PM Isaac (.ike) Levy <
>>>> ike at blackskyresearch.net> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I've just finished listening to a very long video, still digesting it
>>>>> all:
>>>>>
>>>>> "AsiaBSDCon 2019 DevSummit: We don't see a problem. Suggestion of
>>>>> Project Governance additions."
>>>>> https://www.youtube.com/watch?v=g4MetxUV4N0
>>>>>
>>>>> These are the slides from the presentation,
>>>>> https://docs.google.com/presentation/d/1nu9WVp3-QgkDCQCT8eTA
>>>>> lyYLulADyflzCzmZ3-iX-V0/edit#slide=id.g54d9b68929_21_5
>>>>>
>>>>> Attendees in the audience can be identified here:
>>>>> https://wiki.freebsd.org/DevSummit/201903#Short_Talks
>>>>>
>>>>> --
>>>>> Summary: Michael Dexter is presenting on a number of issues and
>>>>> challenges he sees facing the FreeBSD Project, which directly relate to
>>>>> influence from the FreeBSD Foundation.  It's a tough but constructive
>>>>> conversation, whereby MD is raising a number of important issues which I
>>>>> believe are near and dear to many of us around NYC*BUG.
>>>>>
>>>>> For almost every point, MD touches on something which has affected my
>>>>> life around the FreeBSD project, (personally and professionally).  MD tries
>>>>> hard not to posit all the solutions, but instead sparks a really long and
>>>>> valuable discussion among FreeBSD devs, core, and Foundation folks.  The
>>>>> talk isn't directly about code per-se, (but in the end, the issues are
>>>>> deeply technical.)
>>>>>
>>>>> With the stiff opposition in the room, and the patience, directness,
>>>>> and openness MD exhibits in his presentation, I feel he deserves a
>>>>> commendation from the community for raising these issues- and that this
>>>>> presentation should perhaps be required viewing for any new Core/Foundation
>>>>> FreeBSD folks.  Criticism and introspection is always difficult for
>>>>> projects we all care so deeply about, but critical to growth and survival.
>>>>>
>>>>> --
>>>>> For those who have watched this, (or plan to, or were in the rooom),
>>>>> I'd love to openly hear people's thoughts on topics raised?
>>>>>
>>>>> In the years since the FreeBSD Foundation emerged, what have been it's
>>>>> biggest success and failures for the FreEBSD project?  (Aside from the
>>>>> obvious success of paying Glen Barber to stabilize RELENG :)
>>>>>
>>>>> Do other people see value in MD's points, and even better yet, do
>>>>> people have constructive ideas toward remediation for any of these issues?
>>>>> Any constructive/actionable asks of the Project or the Foundation?
>>>>>
>>>>
>>>> It's hard to know what MD's points were as they were shrouded in so
>>>> much passive-agressive toxicity, half-truths and outright lies.
>>>>
>>>> This was a horrible presentation that was painful to sit through
>>>> because he belabored so many points, committed so many logical fallacies
>>>> (FreeBSD core and FreeBSD foundation are two entirely different things,
>>>> despite having the word FreeBSD in them, for example). In addition, a
>>>> number of his points were just wrong (yes, you can impeach core, for
>>>> example). It was poorly researched, poorly organized and poorly presented.
>>>> I had dozens of private messages from other people in the room commenting
>>>> on just how painful it was to sit through in person.
>>>>
>>>> But then again, I'm the guy doing the table flipping on the phone
>>>> because he was telling bald-faced lies about  me and when I tried to
>>>> correct the context, he persisted in those lies.
>>>>
>>>> Warner
>>>> _______________________________________________
>>>> talk mailing list
>>>> talk at lists.nycbug.org
>>>> http://lists.nycbug.org:8080/mailman/listinfo/talk
>>>>
>>>
>>> Just a note: The presentation references this code here:
>>>
>>> https://reviews.freebsd.org/D19016
>>>
>>> Random observation.
>>>
>>> "here's no way that nstr won't be terminated in the first 80 characters
>>> because the snprintf 3 lines above guarantees it. so strnlen() is kinda
>>> useless here."
>>>
>>
>> This I said. It's fair criticism that it's not my most articulate work.
>> However, one uses strnlen when one has a potentially unbounded string.
>> snprintf ensures the strings are bounded, so strnlen was actually useless
>> there. I should have state that more directly.
>>
>>
>>> Why not write a unit test? I think this has a way of engaging people
>>> more, instead of saying "it is cosmetic" or "dont worry i got this". It
>>> says, "I have considered these scenarios. Please  provide some other ones
>>> if you want to discuss a different imp."
>>>
>>
>> I said none of those things. And you are quoting them out of context (the
>> first is a paraphrase of something araujo said, the second wasn't said in
>> the review). In addition, a test case here would just be asking the
>> contributor to do work I knew couldn't possibly be done. Asking for a test
>> case for a change that static analysis says is useless seems counter
>> productive. Providing feedback that a change is incorrect is what the
>> review process is all about.
>>
>> But what does that have to do with project governance? Sure, I can see
>> that it's a criticism of how we try to recruit and retain people, but even
>> then it's a bad example of that. It's as relevant to the stated goals of
>> this talk as this spelling examples. At least the impeachment example was
>> on topic, even if it was so poorly researched as to get corrected
>> immediately after being put up by those in the room. So what action plan
>> came out of the discussion? Or was it just a bitch session designed to
>> stoke anger w/o presenting any actionable suggestions?
>>
>> Warner
>>
>
> Its governance to say. No code without tests. No code without peer review.
> No self merges.
>
> The later 2 things force you to get more buy in.
>
>
> --
> Sorry this was sent from mobile. Will do less grammar and spell check than
> usual.
>

For example in many Asf projects these rules are in place. If a committee
argues  a -1 with a valid reason the feature is blocked.

I'm not exactly sure what the context of this review and process was.
However I think I see:

Code without a solid test plan or tests (I dont understand how to test it).
A comment about the size of a string.

With a different type of governance in place:
Person 1: I am -1 on this change because of large strings will cause it to
fail.
Person 2: I have provided unit test which shows your case is not an issue.
Person 1: You are right. I retract my - 1.
Person 3: I like the fix as well. I will merge to master/feature branch.

I'm not advocating that is how the project should work but or trying to
nitpick this issue but since it was specifically mentioned it is worth
discussing other ways things could have went.


-- 
Sorry this was sent from mobile. Will do less grammar and spell check than
usual.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/talk/attachments/20190613/3c295f79/attachment.html>