<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 13, 2019 at 6:14 AM Edward Capriolo <<a href="mailto:edlinuxguru@gmail.com">edlinuxguru@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br><br>On Thursday, June 13, 2019, Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank">imp@bsdimp.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2019 at 9:47 PM Edward Capriolo <<a href="mailto:edlinuxguru@gmail.com" target="_blank">edlinuxguru@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2019 at 6:16 PM Warner Losh <<a href="mailto:imp@bsdimp.com" target="_blank">imp@bsdimp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 12, 2019 at 1:45 PM Isaac (.ike) Levy <<a href="mailto:ike@blackskyresearch.net" target="_blank">ike@blackskyresearch.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi All,<br>
<br>
I've just finished listening to a very long video, still digesting it all:<br>
<br>
"AsiaBSDCon 2019 DevSummit: We don't see a problem. Suggestion of Project Governance additions."<br>
<a href="https://www.youtube.com/watch?v=g4MetxUV4N0" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=g4MetxUV4N0</a><br>
<br>
These are the slides from the presentation,<br>
<a href="https://docs.google.com/presentation/d/1nu9WVp3-QgkDCQCT8eTAlyYLulADyflzCzmZ3-iX-V0/edit#slide=id.g54d9b68929_21_5" rel="noreferrer" target="_blank">https://docs.google.com/presentation/d/1nu9WVp3-QgkDCQCT8eTAlyYLulADyflzCzmZ3-iX-V0/edit#slide=id.g54d9b68929_21_5</a><br>
<br>
Attendees in the audience can be identified here:<br>
<a href="https://wiki.freebsd.org/DevSummit/201903#Short_Talks" rel="noreferrer" target="_blank">https://wiki.freebsd.org/DevSummit/201903#Short_Talks</a><br>
<br>
--<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
--<br>
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?<br>
<br>
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 :)<br>
<br>
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?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Warner <br></div></div></div>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@lists.nycbug.org" target="_blank">talk@lists.nycbug.org</a><br>
<a href="http://lists.nycbug.org:8080/mailman/listinfo/talk" rel="noreferrer" target="_blank">http://lists.nycbug.org:8080/mailman/listinfo/talk</a><br></blockquote><div><br></div><div>Just a note: The presentation references this code here:<br><br><a href="https://reviews.freebsd.org/D19016" target="_blank">https://reviews.freebsd.org/D19016</a> <br></div><div><br></div><div>Random observation. <br><br>"<span>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."<br></span></div></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span></span></div><div><span>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."</span></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>Warner</div></div></div></blockquote><div><br></div><div>Its governance to say. No code without tests. No code without peer review. No self merges. </div><div><br></div><div>The later 2 things force you to get more buy in. </div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Warner</div></div></div>