Date: Wed, 25 Jan 2012 03:58:41 -0500 From: Arnaud Lacombe <lacombar@gmail.com> To: Mark Linimon <linimon@lonesome.com> Cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle Message-ID: <CACqU3MWS92tn0zUV=PGRYqjz-2K=6mgSU0M1tM7KnrsFhNaJ_g@mail.gmail.com> In-Reply-To: <20120125072809.GA11115@lonesome.com> References: <CACqU3MXGxRpyT4CDHmzpvzwSPsFi1MHxWa6C9RJiJ1jditWB4Q@mail.gmail.com> <20120125072809.GA11115@lonesome.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Wed, Jan 25, 2012 at 2:28 AM, Mark Linimon <linimon@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. =A0What 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>". =A0That means that either our Perforce repository, or > SVN project/ directory, were used as staging areas. =A0It's possible to > subscribe to these email messages. =A0(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. =A0AFAICT you're only intere= sted > 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=3Dkern/160992 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/156540 ? is this FUD: http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/156799 ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-Septem= ber/027400.html ? is this FUD: http://lists.freebsd.org/pipermail/freebsd-current/2011-Decemb= er/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 peel= s > off all the outer layers. =A0There 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=3Dkern/161553 ... silly.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACqU3MWS92tn0zUV=PGRYqjz-2K=6mgSU0M1tM7KnrsFhNaJ_g>