FreeBSD has serious problems with focus, longevity, and lifecycle

[Arnaud Lacombe]

Hi,

On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon <linimon at lonesome.com> wrote:
>> I might just be also interested to review/comment code, discuss
>> regressions, and architecture, for a change ;-)
>> Unfortunately, such threads rarely ever happen. Most of the time, the
>> only food provided is a really indigestible +5000/-3000 patch, where
>> all the thinking, architectural design and code has been done behind
>> closed door of a limited few committers, research lab or company.
>
> That's odd.  What the src committers usually tell me, when I have my
> bugmeister-advocate hat on, is that they post patches and then no one
> comments until after they check them in, at which time they complain.
> This discourages them from going through this the next time.
>
exactly my point, huge patches are impossible to review.

> You will also note that some of the large commits say "MFp4" or "MF:
> <projectname>".  That means that either our Perforce repository, or
> SVN project/ directory, were used as staging areas.  It's possible to
> subscribe to these email messages.  (Exactly how is left as an exercise
> for the reader; the hour is getting late.)
>
that is indeed a good source for having a look at early-alpha-WIP stuff.

> As for the research lab/company commits, I'm sure you'd complain equally
> if the code that these groups develop in-house and then release when it's
> in some kind of stable state, instead didn't get released at all.
>
I see company contributed code as ad-hoc solution to the company's
problem, not general solution for the whole FreeBSD userbase. To make
a comparison with Linux, it is just as if Google got all the Android
code merged in mainline as-is, without re-working anything. It did not
happen that way. Much of their code had (and still has) to be
re-designed, abstracted, and adapted to fit the general-purpose
mainline.

> But, of course, I'm wasting my time trying to give you reasoned arguments
> about why FreeBSD does one thing or another.  AFAICT you're only interested
> in spreading FUD about what we do, how we do it, and what we say about it
> before, during, and afterwards.

is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/160992 ?
is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156540 ?
is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/156799 ?
is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027400.html
?
is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-December/030076.html
?

answer to all the above: no, this is bugs, regressions, and mis-design
you folks introduced, not me. Don't blame me to point it out.

> You seem to be obsessed by picking over
> semantics and finding shortcomings to be aggreived over.
>
Semantics and proper, independent, API are crucial.

There is tons of ad-hoc code in FreeBSD which should be properly
generalized. The most silly example I can think about is
`time_after()', defined in <net80211/ieee80211_freebsd.h>. This has
_nothing_ to do specifically with IEEE802.11, it's about time
manipulation. Feel free to search the tree, there is tons of
potentially unsafe, open-coded version of this macros. Call it
nit-picking if you want, but when I write code, I want an API to use,
I'm fed up to always have to re-invent the wheel.

Btw, I do not even speak about some functions in the kernel
re-implementing the exact same logic +10 times in a row, one after the
other, within the same function body...

For the story, I've been hacking tonight in Linux... a pure pleasure,
real tough to get to, but really enjoyable.

> Whatever patches or review you've contributed to date, to my mind, are
> like the last tiny little bits of onion that are left over after one peels
> off all the outer layers.  There may be something to it, but the effort
> to get down to that point is so painful that it's not worth it.
>
> tl;dr: your drama outweighs your contributions.
>
I already commented on this. I'm no longer interested in getting my
stuff integrated in FreeBSD. I put it on github, eventually send
patches on MLs, then you do what you want with it, I no longer
particularly care. I know some patches are used around, that's enough.
I did my time fighting committers to fix their not-so-bugfree code and
won those battles, that's enough for me.

 - Arnaud

ps: I have a particular appreciation for this PR, a feature praised by
users, and no committer dares to care:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/161553 ... silly.