HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

[Vadim Goncharov]

Hi Robert Watson! 

On Sun, 19 Sep 2010 19:33:14 +0100 (BST); Robert Watson wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon':

>>> The reason is performance for overall network stack, not ideology.
>>
>> For a practical reasons, "it works but slow" is better than "doesn't work at 
>> all (due to absence of code in the src tree)".
>>
>> "Make it work. Make it right. Make it fast. In that order", know this? 
>> Sacrificing "work" for "fast"?.. Hmm, if it is not ideology, then what is 
>> it?..
> Doug has already clarified, but just to follow up with some detail:
[...]
> Towards the end of the project, it was clear that a few components in the 
> stack had attracted no interest from the community, 
                                           ^^^^^^^^^ (1)
> As such, we went through a public deprecation and 
                             ^^^^^^ (2)
> In the end, any significant code base in the kernel requires ownership -- it 
> can continue through many minor changes without an owner, but major retrofits, 
> such as moving to fine-grained locking, need the attention of someone who 
> understands the code, is able to test the code, and has the time to invest in 
                                                          (3) ^^^^^^^^^^^^^^
> the code.  We do a pretty good job at arranging this with a multi-million line 
> code base, all told.

As I clarified in my reply to Doug today, the community (1) is not just
developers, but users also, some of them, relying on FreeBSD in their business,
have the potential to convert money to (3) and thus help the Project (BTW, is
it possible for Foundation to ease this possibility for such users?). Of
course, that is only one variant, there are may be other posiibilities, but all
of them require announce - and (2) was not really public deprecation, in sense
that it was known to a subset of community only. E.g., a programmer living on
STABLE (thus not reading current@) and hacking other open-source - in case of
public announce he could switch from those others to help FreeBSD in a feature
he needs.

BTW, the committers-guide states:

===
11.4 Deprecating Features

When it is necessary to remove functionality from software in the base system
the following guidelines should be followed whenever possible:

1. Mention is made in the manual page and possibly the release notes that the
option, utility, or interface is deprecated. Use of the deprecated feature
generates a warning.

2. The option, utility, or interface is preserved until the next major (point
zero) release.

3. The option, utility, or interface is removed and no longer documented. It is
now obsolete. It is also generally a good idea to note its removal in the
release notes.
===

But I don't see such metions for i4b/isdnd man pages on 6.4.

> this decade-long project was highly successful, and relied on members of the 
> community stepping forward to adapt a very large code base by adding 
> fine-grained locking to each component.  the results have been extremely 
> impressive, allowing our network stack to scale to 8+ cpus (i'm actually 
> testing with 32-thread systems as part of some network stack work i'm doing 
> right now).

The Project is ultimately about the users, right? There are early signs that
some old FreeBSD users get tired from those changes, those removals, lesser
POLA adherence, marketing-not-technical-stuff for time-not-feature-based
releases, not so stable -STABLE as it used to be, and so on, migrating to
other systems. And older users are more valuable to project than newer ones.
May be it's time to revert to some of thet Old Good Things, if decade-long
project is mostly ended, while those signs are still early and not a strong
tendency?.. Given this thread, I've mentioned earlier about 12 messages in
announce@ from 2002 with such public calls for volunteers - there are several
years already without these.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight at mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]