[talk] FreeBSD Governance, Foundation/Project

[Warner Losh]

On Thu, Jun 13, 2019 at 6:14 AM 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-QgkDCQCT8eTAlyYLulADyflzCzmZ3-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.
>

The project has a 25-odd year history. When we started, those were not the
norms. They have become more the norm in the project in recent years,
though the no self merges thing is not really possible with our current
tooling. The stress2 tests have been enhanced to catch all kinds of errors
and edge cases in the kernel. The atf and kyua tests have grown in recent
years. Core recently strongly encouraged all non-trivial changes be code
reviewed.  And the review in question was bad code that was rightly
rejected and the reasons given. So if that example was supposed to elicit
this discussion, it ignored a lot of what's been going on in the project to
make these areas better and it poorly articulated the relevance. It was
also a bad example to pick since the code in question was unquestionably
not acceptable. There are much better examples of things that languish in
phabricator. There's some that are good examples of code that's useful, but
not perfect (useful enough to be included if things can't be fixed), like
the bhyve migration code review... Part of the problem is that we as a
project don't have enough reviewers, and we've not been good about getting
people to break changes into smaller bits so that the undisputed parts go
in quickly, reducing the 'chaff' in the reviews to the meat of the issue.
There are other reviews that are so chaotic and scattered that they are
useless. There's one for the boot loader that tries to make things better,
but has so many different issues jumbled together, and at spots has poor
coding techniques to do these by a submitter who doesn't speak english
natively and whose SCM skills are lacking. Its really hard to take that and
do something useful with it, and getting that change broken up, both in the
review and via back channels, has been frustrating. there's dozens of other
reviews that were small, bite sized, that had issues that the submitter
corrected and they landed in the tree. For all its flaws, Phabricator is
light years ahead of doing it in email in a mailing list that's archived,
but where issues aren't tracked.

So sure, that's good advice. The project has a history and change sometimes
is a bit slow, but is happening. And more needs to change. Hopefully the
git working group can solve many of these structural issues when they
convene.

Warner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nycbug.org:8080/pipermail/talk/attachments/20190613/43662d69/attachment-0001.html>