FreeBSD has serious problems with focus, longevity, and lifecycle

[John Kozubik]

Friends,

I was disappointed to see that 8.3-RELEASE is now slated to come out in
March of 2012. This will be ~13 months since 8.2-RELEASE and is typical
of a trend towards longer gaps between minor releases.

I also see that undercutting the current release before wide deployment
and maturity is continuing. 7.0 came (barely) after 6.3, which was bad
enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.

Finally, the culture of "that's fixed in CURRENT" or "we built those
changes into (insert next major release)" continues to get worse. It's
difficult to escape the notion that FreeBSD is becoming an operating
system by, and for, FreeBSD developers.


The Problems:


Between JohnCompanies and rsync.net, we have nearly one thousand full
blown FreeBSD systems running on three continents. We've been deploying
these systems since 2001 and since "the rift"[1] have been increasingly
subject to the following major issues, listed from most general to most
specific:

1) A widening gap of understanding between the developers and the end
users. Not everyone has a fantastic tool chain and build environment that
allows them to jump around from one snapshot to the next, cost free.
We've got a thousand of these things, and not only are we going to run
RELEASE software ONLY, but we're going to do everything we can to match
that environment up across as large of an installed base as possible.
The daily chatter on the lists about getting stable and getting current,
or moving to the next major release reflects a complete disconnect between
developers and end users.

2) Having two simultaneous production releases draws focus away from both
of them, and keeps any release from ever truly maturing. In January of
2012, we should be on 6.12 (or so) and just breaking ground on 7.0.
Instead, each release gets perhaps two years of focused development before
every new fix is applied only to the upcoming release, and any kind of
support or enthusiasm from the community just disappears.

This means that any serious or wide deployment gets stuck with a bad
choice every two years - keep running something that's already essentially
abandoned, or spend all of that time and money on QA, testing,
documentation, shipping, etc., all over again, just like they did two
years ago.

Of course the retort will be: "we added ZFS and ULE, etc., and those
warranted a full release" - and maybe that's true, but since ZFS is only
now, circa 8.3 (god willing) ready for any kind of prime time
deployment[2], it would have been just fine to "release" it today, in 7.0.

3) Having two simultaneous production releases draws investment away from
FreeBSD, because the relevance and longevity of those fixes are unknown.
I am sure we are not the only organization that either needs new features,
or needs fixes, that just aren't on others' priority lists. In the past,
we've donated time and money[3][4] to try to push some of these things
forward, but it makes less and less sense when the lifespan of any
particular fixes are limited to the shorter and shorter lifespans of the
releases. Why pay to get this fixed today when it's either "already fixed
in CURRENT" or is already irrelevant ? Meanwhile, end users that don't
have the option to hire contract coders just lose out.

4) New code and fixes that people NEED TODAY just sits on the shelf for 8
or 10 or (nowadays) 13 months while end users wait for new minor releases.
Not only does this hurt end users, but it also hurts downstream projects,
like pfsense and FreeNAS.

Here's a good example: somewhere around 2007, a great many PCMCIA network
cards (of interest to pfsense users, like me) just quit working.[5] I
found that this was still the case in 2010. I asked Warner about it, it
got MFC'd, and I donated some hardware towards keeping these devices
maintained. So far so good. But this was in June of 2011 which means
that 8 months later this still isn't released and certainly isn't in
pfsense. Ok, fine - if I'm fiddling with PCMCIA cards in 2011, then
perhaps "get CURRENT" is a reasonable response ... but be honest, do you
have a build environment that allows you to take FreeBSD CURRENT and
generate a new pfsense build from that ? Do any pfsense end users have
that ? I don't. More frequent minor releases would be a boon here.

5) New code and fixes that people NEED TODAY often get pushed into the
next major release, since that's what people are working on anyway.

A few years ago we were dying for new em(4) and twa(4) drivers in FreeBSD
6, but they were applied only to 7 and beyond, since that was the "new
production" release (as opposed to the "old production" release). It's
the same bad choice again: make major investments in testing and people
and processes every two years, or just limp along with old, buggy drivers
and no support.


Suggestions:


Here are the specific actions that I think would dramatically improve the
focus of the project, the experience of real end users, and the ability
for third parties to truly invest in FreeBSD:

- Stop the trend of FreeBSD being an operating system by and for FreeBSD
developers. Think about the processes and costs that large and wide
installed bases incur. Think about the logistics of major upgrades and
the difficulty of running snapshot releases, etc. Remember - if it's not
fixed in the production release, it's NOT FIXED. Serious (large) end
users have very little use for CURRENT.[6]

- Focus on one production release at a time. Preferably for a solid five
years. In addition, provide actual legacy support for that release for
another five years after that. Five years of production and another five
years of legacy would provide a very stable platform for development and
investment, and would signal to large, complex organizations that FreeBSD
takes their needs seriously.

- Release a minor revision every 4 months. This sounds aggressive, but
it's a lot easier if the project isn't simultaneously working on a second
"production" release at the same time.


Thank you for reading this. I look forward to comments and discussion.


John Kozubik


[1] http://lists.freebsd.org/pipermail/freebsd-chat/2011-September/006630.html
[2] Thank you for not hijacking the thread RE: production-worthiness of
ZFS. Just read freebsd-fs for a bit and you'll be sufficiently wary.
[3] http://blog.kozubik.com/john_kozubik/2009/01/64bit-freebsd-quotas.html
[4] http://www.rsync.net/resources/notices/2007cb.html
[5] http://www.freebsd.org/cgi/query-pr.cgi?pr=115623#reply12
[6] It's worth reminding people that the official stance of the FreeBSD
project is that *even STABLE* is "not a resource for end-users".
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

[William Bentley]

I also echo John's sentiments here. Very excellent points made here.
Thank you for voicing your opinion. I was beginning to think I was the
only one who felt this way.

I also have several FreeBSD installations spread across different
development/production systems and it is not feasible to always upgrade
to the latest and greatest. Part of why FreeBSD is difficult to adopt
into more of the commercial/government sectors is because of this fast
paced release cycle and most of the important patches/fixes are not
backported far enough. This is why most of my customers decide to use
Solaris or RedHat and not FreeBSD. (Not looking to start a flame war
about the OS choice/etc just pointing out the Release cycle model). I
would love to push FreeBSD harder but it is becoming increasingly
difficult as of late.

We seem to have lost our way around the release of FreeBSD 7. I am all
in favor of new features but not at the risk of stability and proper
life cycle management.

Are me and John the only people that feel this way or are we among the
minority?


-Will

[Julian Elischer]

On 1/16/12 3:32 PM, William Bentley wrote:
> I also echo John's sentiments here. Very excellent points made here.
> Thank you for voicing your opinion. I was beginning to think I was the
> only one who felt this way.

[...]

> We seem to have lost our way around the release of FreeBSD 7. I am all
> in favor of new features but not at the risk of stability and proper
> life cycle management.
>
> Are me and John the only people that feel this way or are we among the
> minority?
>
>
> -Will
>
>

It pretty much boils down to one thing.. man power..

[Garrett Cooper]

On Mon, Jan 16, 2012 at 3:32 PM, William Bentley <Wil...@futurecis.com> wrote:
> I also echo John's sentiments here. Very excellent points made here.
> Thank you for voicing your opinion. I was beginning to think I was the
> only one who felt this way.
>
> I also have several FreeBSD installations spread across different
> development/production systems and it is not feasible to always upgrade
> to the latest and greatest. Part of why FreeBSD is difficult to adopt
> into more of the commercial/government sectors is because of this fast
> paced release cycle and most of the important patches/fixes are not
> backported far enough. This is why most of my customers decide to use
> Solaris or RedHat and not FreeBSD. (Not looking to start a flame war
> about the OS choice/etc just pointing out the Release cycle model). I
> would love to push FreeBSD harder but it is becoming increasingly
> difficult as of late.
>
> We seem to have lost our way around the release of FreeBSD 7. I am all
> in favor of new features but not at the risk of stability and proper
> life cycle management.
>
> Are me and John the only people that feel this way or are we among the
> minority?

You aren't. There are other people like Devin Teske's group that
feel the same (they're upgrading from 4.x to 8.2! Brave man.. and
godspeed to him), along with some development organizations that
depend on long release cycles (IronPort, Isilon, etc).
That being said. More people, more likelihood to succeed with what
you need, like julian@ suggests. I like long release cycles too for
stuff that I find critical and "in production", like my router. My
fileserver is a slightly different story, but I just got off the
CURRENT bandwagon off on to the 9-STABLE bandwagon :).
Cheers,
-Garrett

[John Kozubik]

Julian,

On Mon, 16 Jan 2012, Julian Elischer wrote:

> It pretty much boils down to one thing.. man power..

Wouldn't there be more manpower available for more frequent minor releases
if the project were not undertaking two simultaneous "production"
releases ? Specifically, wouldn't it have been feasible to be at 8.4
right now if much of 2011 had not been spent breaking ground on 9.0 ?

Further, isn't the lack of focus, or "polish" of the current release also
impacted by these decisions ?

Of course there is a limited amount of manpower, but for the points I
raised that was a symptom, not a cause...

[Steven Hartland]

----- Original Message -----
From: "John Kozubik" <jo...@kozubik.com>
To: <freebsd...@freebsd.org>
Sent: Monday, January 16, 2012 10:28 PM
Subject: FreeBSD has serious problems with focus, longevity, and lifecycle


>
> Friends,
>
> I was disappointed to see that 8.3-RELEASE is now slated to come out in
> March of 2012. This will be ~13 months since 8.2-RELEASE and is typical
> of a trend towards longer gaps between minor releases.

..

I must say as a small company that runs ~200 machines on FreeBSD
I do see where John is coming from, as it is very time consuming to keep
things up to date and new is not always better e.g. we still have boxes
stuck on 6.x as issues introduced in the Linux compat after that caused
problems.

That said I'm in two minds as the features that have been brought in by
the more rapid dev cycle like ZFS have been great.

Where I do see an issue is where it feels like we've just got to a solid
8.2 release with p6 and some addition patches we see things like em driver
updates required to run newer hardware only in 9.

While we might like to push everything to 9 it brings with it a large
amount of untested changes like the HPN patches to core ssh which we
have seen problems with under openssh-portable when tested.

So this puts us in a dilemma, push to 9 and keep up to date or stick
with 8.2 with custom patches while we wait for 8.3 which we know is
good and assuming it has the patches need included in it?

The correct answer for us is currently unknown and is still being
debated, but in the mean time we are going to keep with 8.2 until
we've had the chance to fully evaluate what 9 has to offer.

Regards
Steve



================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postm...@multiplay.co.uk.

[Atom Smasher]

thanks john.

i've been a long-time (10+ years) freeBSD user (desktops, laptops,
servers, and anywhere else i can run it) and advocate (encouraging others
to at least check it out) and also a long-time satisfied johnco customer.

my freeBSD days seem to be coming to an end.

i bought myself a LENOVO T510 when it first came out, around early 2010.
it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i
STILL can't run xorg properly with it. linux has run fine with it since i
opened the box. last i checked, freeBSD will be support this GPU in R9...
or maybe R10...?

i really like freeBSD's robustness, especially compared to linux, among
other things. i like that freeBSD is genetically a "real" unix... what's
the real difference between BSD and linux? BSD was developed by unix
hackers porting the OS to PC hardware; linux was developed by PC hackers
trying to make their own version of unix. these origins are still very
apparent, if one knows where to look.

i like that i can set up a freeBSD bare-bones (eg secure) mail-server or
web-server in an afternoon.

but none of that matters if the damn thing just doesn't work.

over the last two years, and it pains me to say this, i've been running
linux on that T510. but it gets worse... i've been finding that i'm simply
more productive on that machine, and spending more time in front of it,
and more time getting useful things done.

i understand that it's ultimately a matter of manpower and resources, and
linux seems to have more momentum and "sex appeal", but i'm finding myself
in a real crisis of faith... the OS that i've been using and loving for
10+ years seems to be dying, from any real usability perspective.

and for now, i'm slowly and reluctantly migrating towards linux.


--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"We will, in fact, be greeted as liberators."
-- Dick Cheney, 16 March 2003

[richo]

On 16/01/12 16:13 -0800, John Kozubik wrote:
>
>Julian,
>
>On Mon, 16 Jan 2012, Julian Elischer wrote:
>
>>It pretty much boils down to one thing.. man power..
>
>
>Wouldn't there be more manpower available for more frequent minor
>releases if the project were not undertaking two simultaneous
>"production" releases ? Specifically, wouldn't it have been feasible
>to be at 8.4 right now if much of 2011 had not been spent breaking
>ground on 9.0 ?
>
>Further, isn't the lack of focus, or "polish" of the current release
>also impacted by these decisions ?
>
>Of course there is a limited amount of manpower, but for the points I
>raised that was a symptom, not a cause...

This would be a different argument if all the devs were paid a salary.

In many instances the devs in question wouldn't have the motivation to work
on the maintenence release, in others the work is sponsored but is moving in
a direction that is fundamentally incompatible with the 8.x release.

I'm not trying to refute your input, just offering some insight about how it
may not be strictly accurate.

--
richo || Today's excuse:

Please excuse me, I have to circuit an AC line through my head to get
this database working.
http://blog.psych0tik.net

[richo]

On 17/01/12 02:21 +0000, Igor Mozolevsky wrote:

>On 17 January 2012 01:02, richo <ri...@psych0tik.net> wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>

>Isn't this a bit of a cyclical argument: developers don't work because
>they are not paid a salary, the end-user base shrinks, BigCo doesn't
>want to pay for someone to put extra work in getting fBSD to do
>something that it can get elsewhere (eg Linux), fewer still developers
>work on fBSD, end-user base shrinks, BigCo is even more reluctant,
>even fewer....

Potentially, but it doesn't invalidate it, imo.

I'm very aware that the code I produce for $WORK is very different to code I
write in my own time. Code for $WORK is wrapped in test cases, clean, neat
and well documented.

code I write in my own time tends to be hackish, incomplete totally
undocumented and ludicrously easy to break because I'm intrigued by
implementing a single interesting figure that has my attention, or to see
whether or not a concept is technically feasible.

This is a shortcoming of mine that I should work to overcome, but I feel that
the same thing would likely extend to other developers, though in most cases
to a lesser degree. Without some other motivation most people naturally
gravitate towards newer "cool" features, rather than doing the relatively
boring maintenence and backporting.

Note though, that recognising this highlights my respect for the people who
take the time to do it, even though it may not be as "cool" as working on the
latest and greatest new feature.

--
richo || Today's excuse:

emissions from GSM-phones
http://blog.psych0tik.net

[Igor Mozolevsky]

On 17 January 2012 02:25, richo <ri...@psych0tik.net> wrote:
> On 17/01/12 02:21 +0000, Igor Mozolevsky wrote:
>>
>> On 17 January 2012 01:02, richo <ri...@psych0tik.net> wrote:
>>
>>> This would be a different argument if all the devs were paid a salary.
>>
>>
>> Isn't this a bit of a cyclical argument: developers don't work because
>> they are not paid a salary, the end-user base shrinks, BigCo doesn't
>> want to pay for someone to put extra work in getting fBSD to do
>> something that it can get elsewhere (eg Linux), fewer still developers
>> work on fBSD, end-user base shrinks, BigCo is even more reluctant,
>> even fewer....
>
>
> Potentially, but it doesn't invalidate it, imo.
>
> I'm very aware that the code I produce for $WORK is very different to code I
> write in my own time. Code for $WORK is wrapped in test cases, clean, neat
> and well documented.
>
> code I write in my own time tends to be hackish, incomplete totally
> undocumented and ludicrously easy to break because I'm intrigued by
> implementing a single interesting figure that has my attention, or to see
> whether or not a concept is technically feasible.
>
> This is a shortcoming of mine that I should work to overcome, but I feel
> that
> the same thing would likely extend to other developers, though in most cases
> to a lesser degree. Without some other motivation most people naturally
> gravitate towards newer "cool" features, rather than doing the relatively
> boring maintenence and backporting.

Are you not making a case for long and thin release cycle vs short and
fat then? It's absolutely fine to have a branch (let's call that
"development") that is cool-and-funky and breaks in 70% of the cases
so long as there is another branch (let's call it "release") that is
not-so-cool-and-funky, but only breaks in 1% of the cases, but is well
documented, tested, &c and have the developer satisfaction of not only
having implemented something cool, but knowing that once that cool is
stable enough, that feature is used in environments where stability
and dependability matters? A cool feature that nobody can rely on is,
quite frankly, junk; is it not? To be realistic, I think any serious
developer should expect to spend 70% of their development time on
maintenance, for a simple reason that if the software is not
maintained to the standard that end-users find usable, they will
simply switch, and the user-base to test your latest cool-and-funky
gets smaller and smaller... Of course, one way to avoid the 70% being
spent on maintenance is to write flawless software, but good luck with
that! ;-)

This goes back to one of the points that John K. made: who is the
system for, the developers or the end users? A system for the latter
will quite happily give enough playground for the former, but a system
for the former, will never work for the latter. Which, I suppose, is
why your $WORK demands a certain quality of code---one way or another
their livelihood depends on it!..


--
Igor M. :-)

[Yuri]

On 01/16/2012 17:03, Atom Smasher wrote:
>
> i bought myself a LENOVO T510 when it first came out, around early
> 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on
> freeBSD i STILL can't run xorg properly with it. linux has run fine
> with it since i opened the box. last i checked, freeBSD will be
> support this GPU in R9... or maybe R10...?

The usual explanation for this is that FreeBSD is the server OS and
doesn't need to worry about desktop-only hardware. (Not that I agree
with such position.)
I noticed that FreeBSD overall isn't too good for laptops (correct me
if I am wrong). Even if Arrandale GPU worked, there is no working
network manager in kde or gnome, able to find and setup WiFi networks
without user typing anything. Also FreeBSD isn't able to enter (and come
back from) the sleep mode. Also it can't stop the hard drives when the
system is idle (last time I tried I got system crash). These make it
very difficult to use FreeBSD on the laptops. Major usability issues.

Yuri

[Igor Mozolevsky]

On 17 January 2012 01:02, richo <ri...@psych0tik.net> wrote:

> This would be a different argument if all the devs were paid a salary.

Isn't this a bit of a cyclical argument: developers don't work because
they are not paid a salary, the end-user base shrinks, BigCo doesn't
want to pay for someone to put extra work in getting fBSD to do
something that it can get elsewhere (eg Linux), fewer still developers
work on fBSD, end-user base shrinks, BigCo is even more reluctant,
even fewer....

--
Igor M. :-)

[Doug Barton]

On 01/16/2012 16:02, Julian Elischer wrote:
> It pretty much boils down to one thing.. man power..

If the basic design of the system is wrong, it doesn't matter how many
person-hours you throw at it (or don't).

--

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

[Atom Smasher]

On Tue, 17 Jan 2012, richo wrote:

> I'm very aware that the code I produce for $WORK is very different to
> code I write in my own time. Code for $WORK is wrapped in test cases,
> clean, neat and well documented.
>
> code I write in my own time tends to be hackish, incomplete totally
> undocumented and ludicrously easy to break because I'm intrigued by
> implementing a single interesting figure that has my attention, or to
> see whether or not a concept is technically feasible.

====================

code i write for work is (typically) under pressure of time and money.
sometimes good documentation is more important than good code, sometimes
documentation is irrelevant. at work i've been complimented for getting
things done on time and under budget, but NEVER for getting it done right.

code i write in my own time is art. i wouldn't write a sloppy song in my
spare time, and i don't write sloppy code in my spare time.

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

A student asked his old Sufi Master if he should tie up
his camel for the night, so that it wouldn't wander
away while they were sleeping or if doing so was an
insult to God. Should he leave the camel untied to
show his trust in God that the camel wouldn't run away?
The Master replied "Trust God AND tie up your camel."

[John Kozubik]

On Tue, 17 Jan 2012, Steven Hartland wrote:

>> I was disappointed to see that 8.3-RELEASE is now slated to come out in
>> March of 2012. This will be ~13 months since 8.2-RELEASE and is typical of
>> a trend towards longer gaps between minor releases.
>

> ...

>
> I must say as a small company that runs ~200 machines on FreeBSD
> I do see where John is coming from, as it is very time consuming to keep
> things up to date and new is not always better e.g. we still have boxes
> stuck on 6.x as issues introduced in the Linux compat after that caused
> problems.
>
> That said I'm in two minds as the features that have been brought in by
> the more rapid dev cycle like ZFS have been great.

The features are great - nobody doesn't want the features! Like I said in
the original post, as wonderful as ZFS on FreeBSD is (and we are deploying
it this year) it is only now (well, in March) with 8.3 that I feel it is
finally safe and stable enough to bet the farm on. I'm not the only one
that feels this way.

If that's the case, then, ZFS could have been developed just as it has, in
a development branch, and not been used as justification for (mutiple)
major releases and all of their disruption.

As I said in the original post - we should be on 6.12 right now, and
bringing out 7.0, with ZFS v28.

> Where I do see an issue is where it feels like we've just got to a solid
> 8.2 release with p6 and some addition patches we see things like em driver
> updates required to run newer hardware only in 9.

That's a few releases in a row now where "legacy" gets locked out of new
motherboards because of em(4). But I digress...

> While we might like to push everything to 9 it brings with it a large
> amount of untested changes like the HPN patches to core ssh which we
> have seen problems with under openssh-portable when tested.
>
> So this puts us in a dilemma, push to 9 and keep up to date or stick
> with 8.2 with custom patches while we wait for 8.3 which we know is
> good and assuming it has the patches need included in it?

Exactly. We're in the same boat.

Longer, dedicated lifecycle, extended legacy support, and more frequent
minor releases were my original suggestions. Why not take the "newer
production release" (or whatever 9.0 is) and rename it "development" ?

Why couldn't this change happen today, specifically with 8.x and 9.x ?

[Freddie Cash]

Just a note before everyone goes off on wonderful things were with FreeBSD
4.x going all the way to 4.11:

4.x is an anomoly in the history of FreeBSD major versions, being the only
release with more than 4? 5? minor releases.

There were only a couple minor versions of 1.x; there were only a couple of
minor versions of 2.x; there were only a couple minor versions of 3.x; and
so on through to 8.x.

IOW, the 'glory days before 5.0' is really no different than the days since
5.0. Looking at the complete history of FreeBSD releases, 4.x is the
outlier that needs to be discarded for the stats to make sense. (Or
something like that, I've failed stats 3 times now.) :)

When I started with FreeBSD, there were two production releases available:
2.2.something and 3.1. They even came in the same box set from Walnut
Creek? Forget where I ordered them online now. Shortly after, 4.0 was
released, but 3.x was stil developped.

The only difference between pre-5 and post-5 is the switch from
feature-based releases that could take years to develop, to time-based
releases that ship at mostly-regular times, with whatever features are
ready. The latter is actually more useful, as you can plan ahead of time
as you know the general timeframes between major versions.

So, let's keep a little perspective in the discussion, and not ignore the
past history of FreeBSD releases.

Cheers,
Freddie

[Royce Williams]

John's trying to manage risk.  Switching from RELEASE to CURRENT adds
a lot of risk and churn, when most folks in this class of use case
just need a few very specific drivers and bugfixes (what some OSes
call "hotfixes".)

John sounds willing to trade a little bit of local risk (and testing
time) in exchange for a way to self-serve a hotfix without abandoning
RELEASE.  How can we enable that?

There are simple cases -- the ones that just need a few files and a
kernel module -- that seem within easy reach.  For example, the eRacks
guys generated these handy binaries for mps(4) for 7.4, 8.0, 8.1 and
8.2:

http://blog.eracks.com/2011/08/lsi-logic-6gbps-mps-driver-for-freebsd-8-2-release/

For me, this was perfect: I got to have my cake (tracking 8.1-RELEASE,
and using freebsd-update) and eat it too (support for specific newer
hardware).  If security updates break my mps(4), I'm on my own -- but
it's still a much better balance of risk for me than switching to
CURRENT.

I know that some fixes are harder than just adding a kernel module.  I
know that the standards for releasing errata are high, and they should
be.  But I wish there was a way to optionally lower that threshold and
say: "Yes, I know this might eat my data.  Let me judge and test that
for myself without otherwise abandoning RELEASE."  If there was a way
to mark hotfixes as "worked for me" (to let the better ones bubble up
to the top), we non-coders could even help manage the list.

I can't do it myself, but I would happily help brainstorm, test  --
and commit $100 or more, Kickstarter-style, to fund someone else's
work.

Royce

[Damien Fleuriot]

On 1/16/12 11:28 PM, John Kozubik wrote:
>
> Friends,
>
> I was disappointed to see that 8.3-RELEASE is now slated to come out in
> March of 2012. This will be ~13 months since 8.2-RELEASE and is typical
> of a trend towards longer gaps between minor releases.
>
> I also see that undercutting the current release before wide deployment
> and maturity is continuing. 7.0 came (barely) after 6.3, which was bad
> enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.
>
> Finally, the culture of "that's fixed in CURRENT" or "we built those
> changes into (insert next major release)" continues to get worse. It's
> difficult to escape the notion that FreeBSD is becoming an operating
> system by, and for, FreeBSD developers.
>

Wholeheartedly agree.

I'm having an increasingly difficult time defending FreeBSD in our
company against the advances of debian kfree which is much easier to
maintain.
Can we get back to the 4.x release style and, hopefully, see some 9.7,
9.8... ?

Check this PR I opened some months ago:
http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern

It was planned for 9.0-RELEASE, there is no mention of 8.x
That's just the kind of problem John raises here.


I can't keep on defending FreeBSD when the minor fix to a major bug
isn't backported, and only makes it to the next major version, 4 or 5
months from now.

[Andriy Gapon]

on 17/01/2012 00:28 John Kozubik said the following:

> we going to run RELEASE software ONLY

My opinion: you've put yourself in a box that is not very compatible with the
current FreeBSD release strategy. With your scale and restrictions you probably
should just use the FreeBSD source and roll your own releases from a stable
branch of interest (including testing, etc). Or have your own "branch" where
you could cherry-pick interesting changes from any FreeBSD branches. Tools like
e.g. git and mercurial make it easy. Of course, this strategy is not as easy as
trying to persuade the rest of FreeBSD community/project/thing to change its
ways, but perhaps a little bit more realistic. You can bond with similarly
minded organizations to share costs/work/etc. It's a community-driven project
after all.

--
Andriy Gapon

[Atom Smasher]

On Mon, 16 Jan 2012, Yuri wrote:

> On 01/16/2012 17:03, Atom Smasher wrote:
>>
>> i bought myself a LENOVO T510 when it first came out, around early
>> 2010. it's got an i5 CPU and Arrandale GPU. it's two years old and on
>> freeBSD i STILL can't run xorg properly with it. linux has run fine
>> with it since i opened the box. last i checked, freeBSD will be support
>> this GPU in R9... or maybe R10...?
>
> The usual explanation for this is that FreeBSD is the server OS and
> doesn't need to worry about desktop-only hardware. (Not that I agree
> with such position.) I noticed that FreeBSD overall isn't too good for
> laptops (correct me if I am wrong). Even if Arrandale GPU worked, there
> is no working network manager in kde or gnome, able to find and setup
> WiFi networks without user typing anything. Also FreeBSD isn't able to
> enter (and come back from) the sleep mode. Also it can't stop the hard
> drives when the system is idle (last time I tried I got system crash).
> These make it very difficult to use FreeBSD on the laptops. Major
> usability issues.

==================

so i guess that means that i'm tougher than a typical laptop user... and
instead of making things easier, freeBSD is getting harder.

thing is, when people don't "play" with freeBSD on laptops and desktops,
then they grow up, get real jobs, and don't know much about it.

if this keeps up, i'll cross a line where i just get more comfortable with
linux and migrate my freeBSD servers to it.

this is one of the areas where linux is doing well... people are "playing"
with it, but in the process they're getting used to it and comfortable
with it. from that background, they can install a linux based server
without breaking a sweat. linux's ease of use and hardware support are
seeding the next generation of FLOSS and *nix users... and most of them
have never installed/used freeBSD.

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"Don't suspect your friends - turn them in!"
-- Brazil

[Ivan Voras]

(answering out of order)

On 16/01/2012 23:28, John Kozubik wrote:

> 2) Having two simultaneous production releases draws focus away from
> both of them, and keeps any release from ever truly maturing.

This isn't how things work. The -CURRENT always has (and probably always
had and always will have) the focus of developers. The "releases" are
for many people simply a periodical annoyance due to freezes. In no way
will reducing the number of "production releases" change this. As a
volunteer effort, backports to stable branches only happen when 1) it's
in the interest of the developer, e.g. "I've found a bug on my systems,
want to get it fixed in -STABLE" and 2) when the developer is budged by
outside forces (users complaining, other developers requesting it) and
3) they think it's worth doing and have time to do it spontaneously.
These are in order of likelihood to happen.

You could say the question is: why is it so, but I think you know the
answer to that: small project, not enough manpower and volunteer-hours.
However, the situation is actually quite good because the developers are
usually very responsive to MFC requests...

> going to
> run RELEASE software ONLY

> 4) New code and fixes that people NEED TODAY just sits on the shelf for
> 8 or 10 or (nowadays) 13 months while end users wait for new minor
> releases.

.. except if you expect regular releases :)

I've concluded very early that because of what I've said above, the only
way to run FreeBSD effectively is to track -STABLE. The developers
MFC-ing stuff usually try hard not to break things so -STABLE has become
a sort of "running RELEASE" branch. Since -STABLE is so ... stable ...,
there is less and less incentive to make proper releases (though I think
nobody would mind it happening).

The next question is: what do releases from a -STABLE branch bring in
that simply tracking the original -STABLE tree doesn't? Lately, not very
much. Since there is a huge number of users and developers tracking
-STABLE, the testing done specifically for a X.Y, Y>0 RELEASE is not
very extensive, so you just as well could have tracked -STABLE.

I'm sure you know how easy it is to upgrade a STABLE-running system, and
there are simple ways in which that can be made to scale to thousands of
machines. Breakage is of course a risk, but not significantly greater
than for any other upgrading.

> of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0.
> Instead, each release gets perhaps two years of focused development
> before every new fix is applied only to the upcoming release, and any
> kind of support or enthusiasm from the community just disappears.

If you're saying that -STABLE branches don't get fixes fast enough, I'd
disagree.

> A few years ago we were dying for new em(4) and twa(4) drivers in
> FreeBSD 6, but they were applied only to 7 and beyond, since that was
> the "new production" release (as opposed to the "old production"
> release). It's the same bad choice again: make major investments in
> testing and people and processes every two years, or just limp along
> with old, buggy drivers and no support.

Have you tried contacting the developers of those drivers? The most
likely causes the drivers weren't MFC-ed are either that they were
experimental enough that it was feared for their stability or that they
didn't think anyone needs drivers MFC-ed.

The situation you describe is certainly not FreeBSD-specific: Debian is
notoriously slow in adopting new features, but so is Red Hat Enterprise
Linux, which had the ancient (2006 vintage) 2.6.18 kernel throughout its
5.x cycle (still active in 2011) - though updated with new drivers.
Compared to these, FreeBSD is in many ways a pleasure to work with.

Seriously, just think of -STABLE as a "rolling release", just like the
ports tree.

[Ivan Voras]

On 17/01/2012 07:20, John Kozubik wrote:

> as wonderful as ZFS on FreeBSD is (and we are
> deploying it this year) it is only now (well, in March) with 8.3 that I
> feel it is finally safe and stable enough to bet the farm on. I'm not
> the only one that feels this way.

I must remember to ask you about your experiences with ZFS in about a
year from now :)

[Tom Evans]

On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras <ivo...@freebsd.org> wrote:
> I've concluded very early that because of what I've said above, the only way
> to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff
> usually try hard not to break things so -STABLE has become a sort of
> "running RELEASE" branch. Since -STABLE is so ... stable ..., there is less
> and less incentive to make proper releases (though I think nobody would mind
> it happening).
>
> The next question is: what do releases from a -STABLE branch bring in that
> simply tracking the original -STABLE tree doesn't? Lately, not very much.

Sorry to just pick out bits of your email Ivan…

Ability to use freebsd-update. It would be better to have more
frequent releases. As a prime example, ZFS became much more stable
about 3 months after 8.2 was released. If you were waiting for an 8.x
release that supported that improved version of ZFS, you are still
waiting.

You say that snapshots of STABLE are stable and effectively a running
release branch, so why can't more releases be made?

Is the release process too complex for minor revisions, could that be
improved to make it easier to have more releases, eg by not bundling
ports packages?

Can it really be that the best advice for users is to run their own
build infrastructure and make their own releases?

I really don't want to come across as someone throwing their toys out
and saying that unless everything changes I'm off to Linux-land,
however there is mutterings at $JOB that too much time is spent
massaging FreeBSD and that using Linux would be significantly easier
to manage.

Cheers

Tom

[Ivan Voras]

On 17 January 2012 13:02, Tom Evans <teva...@googlemail.com> wrote:
> On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras <ivo...@freebsd.org> wrote:
>> I've concluded very early that because of what I've said above, the only way
>> to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff
>> usually try hard not to break things so -STABLE has become a sort of
>> "running RELEASE" branch. Since -STABLE is so ... stable ..., there is less
>> and less incentive to make proper releases (though I think nobody would mind
>> it happening).
>>
>> The next question is: what do releases from a -STABLE branch bring in that
>> simply tracking the original -STABLE tree doesn't? Lately, not very much.
>
> Sorry to just pick out bits of your email Ivan…
>
> Ability to use freebsd-update. It would be better to have more
> frequent releases. As a prime example, ZFS became much more stable
> about 3 months after 8.2 was released. If you were waiting for an 8.x
> release that supported that improved version of ZFS, you are still
> waiting.

You know, that's an excellent point! And maybe an excellent idea: to
provide occasional, time-based STABLE snapshots for freebsd-update.

> You say that snapshots of STABLE are stable and effectively a running
> release branch, so why can't more releases be made?

Nobody volunteered :(

> Is the release process too complex for minor revisions, could that be
> improved to make it easier to have more releases, eg by not bundling
> ports packages?

Almost certainly yes. The current release process involves src, ports
and docs teams. Would you and other RELEASE users be happy with simple
periodic snapshots off the STABLE branches, not much different from
tracking STABLE? The only benefit I see would be a light-weight
opportunity for testing which would probably end up being implemented
by moving to date-based tags (e.g. if a critical bug is found and the
fix MFC-ed, the "current" tag would be advanced to "$today")?

> Can it really be that the best advice for users is to run their own
> build infrastructure and make their own releases?

Maybe. I'm trying to suggest that it looks like (I may be wrong, of
course) that the effort required to upgrade from one RELEASE to the
other is comparable to the effort of just having a -STABLE build
machine somewhere and doing "make installkernel, make installworld,
mergemaster -FU" over NFS on a 1000 machines. If you are serious about
testing, you would need to test the RELEASEs also.

> I really don't want to come across as someone throwing their toys out
> and saying that unless everything changes I'm off to Linux-land,
> however there is mutterings at $JOB that too much time is spent
> massaging FreeBSD and that using Linux would be significantly easier
> to manage.

Personally, I actually like apt-get and the way it handles installs,
updates, dependencies, suggesteions, etc. I dislike almost everything
else, thoughj.

But now I'm curious: how do you (and others) update from one RELEASE
to the other? Just by using freebsd-update? What do you think prevents
you from using -STABLE?

[Atom Smasher]

On Tue, 17 Jan 2012, richo wrote:

> This would be a different argument if all the devs were paid a salary.

==============

what percentage of linux devs are on salary to develop linux?

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"Patriotism is the willingness to kill
and be killed for trivial reasons."
-- Bertrand Russell

[Ivan Voras]

On 17/01/2012 07:32, Atom Smasher wrote:
> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
> ==============
>
> what percentage of linux devs are on salary to develop linux?

Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm

[Igor Mozolevsky]

On 17 January 2012 13:44, Ivan Voras <ivo...@freebsd.org> wrote:
> On 17/01/2012 07:32, Atom Smasher wrote:
>>
>> On Tue, 17 Jan 2012, richo wrote:
>>
>>> This would be a different argument if all the devs were paid a salary.
>>
>> ==============
>>
>> what percentage of linux devs are on salary to develop linux?
>
> Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm

Actually, you're misrepresenting the facts: according to the headline,
75% of the code came from paid developers, *not* 75% of developers are
paid... See the difference?..


--
Igor M.

[Ivan Voras]

On 17 January 2012 14:49, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:
> On 17 January 2012 13:44, Ivan Voras <ivo...@freebsd.org> wrote:
>> On 17/01/2012 07:32, Atom Smasher wrote:
>>>
>>> On Tue, 17 Jan 2012, richo wrote:
>>>
>>>> This would be a different argument if all the devs were paid a salary.
>>>
>>> ==============
>>>
>>> what percentage of linux devs are on salary to develop linux?
>>
>> Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm
>
> Actually, you're misrepresenting the facts: according to the headline,
> 75% of the code came from paid developers, *not* 75% of developers are
> paid... See the difference?..

Yes, you're correct.

[Igor Mozolevsky]

On 17 January 2012 14:20, Ivan Voras <ivo...@freebsd.org> wrote:
> On 17 January 2012 14:49, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:
>> On 17 January 2012 13:44, Ivan Voras <ivo...@freebsd.org> wrote:
>>> On 17/01/2012 07:32, Atom Smasher wrote:
>>>>
>>>> what percentage of linux devs are on salary to develop linux?
>>>
>>> Apparently, 3/4: http://apcmag.com/linux-now-75-corporate.htm
>>
>> Actually, you're misrepresenting the facts: according to the headline,
>> 75% of the code came from paid developers, *not* 75% of developers are
>> paid... See the difference?..
>
> Yes, you're correct.

Actually, I don't think it's cash that's the problem. I think it is
more to do with the lack of common goal: the way that releases are
perceived, at least by me, are that a bunch of people "play" in
current then at some point someone decides to take a "cut" of the
current branch and call it a release then work toward making that
"release" passable as stable. To illustrate that, I cannot find
anywhere on the .org website what core@ see the desirable features of
10.0 to be, or what the committers are working toward. It seems that
the "bazaar" model of development is at its worst here: everyone is
doing their own thing and at some point someone decides to call it a
day and make a release, nobody cares for what they have already done,
but only what they want to do in the future, non-committer patches go
ignored (no, I don't have a reference) which discourages end-user
contribution... I'm very happy to be shown wrong here, btw!..


--
Igor M. :-)

[Mark Felder]

Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd.
Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to
us that VMWare only supports -RELEASE and it took until ESX 5 to
officially support 8.2!

More releases / snapshots of -STABLE helps people on physical servers, but
anyone who runs VMs on Xen or VMWare won't get any support for those
versions because they didn't go through the QA process yet. FreeBSD is
increasingly becoming a third world citizen thanks to virtualization
efforts being focused on Linux, so I feel that more frequent releases
won't help as many people as you think.

[Chris Rees]

On 17 Jan 2012 13:38, "Atom Smasher" <at...@smasher.org> wrote:
>
> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
> ==============
>
> what percentage of linux devs are on salary to develop linux?
>

You're not comparing like with like.

Linux is not an OS; FreeBSD is.

Are you talking about Linux? Debian? Red Hat?

Chris

[Freddie Cash]

On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:
> Actually, I don't think it's cash that's the problem. I think it is
> more to do with the lack of common goal: the way that releases are
> perceived, at least by me, are that a bunch of people "play" in
> current then at some point someone decides to take a "cut" of the
> current branch and call it a release then work toward making that
> "release" passable as stable. To illustrate that, I cannot find
> anywhere on the .org website what core@ see the desirable features of
> 10.0 to be, or what the committers are working toward.

That would be because, with the multi-year debacle that 5.0-RELEASE
became while they worked on the "features list for 5.0" (primarily
SMPng), the FreeBSD Project has moved away from features-based
releases and to time-based releases (although the exact timelines are
not carved in stone).

You won't find a list of features for the next release of FreeBSD.
You'll just find a list of things that people are working on that may
or may not be ready in time for the next release.

The development is much closer to Ubuntu (release whatever is ready
every 6 months) than to Debian (release everything when it's ready,
even if it takes 2, 3, 4+ years to make it ready, while the current
release grows stale).

--
Freddie Cash
fjw...@gmail.com

[Igor Mozolevsky]

On 17 January 2012 16:48, Freddie Cash <fjw...@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 7:32 AM, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:
>> Actually, I don't think it's cash that's the problem. I think it is
>> more to do with the lack of common goal: the way that releases are
>> perceived, at least by me, are that a bunch of people "play" in
>> current then at some point someone decides to take a "cut" of the
>> current branch and call it a release then work toward making that
>> "release" passable as stable. To illustrate that, I cannot find
>> anywhere on the .org website what core@ see the desirable features of
>> 10.0 to be, or what the committers are working toward.
>
> That would be because, with the multi-year debacle that 5.0-RELEASE
> became while they worked on the "features list for 5.0" (primarily
> SMPng), the FreeBSD Project has moved away from features-based
> releases and to time-based releases (although the exact timelines are
> not carved in stone).
>
> You won't find a list of features for the next release of FreeBSD.
> You'll just find a list of things that people are working on that may
> or may not be ready in time for the next release.
>
> The development is much closer to Ubuntu (release whatever is ready
> every 6 months) than to Debian (release everything when it's ready,
> even if it takes 2, 3, 4+ years to make it ready, while the current
> release grows stale).

And this is the ridiculous "bazaar" situation that I was criticising.
In contrast to Ubuntu, or other distribution on top of Linux, FreeBSD
is a "whole" system. Even Ubuntu and such, take a "collection" of
projects that have been developed with certain measurable goals. Yes,
Ubuntu appears to be date-oriented distribution, but the software that
Ubuntu incorporate into their releases is feature- and goal- oriented.
FreeBSD, it seems, as I have pointed out, have no measurable goals
within the project itself other than "whatever looks like it has a
potential to work on date X" is going to be in our release. How can
this be even considered to be serious?.. No serious
manufacturer/producer says "throw things in a mix and we'll stick to
whatever passes as passable by date X"...


--
Igor M. :-)

[Victor Balada Diaz]

On Mon, Jan 16, 2012 at 02:28:09PM -0800, John Kozubik wrote:
>
> Friends,
>
> I was disappointed to see that 8.3-RELEASE is now slated to come out in
> March of 2012. This will be ~13 months since 8.2-RELEASE and is typical
> of a trend towards longer gaps between minor releases.
>
> I also see that undercutting the current release before wide deployment
> and maturity is continuing. 7.0 came (barely) after 6.3, which was bad
> enough, but not as bad as 8.0 arriving with 7.2, and now 9.0 with 8.2.
>
> Finally, the culture of "that's fixed in CURRENT" or "we built those
> changes into (insert next major release)" continues to get worse. It's
> difficult to escape the notion that FreeBSD is becoming an operating
> system by, and for, FreeBSD developers.
>

Hello John,

With my sysadmin hat on i can echo your feelings, but i guess that your
proposals are more focused on a company environment than a collaborative
environment.

First i would like to remember the last stage of FreeBSD 4.x for those
people (not you) who are arguing in the thread about long "stable" releases.
Those of us who used FreeBSD 4.x on the late release cycle will remember
a few of this problems:

- New hardware didn't work because no ACPI support was in 4.x until
4.11 or 4.12 (can't remember). Even then, it was considered a bad
idea to backport it because it was a huge change for a -STABLE branch.

- Because SMPng project involved a lot of changes, it was not easy to
backport drivers.

- SMP performance was horrible. As libc_r was the only option on 4.x
you got various performance and stability problems with apps designed
for a better threading model. A good example is MySQL performance. At
that time started the whole "mysql performance issues of FreeBSD vs linux"
that last until today.

- Porting some new apps was troublesome because a lot of libraries
had missing bits pending the big SMPng changes on 5.x. Mostly related to thread libs.

- 5.x was a huge change relating to POLA. Eg: init scripts changed to new rc.d
framework (iirc imported or based on NetBSD work).

At that time you had two options:

- Use rock solid FreeBSD 4.x and be unable to run more or less recent apps and hardware
without huge problems.

- Use FreeBSD 5.x which was unstable and slow compared to 4.x

Because of this problems some people migrated to Linux, a fork of FreeBSD with the idea
of an easier SMP model was created, etc.

FreeBSD project learnt a good lesson: If you wait too much for great features to came
to a reality instead of releasing often, you will not have features or stability. Ie:
The stable release is unusable because backporting drivers and libs is harder and you end with
unsupported new hardware as time passes, apps are harder to port because missing APIs,
etc. And the new "current" release is unusable because there are too many things in testing
and breaks in a lot of places.

At that time (maybe 6.x? can't remember for sure, maybe someone else will remember better)
the FreeBSD project announced a new way of doing releases. Release Timely instead of
release based on features. If you don't have a feature ready when it's time for releases, just skip
until next one instead of waiting.

Now a few years later as sysadmins we find that there are too many releases that don't last
too much. We waste a lot of time testing upgrades and once they're in production releases
don't last often enough for the effort to be worthwile. Hence, John mail.

I agree with John on the problems, but i disagree on solutions and the causes. No solution
is going to work if you expect volunteers to do anything for a long time that's boring. You lost
interest and stop working on that.

What i really think it's the problem:

If you try to maintain a few servers without much resources you end replicating half FreeBSD's
project release infraestructure:

- You find a bug, report, get a patch and apply. After that, you lost forever the option
of using freebsd-update. You need to reinstall the system to get freebsd-update again

- You want binary updates with custom kernel or patches? -> Your only option is cutting your
own releases or forget about freebsd-update.

- You want to track packages on various machines? -> create your tinderbox because binary package upgrades
is a no-op with standard packages distributed by the project.

- You want to apply a security update to a custom kernel? -> no binary option

- Do you want to apply just one security update but no other to a standard kernel? -> no option
freebsd-update will just allow you all patches or none.

- Performance problems? Usually involves recompiling with different compiler or kernel/userland options.
Again: no easy binary upgrade path.

As you can see, if you want to change something, you end doing half the release process yourself for
easy things like patch handling, package upgrades or binary upgrading. And what's worse:
You can't easily change from custom-built system to standard system once bugs are fixed and get to
mainstream.

If you're a small FreeBSD user with 10-300 servers it will hurt a lot to do most of release engenieering
yourself to just get a little flexibility.

We're half binary, half source.

I think that the best thing for improving sysadmin experiencie is to lower the entry of useful
tools that allow to easily administer lots of different servers.

It's not hard to get a patch from a developer for a small driver update. It's not even that expensive
to pay someone for a backport. I've done various myself in the years i've been using FreeBSD. What's
really expensive is maintaining the infraestructure needed for just one patch.

The difference of a standard RELEASE install vs standard release with a small re(4) patch is that now
i suddenly need to build releases, create freebsd-update servers etc.

Thinking on how other projects get the same thing done you can look at Debian project. If you need
to patch any util, as you have system packages, you just patch a .deb and post it to a custom FTP server.
Now all servers could easily update from that package. Once the patches are in mainstream version, you
just need to forget about your package and system will use the newer official version without problems.

This also gets for free community involvement: Eg debian backports[1] for stable releases. People interested
in getting long support cycles for releases can collaborate. Now try to do that with backports for RELEASES
on FreeBSD.

What we lack, IMO is flexibility for binary updates/upgrades and some way of having system packages.

Of course if noone is interested in wasting his time on writing all of this, nothing will get done of this talk,
but i just wanted to offer a different solution that shouldn't be that hard to implement or sponsor and
could make developers and big companies happy without any of them having to do long-time work.

I hope you've been able to understand me because english is not my native language.

Have a nice day.
Victor.

[1]: http://backports-master.debian.org/

--
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros.

[Damien Fleuriot]

On 1/17/12 4:39 PM, Mark Felder wrote:
> Why is everyone so afraid of running -STABLE? Plenty of stuff gets
> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
> frustrating to us that VMWare only supports -RELEASE and it took until
> ESX 5 to officially support 8.2!
>
> More releases / snapshots of -STABLE helps people on physical servers,
> but anyone who runs VMs on Xen or VMWare won't get any support for those
> versions because they didn't go through the QA process yet. FreeBSD is
> increasingly becoming a third world citizen thanks to virtualization
> efforts being focused on Linux, so I feel that more frequent releases
> won't help as many people as you think.
>

Running FBSD in a *production* environment means you want something
stable and tested.

-STABLE does not fulfill the requirements I'm afraid.

We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here.

[Igor Mozolevsky]

On 17 January 2012 15:39, Mark Felder <fe...@feld.me> wrote:

> FreeBSD is increasingly becoming a third world citizen thanks to
> virtualization efforts being focused on Linux, so I feel that more
> frequent releases won't help as many people as you think.

I would guess that for folks like VMWare, the choice of their focus is
essentially determined by their customers and not by them themselves.
So if VMWare choose to focus more on Linux over FreeBSD it is simply
indicative that VMWare's customers demand Linux support more that the
FreeBSD one... Now, why is there more end-user demand for Linux than
FreeBSD? I am guessing that is exactly what John K's original post was
trying to address...


--
Igor M. :-)

[John Kozubik]

Ivan,

On Tue, 17 Jan 2012, Ivan Voras wrote:

>> 2) Having two simultaneous production releases draws focus away from
>> both of them, and keeps any release from ever truly maturing.
>
> This isn't how things work. The -CURRENT always has (and probably always had
> and always will have) the focus of developers. The "releases" are for many
> people simply a periodical annoyance due to freezes. In no way will reducing
> the number of "production releases" change this. As a volunteer effort,
> backports to stable branches only happen when 1) it's in the interest of the
> developer, e.g. "I've found a bug on my systems, want to get it fixed in
> -STABLE" and 2) when the developer is budged by outside forces (users
> complaining, other developers requesting it) and 3) they think it's worth
> doing and have time to do it spontaneously. These are in order of likelihood
> to happen.

I could not have illustrated my point better, RE: FreeBSD becoming an OS

by, and for, FreeBSD developers.

I wish I could find the quote - it was from one of the FreeBSD core team
many years ago, and it was something along the lines of "we are holding
a piece in one of the highest stakes games in the modern world". Now
juxtapose that with "The "releases" are for many people simply a
periodical annoyance".

>> going to
>> run RELEASE software ONLY
>
>> 4) New code and fixes that people NEED TODAY just sits on the shelf for
>> 8 or 10 or (nowadays) 13 months while end users wait for new minor
>> releases.
>

> ... except if you expect regular releases :)

>
> I've concluded very early that because of what I've said above, the only way
> to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff
> usually try hard not to break things so -STABLE has become a sort of "running
> RELEASE" branch. Since -STABLE is so ... stable ..., there is less and less
> incentive to make proper releases (though I think nobody would mind it
> happening).

Impossible. I'm not a FreeBSD guy, I'm a business owner. Like most
businesses, we are running official, delivered, release software only.
Controller firmware ? Release only. Motherboard BIOS ? Release only.
Drivers ? Release only. Just because I *happen* to also have some
techincal expertise with FreeBSD, and some geeky tendencies does not mean
we're making any exceptions.

> The next question is: what do releases from a -STABLE branch bring in that
> simply tracking the original -STABLE tree doesn't? Lately, not very much.
> Since there is a huge number of users and developers tracking -STABLE, the
> testing done specifically for a X.Y, Y>0 RELEASE is not very extensive, so
> you just as well could have tracked -STABLE.
>
> I'm sure you know how easy it is to upgrade a STABLE-running system, and
> there are simple ways in which that can be made to scale to thousands of
> machines. Breakage is of course a risk, but not significantly greater than
> for any other upgrading.

If we lose an rsync.net storage array, we'll get sued in 50 countries.
My family and I will be *fucked*, not to mention the thousands and
thousands of people, possibly ruined, around the globe.

Now let's explain to one of those folks (or a judge and jury) (or my wife
and kids) how the STABLE track works. Presumably they will refer us
directly to the FreeBSD projects home page, where they had found:

"This is still a development branch, however, and this means that at any
given time, the sources for FreeBSD-STABLE may or may not be suitable for
any particular purpose. It is simply another engineering development
track, NOT A RESOURCE FOR END-USERS."

>> of 2012, we should be on 6.12 (or so) and just breaking ground on 7.0.
>> Instead, each release gets perhaps two years of focused development
>> before every new fix is applied only to the upcoming release, and any
>> kind of support or enthusiasm from the community just disappears.
>
> If you're saying that -STABLE branches don't get fixes fast enough, I'd
> disagree.

I'm not saying that. I'm not a FreeBSD developer and I have little use
for either CURRENT or STABLE. I'm saying that I need a major release to
have an *effective* lifetime longer than two years.

Nobody runs the x.0, and these days the next major release comes in
concurrent with x.2 ... so that's x.1 and x.2 you get to use in a real
world, enterprise setting, before you have to either:

a) scrap that investment and start a new round of investment in the new
release (not trivial for a global firm)

b) begin limping along as a second class citizen, watching everything -
not just new features, but necessary bug fixes, go into the next major.


--john

[John Kozubik]

On Tue, 17 Jan 2012, Tom Evans wrote:

> On Tue, Jan 17, 2012 at 11:41 AM, Ivan Voras <ivo...@freebsd.org> wrote:
>> I've concluded very early that because of what I've said above, the only way
>> to run FreeBSD effectively is to track -STABLE. The developers MFC-ing stuff
>> usually try hard not to break things so -STABLE has become a sort of
>> "running RELEASE" branch. Since -STABLE is so ... stable ..., there is less
>> and less incentive to make proper releases (though I think nobody would mind
>> it happening).
>>
>> The next question is: what do releases from a -STABLE branch bring in that
>> simply tracking the original -STABLE tree doesn't? Lately, not very much.
>

> Sorry to just pick out bits of your email Ivan?

>
> Ability to use freebsd-update. It would be better to have more
> frequent releases. As a prime example, ZFS became much more stable
> about 3 months after 8.2 was released. If you were waiting for an 8.x
> release that supported that improved version of ZFS, you are still
> waiting.

Ding!

It's amazing how many people are in the exact same boats - waiting for
8.3, getting locked out of new motherboards because em(4) can't be
"backported" to even the production release...

> You say that snapshots of STABLE are stable and effectively a running
> release branch, so why can't more releases be made?
>
> Is the release process too complex for minor revisions, could that be
> improved to make it easier to have more releases, eg by not bundling
> ports packages?

Thanks, Tom. I'm calling for some changes that, culturally, might be
impossible, but a lot of pain would be avoided if more regular minor
releases (3 per year) were made.

[John Kozubik]

Hi Ivan,

Thanks for the insights below ... see my comments inline:

On Tue, 17 Jan 2012, Ivan Voras wrote:

>> Ability to use freebsd-update. It would be better to have more
>> frequent releases. As a prime example, ZFS became much more stable
>> about 3 months after 8.2 was released. If you were waiting for an 8.x
>> release that supported that improved version of ZFS, you are still
>> waiting.
>
> You know, that's an excellent point! And maybe an excellent idea: to
> provide occasional, time-based STABLE snapshots for freebsd-update.
>
>> You say that snapshots of STABLE are stable and effectively a running
>> release branch, so why can't more releases be made?
>
> Nobody volunteered :(

Fair enough. Is it the case that if funds or manpower were made
available, more releases would be workable ? Or are there some deeper
cultural leanings toward having fewer minor releases ?

>> Is the release process too complex for minor revisions, could that be
>> improved to make it easier to have more releases, eg by not bundling
>> ports packages?
>
> Almost certainly yes. The current release process involves src, ports
> and docs teams. Would you and other RELEASE users be happy with simple
> periodic snapshots off the STABLE branches, not much different from
> tracking STABLE? The only benefit I see would be a light-weight
> opportunity for testing which would probably end up being implemented
> by moving to date-based tags (e.g. if a critical bug is found and the
> fix MFC-ed, the "current" tag would be advanced to "$today")?

Well, as I tried to explain just previously in the thread, these need to
be real, bona fide releases. The notion of putting a few extra ones out
without updating the ports tree and docs is tempting, but I think it's the
wrong answer. Things should be kept simple and straightforward, and all
of the minor releases should be *real* releases.

Is three per year an insane schedule ? Remember, I am simultaneously
advocating that FreeBSD stop publishing two production releases
simultaneously, which is almost oxymoronic, so presumably there are
resources that get freed up there.

>> Can it really be that the best advice for users is to run their own
>> build infrastructure and make their own releases?
>
> Maybe. I'm trying to suggest that it looks like (I may be wrong, of
> course) that the effort required to upgrade from one RELEASE to the
> other is comparable to the effort of just having a -STABLE build
> machine somewhere and doing "make installkernel, make installworld,
> mergemaster -FU" over NFS on a 1000 machines. If you are serious about
> testing, you would need to test the RELEASEs also.

All very interesting - and honestly, things I will personally consider for
my home filers, pfsense boxes, etc. But no, none of my firms are going
into the OS business - even for ourselves.

[John Kozubik]

On Tue, 17 Jan 2012, Mark Felder wrote:

> Why is everyone so afraid of running -STABLE? Plenty of stuff gets MFC'd.
> Yeah, I agree -- running -RELEASE is difficult. Hell, it's frustrating to us
> that VMWare only supports -RELEASE and it took until ESX 5 to officially
> support 8.2!
>
> More releases / snapshots of -STABLE helps people on physical servers, but
> anyone who runs VMs on Xen or VMWare won't get any support for those versions
> because they didn't go through the QA process yet. FreeBSD is increasingly
> becoming a third world citizen thanks to virtualization efforts being focused
> on Linux, so I feel that more frequent releases won't help as many people as
> you think.

Again, I'm not suggesting more snapshots - I am suggesting more real, bona
fide releases. This will help people.

The fact that vmware only works with release software is consistent with
my own assertions. They (we) don't care what fancy toolchain and build
environments you have - we need things that we can defend to customers,
stockholders, judges, juries, etc.

[Julian Elischer]

On 1/16/12 10:20 PM, John Kozubik wrote:

>
>
> On Tue, 17 Jan 2012, Steven Hartland wrote:
>
>>> I was disappointed to see that 8.3-RELEASE is now slated to come
>>> out in March of 2012. This will be ~13 months since 8.2-RELEASE
>>> and is typical of a trend towards longer gaps between minor releases.
>>

>> ...
>>
>> I must say as a small company that runs ~200 machines on FreeBSD
>> I do see where John is coming from, as it is very time consuming to
>> keep
>> things up to date and new is not always better e.g. we still have
>> boxes
>> stuck on 6.x as issues introduced in the Linux compat after that
>> caused
>> problems.
>>
>> That said I'm in two minds as the features that have been brought
>> in by
>> the more rapid dev cycle like ZFS have been great.
>
>
> The features are great - nobody doesn't want the features! Like I
> said in the original post, as wonderful as ZFS on FreeBSD is (and we

> are deploying it this year) it is only now (well, in March) with 8.3
> that I feel it is finally safe and stable enough to bet the farm
> on. I'm not the only one that feels this way.
>

> If that's the case, then, ZFS could have been developed just as it
> has, in a development branch, and not been used as justification for
> (mutiple) major releases and all of their disruption.
but it would not have gotten the testing it did.

>
> As I said in the original post - we should be on 6.12 right now, and
> bringing out 7.0, with ZFS v28.

that was my feeling when we went to this "bring out a new major
release every 3 weeks" scheme.

We must however look at why Major and Minor releases are different.

A major release means that kernel ABIs (inside the system) have changed.

We needed to change the ABIs between 4 and 5 for sure (threaded
kernel) and
between 6 and 7 for sure, (second round of threading work).
7 and 8 also really required a change.
I'm not sure about 5-6 and 8-9.

[Julian Elischer]

On 1/16/12 10:29 PM, Atom Smasher wrote:
>
> so i guess that means that i'm tougher than a typical laptop user...
> and instead of making things easier, freeBSD is getting harder.
>
> thing is, when people don't "play" with freeBSD on laptops and
> desktops, then they grow up, get real jobs, and don't know much
> about it.
>
> if this keeps up, i'll cross a line where i just get more
> comfortable with linux and migrate my freeBSD servers to it.
>
> this is one of the areas where linux is doing well... people are
> "playing" with it, but in the process they're getting used to it and
> comfortable with it. from that background, they can install a linux
> based server without breaking a sweat. linux's ease of use and
> hardware support are seeding the next generation of FLOSS and *nix
> users... and most of them have never installed/used freeBSD.

have a play with PCBSD some time

[Julian Elischer]

On 1/17/12 10:08 AM, John Kozubik wrote:
>
> Hi Ivan,
>
>
[...]

>
> Fair enough. Is it the case that if funds or manpower were made
> available, more releases would be workable ? Or are there some
> deeper cultural leanings toward having fewer minor releases ?

sure

if you or someone is willing to cut releases, you can do so and I'm
sure re@, given the resources (not just promised them) could do
things differently.
re would probably love to have people employed by someone to do the
job :-)

[Julian Elischer]

On 1/17/12 7:39 AM, Mark Felder wrote:
> Why is everyone so afraid of running -STABLE? Plenty of stuff gets
> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
> frustrating to us that VMWare only supports -RELEASE and it took
> until ESX 5 to officially support 8.2!
>
> More releases / snapshots of -STABLE helps people on physical
> servers, but anyone who runs VMs on Xen or VMWare won't get any
> support for those versions because they didn't go through the QA
> process yet. FreeBSD is increasingly becoming a third world citizen
> thanks to virtualization efforts being focused on Linux, so I feel
> that more frequent releases won't help as many people as you think.

I'm going to go both ways on this one.

Where I used to work (Devin Teske is now there) we used to use
the 'stable' branch and rolll our own releases.
the criticality of those systems was hard to over-emphasize. In 2005
we worked
out we processed 1.5 trillion dollars of transactions on those systems.

The other side of the coin is that we had the resources to have
someone (me)
tracking the branch. I only spun a release when I thought it was a
good time to
do so, but I always had a year or so advance warning of when a new
release was
likely to be needed so I could select a good moment from over a wide
range.
Also ran a layer on the top of the sources where I could add
cherry-picked
back-ports and changes as part of our release.

If it came to that maybe all the people who are currently saying they
need better
support of the 8.x branch could get together and together, support
someone
to do that job for them..would 1/5th of a person be too expensive for
them?

if not, what is a reasonable cost? Is it worth 1/20 th of a person?


Julian

[Hugo Silva]

On 01/17/12 12:42, Ivan Voras wrote:
> On 17 January 2012 13:02, Tom Evans<teva...@googlemail.com> wrote:
> Almost certainly yes. The current release process involves src, ports
> and docs teams. Would you and other RELEASE users be happy with simple
> periodic snapshots off the STABLE branches, not much different from
> tracking STABLE? The only benefit I see would be a light-weight
> opportunity for testing which would probably end up being implemented
> by moving to date-based tags (e.g. if a critical bug is found and the
> fix MFC-ed, the "current" tag would be advanced to "$today")?

If (a cluster of) new features have made it to stable in the mean time
and have been tested and generally recognized as being in working
condition, my opinion is that a release should be up for consideration:


For starters, it's so much easier from a server management point of
view.. easier to memorize and compare 8.5-RELEASE vs 8.6-RELEASE ("now
with blah-ZFS features and cpuset added to rc.d, bind updated to blah,
openssh updated to version bleh, insert other usual suspects here") than
it is to track stable. I don't remember what was added to -STABLE 3
months ago. It doesn't appear to be as much of a good starting point
("good snapshot"), compared to a release either. I like to know where
I'm standing when setting up a new system, and a release is a convenient
starting point.


Also, one can always check what was added to a release on freebsd.org,
while for -stable some digging has to be performed.

For production servers, I'd rather run most servers with known good
release branches.

Sure, there were times when I needed something from the stable branch
and decided to use it, but when the next release comes out then it's
time to revert back to the release branch.

Come to think about it, those days are pretty much gone since 4.x
(incidentally, many of us who've stuck with FreeBSD for this long think
of 4.x as an epic series).


Running different -stable snapshots from different times results in
systems running different versions of the operating system, in my
opinion this is bound to bring problems (more stuff can go wrong).

It's so much easier to have a look at ganglia or cacti or clusterit or
anything similar and contrast the OS version and architecture. Running
-stable, not so much. Is it stable from 2 days ago or a year? And what
has changed since then?


Furthermore, releases get way more attention in freebsd's own webpage,
not to mention the cascading effect that has. You don't see a lot of
articles about new blah features on "9-stable snapshot dated Jan 17
2012", but there are many about 9.0-RELEASE being out in the street.
This also brings more visibility to the project.


Maybe I'm horribly mistaken about the releasographics of production
FreeBSD users, but I think most of us tend to run -release for the
reasons mentioned above, and perhaps some more that I'm neglecting right
now.

[Julian Elischer]

On 1/17/12 9:36 AM, Damien Fleuriot wrote:
>
> On 1/17/12 4:39 PM, Mark Felder wrote:
>> Why is everyone so afraid of running -STABLE? Plenty of stuff gets
>> MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
>> frustrating to us that VMWare only supports -RELEASE and it took until
>> ESX 5 to officially support 8.2!
>>
>> More releases / snapshots of -STABLE helps people on physical servers,
>> but anyone who runs VMs on Xen or VMWare won't get any support for those
>> versions because they didn't go through the QA process yet. FreeBSD is
>> increasingly becoming a third world citizen thanks to virtualization
>> efforts being focused on Linux, so I feel that more frequent releases
>> won't help as many people as you think.
>>
> Running FBSD in a *production* environment means you want something
> stable and tested.
>
> -STABLE does not fulfill the requirements I'm afraid.
>
> We've had to downgrade some boxes from 8.2-STABLE to -RELEASE here.

then you went the wrong way
and your process is flawed.

having run -stable on production systems, the way to do it is:

* follow -stable..
* pick a time that IN RETROSPECT (from 1 month later) looks as though
it was good.
* take a snapshot from that time and test it.
* if it has problems MOVE FORWARD (not back) to the next candidate
snapshot time.
* repeat until you have one that works for you

[Steven Hartland]

----- Original Message -----
From: "John Kozubik" <jo...@kozubik.com>

> It's amazing how many people are in the exact same boats - waiting for
> 8.3, getting locked out of new motherboards because em(4) can't be
> "backported" to even the production release...

This is not true, only last week did we take the version of e1000 from
HEAD into our 8.2-RELEASE tree as a patch. It wasnt totally trivial but
it also wasnt difficult either. But it would still be preferable for
many not to have to do this I assume?

This import brings the number of number release patches we manually apply
to our machines above 8.2-RELEASE to 18 which includes:-
updated areca driver, boot time fixes (disable memtest), devfs startup fix
ixgbe & e100 drivers, libz assembly crash fix, mps driver import, rc.subr
fix for scripts, increased max swap size, tcp reassembly fix, udp6 fix
for java, cam timeout fixes, zfs overflow fix, zfs slice boot delay,
camcontrol security options for ssds and jail uref panic fix.

I'm sure there are more that others would include but these changes are
important enough to our environment to prompt their inclusion in what
is effectively our own stream of 8.2-RELEASE.

Now I know the factastic work commiters do in bring us FreeBSD so
I can't bring myself to critisise in anyway the work they do. But its
defintiely interesting to see others are in the same boat as us looking
for something thats a bit more predicable than the current large change
releases.

I wonder if there is something that could be created to make maintaining
micro branches easier. I know mfsbsd has made our lives so much simpler
since we discovered it allowing us to take a standard source build on
one machine and roll an install cd customised to our requirements in
minutes.

What other undiscovered gems are our out there?

Regards
Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postm...@multiplay.co.uk.

[Hans Petter Selasky]

On Tuesday 17 January 2012 20:54:51 Steven Hartland wrote:
> boot time fixes (disable memtest),

Hi,

Another noticeable part is that ufsread.c in boot2 uses very small block sizes
to read the file system data. If that could be fixed boot times would drop too
!

--HPS

[Atom Smasher]

On Tue, 17 Jan 2012, Chris Rees wrote:

> > what percentage of linux devs are on salary to develop linux?
> >
>
> You're not comparing like with like.
>
> Linux is not an OS; FreeBSD is.
>
> Are you talking about Linux? Debian? Red Hat?

================

linux is, in fact, an operating system.

debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"Facts change from time to time."
-- Donald Rumsfeld

[Mark Felder]

On Tue, 17 Jan 2012 14:30:20 -0600, Atom Smasher <at...@smasher.org> wrote:

> linux is, in fact, an operating system.
> debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

It's not really worth getting into this argument, but I'll reiterate that
no, it's not an OS -- it's a kernel. Without the userland utilities the
distros provide it's not very usable. Linus and co don't maintain the
shell or the rc subsystem or anything like that. They only work on the
kernel and in-tree drivers. We need to be comparing FreeBSD to a full
blown distro.


Cheers

[Mark Saad]

Here are My 2 Cents ,

1. Support each release longer, or develop a better way to MFS ( Merge
from Stable ) bug fixes, and driver updates to RELEASE. It always
seams that there are a number of things in X-STABLE I would love to
have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE
just some new drivers and fixes .

2. Spell out the entire RELEASE road map at the beginning of the
release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc
.


--
mark saad | none...@longcount.org

[Mark Felder]

On Tue, 17 Jan 2012 12:59:44 -0600, Julian Elischer <jul...@freebsd.org>
wrote:

> On 1/17/12 9:36 AM, Damien Fleuriot wrote:
>
> having run -stable on production systems, the way to do it is:
>
> * follow -stable..
> * pick a time that IN RETROSPECT (from 1 month later) looks as though it
> was good.
> * take a snapshot from that time and test it.
> * if it has problems MOVE FORWARD (not back) to the next candidate
> snapshot time.
> * repeat until you have one that works for you
>

This is also the way I've had it explained to me. Note, I'm currently not
running anything -STABLE in production right now simply because I don't
have that need. I did for a while last year, but not now.

I'm deploying two ZFS SANs based on 9 early February. It might be on
-RELEASE with manual backports of the gmultipath rewrite (required) and
also I am considering the fixes for CDROM access (CAM stuff). I've seen
several other things hit -STABLE right after the freeze ended early
January which surprise me that they weren't included in -RELEASE and we
didn't have another RC. I definitely see the frustration being expressed
here, but I personally am comfortable running -STABLE. Many people are not
and it is unfortunate that they will be left waiting until 9.1-RELEASE
(probably late summer?). I hope a compromise will be found. I'm clearly in
the minority that is OK with the current situation.

To be fair, it could be worse -- OpenBSD secretly wants you to run
snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of
the most extreme security concerns. Even the packages are kept at the
exact version of the time of release.

Well to be honest, Theo doesn't want me running OpenBSD at all. :-)


-Previously Flamed User

[Chris Rees]

On 17 January 2012 20:30, Atom Smasher <at...@smasher.org> wrote:
> On Tue, 17 Jan 2012, Chris Rees wrote:
>
>> > what percentage of linux devs are on salary to develop linux?
>> >
>>
>> You're not comparing like with like.
>>
>> Linux is not an OS; FreeBSD is.
>>
>> Are you talking about Linux? Debian? Red Hat?
>
> ================
>
> linux is, in fact, an operating system.
>
> debian, red hat, ubuntu, gentoo, etc are distributions of that OS.

No. Linux is, in fact, not an operating system. It is a kernel.

You can't compare a *project* with a kernel.

You could compare a *distribution* with a project, hence my email.

Chris

[Warner Losh]

On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people.

I tend to agree with you. Our release engineering process isn't serving the needs of users as much as it once did. When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions. This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases. Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.

Today we have lost our way. We have no major vendor pushing the process along to make it happen faster. We have no reason to get things done faster or differently than the volunteers are doing it. So we're languishing. 9.0 took forever to get out, and we didn't do stop-gap 8.x releases. Our port collection has also gotten bigger since those by-gone days so doing a release of the whole ports tree is taking longer to QA, so pressure to do it more often meets up with resource constraints. Our binary update tools lag considerably compared to Linux, and there's a big reluctance to whole-heartedly embrace PBI as a possible solution. Maybe pkgng will help there. Maybe the various attempts to get ABI stability to allow for easier decoupling of FreeBSD base and FreeBSD ports releases.

But we have a real problem here. One I don't have easy answers for how to solve. One that likely has many other root-causes than the few I've cherry picked for this reply. The underlying balances that allowed the early project to succeed have shifted, but we've not shifted with them.

Warner

[Ian Lepore]

On Tue, 2012-01-17 at 10:56 -0800, Julian Elischer wrote:
> If it came to that maybe all the people who are currently saying they
> need better
> support of the 8.x branch could get together and together, support
> someone
> to do that job for them..would 1/5th of a person be too expensive
> for
> them?
>
> if not, what is a reasonable cost? Is it worth 1/20 th of a person?
>
>
> Julian
>

I've got to say, this strikes me as the most interesting idea floated so
far in this conversation. I've heard of many instances of sponsored
projects; they almost always involve major new features or support for
new hardware or technologies; paying someone for a specific small
focused fix is also common.

A sponsored branch is... well... just an interesting concept to me.

Unlike most developers, I have little interest in creating new code from
scratch to implement the fad of the week. (There's that whole other
opensource OS if fad of the week technology is your thing.) I live to
find and fix bugs. Sometimes that means days of frustration to generate
a one-line patch. Sometimes you find the problem in minutes but the fix
means a painful redesign that touches 342 files and has the potential to
ruin everyone's day when you get it wrong. But, for me at least, it's
much more challenging and thus more rewarding when you get it right.

Despite being a developer myself, I understand completely where John is
coming from in opening this conversation, and I'm firmly in the "me too"
camp because I'm also an end user of FreeBSD. I work at a company that
creates embedded systems products with FreeBSD as our OS.

In July we started the process of converting our products from 6.2 to
8.2. Out of sheer emergency necessity we shipped a product using 8.2 in
October -- 6.2 was panicking and the customer was screaming, we had no
choice; we've had to do several fix releases since then. It's only
within the past couple weeks that I think we're finally ready to deploy
8.2 for all new products. More testing is needed before updating
existing products in the field. It takes a long time for a business to
vet a major release of an OS and deploy it. It costs a lot.

Now, before we're even really completely up and running on 8.2 at work,
9.0 hits the street, and developers have moved on to working in the 10.0
world. What are the chances that any of the patches I've submitted for
bugs we fixed in 8.x are ever going to get commited now that 8 is well
on its way to becoming ancient history in developers' minds?

So back to where I started this rambling... that concept of a sponsored
branch, or maybe something along the lines of a long-lived stable branch
supported by a co-op of interested users. Some co-op members may be
able to provide developers or other engineering-related resources, some
may just pay cash to help acquire those resources for various short-term
or targeted needs along the way. I think it could work, and I think
businesses that need such stability might find it easier to contribute
something to a co-op than the current situation that requires a company
such as ours to become, in effect, our own little "FreeBSD Project
Lite" (if you think FreeBSD lacks manpower to do release engineering,
imagine how hard it is for a small or medium sized business).

-- Ian

[Mark Blackman]

On 17 Jan 2012, at 21:09, Warner Losh wrote:

>
> On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
>> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases. This will help people.
>
> I tend to agree with you. Our release engineering process isn't serving the needs of users as much as it once did. When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions. This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases. Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.
>
> Today we have lost our way. We have no major vendor pushing the process along to make it happen faster.

What exactly did the major vendor to push things along? Keep nagging?

I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any
case. The FreeBSD foundation seems less interested in the "for end-users" angle as well.

- Mark_______________________________________________

[Matt Olander]

On Tue, Jan 17, 2012 at 1:27 PM, Mark Blackman <ma...@exonetric.com> wrote:
> On 17 Jan 2012, at 21:09, Warner Losh wrote:
>
>>
>> On Jan 17, 2012, at 11:12 AM, John Kozubik wrote:
>>> Again, I'm not suggesting more snapshots - I am suggesting more real, bona fide releases.  This will help people.
>>
>> I tend to agree with you.  Our release engineering process isn't serving the needs of users as much as it once did.  When Walnut Creek was running release engineering, we had releases often because they wanted to make money from their subscriptions.  This produced reasonably spaced minor releases and except for 4-5, decently spaced major releases.  Even after the torch passed from walnut creek to others, there was still either residual pressures to make the releases happen, or inherited mindset that keep on the same pace.
>>
>> Today we have lost our way.  We have no major vendor pushing the process along to make it happen faster.
>
> What exactly did the major vendor to push things along? Keep nagging?
>
> I'd have thought PC-BSD and iXsystems are the natural people to to take over that role in any
> case.   The FreeBSD foundation seems  less interested in the "for end-users" angle as well.

We'd be happy to sponsor a full-time employee at the Mall to handle
rolling -STABLE into release a few more times per year. We might need
a bit of help maintaining a long term release but we think it's a
pretty good idea all the way around.

Cheers,
-matt

[Matthew D. Fuller]

On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of
Mark Felder, and lo! it spake thus:

>
> I've seen several other things hit -STABLE right after the freeze
> ended early January which surprise me that they weren't included in
> -RELEASE and we didn't have another RC.

You mean the 9.0-RELEASE that's scheduled to be done (after having
already slipped a month) at the beginning of Sept 2011? At some point
(well before those add'l patches you're talking about, IMO) you have
to STOP and release the damn thing already.


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[Matthew D. Fuller]

On Tue, Jan 17, 2012 at 12:02:29PM +0000 I heard the voice of
Tom Evans, and lo! it spake thus:

>
> You say that snapshots of STABLE are stable and effectively a
> running release branch, so why can't more releases be made?
>

> Is the release process too complex for minor revisions, could that
> be improved to make it easier to have more releases, eg by not
> bundling ports packages?

That's at LEAST a double edged sword. The moment you do that, you'll
have a giant groundswell of complaining about how the "quality of
releases" has gone down.

[Matthew D. Fuller]

On Tue, Jan 17, 2012 at 06:57:19PM +0000 I heard the voice of
Hugo Silva, and lo! it spake thus:

>
> Come to think about it, those days are pretty much gone since 4.x
> (incidentally, many of us who've stuck with FreeBSD for this long
> think of 4.x as an epic series).

Having been a FreeBSD user for a very long time, I don't think of 4.x
as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a
long time because everyone thought it was awesome, it was because the
next version was still so broken it was the only thing we had to
release.

And the reason it developed whatever excess "stability" it may have
had is _because_ it was moribund. It's trivial to avoid introducing
new bugs to software; all you have to do is never change it. The next
best thing is to make very small targetted changes with enormous care
to make them local. But that means you DON'T get things like new
drivers and infrastructure and so on, because those are just the sort
of big changes that are likely to create new problems even as they
solve existing ones. At some point aroudn X.4 or X.5 it stops being
-STABLE and starts just being -STALE.


For me, the smaller jumps between major releases are a *GOOD* thing,
because it makes it parsecs easier to move between them. Moving a
system from 4 to 5 was a giant nightmare of everything breaking. The
only thing I can remember worse was moving from 2.2 to 3 (and
actually, most of my 2.2 systems either stayed that way until they
died, or got moved via *HEROIC* efforts straight to 4).

In contrast, moving from 6->7->8 was only a slightly larger bump than
moving from 6.X to 6.Y. I have a specific system that I'm holding
back moving from 8 to 9 now because of a specific change, and I'm
sorta hoping I can retire that system before I have to try it. If we
went back to the days of mega-major's, that would happen *EVERY* time.


Now, there are some environments where upgrades are rare major events
and every single upgrade (possibly excluding those that can be
honestly described as "single targetted patch") requires a giant pile
of from-scratch requalification. And in those cases, it's almost the
same amount of work whether you're going from 4.6->4.7 as if you were
doing 4.10->9.1. From that perspective, sure, giant lengthenings may
sound like an excellent idea. But from the position of considering
upgrades as common and minor things, giant leaps are a nightmare I
want to avoid at all costs.

> Maybe I'm horribly mistaken about the releasographics of production

> FreeBSD users, but I think most of us tend to run -release [...]

I doubt it would be easy to get stats. But you could probably draw a
reasonable correlation between people using releases and binary
packages, vs. source and port builds. That would probably be easier
to get numbers on.

--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[Adrian Chadd]

On 16 January 2012 18:21, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:
> On 17 January 2012 01:02, richo <ri...@psych0tik.net> wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>
> Isn't this a bit of a cyclical argument: developers don't work because
> they are not paid a salary, the end-user base shrinks, BigCo doesn't
> want to pay for someone to put extra work in getting fBSD to do
> something that it can get elsewhere (eg Linux), fewer still developers
> work on fBSD, end-user base shrinks, BigCo is even more reluctant,
> even fewer....

Right, so some people need to stand up and actually push their agenda
forward by agreeing to take on (and then completing) contributions
towards the project that furthers their goals.

OP - if you'd like to see FreeBSD's stable release schedule pushed
forward a bit quicker then please, step up and offer to assist. No-one
is going to say no. Everyone will appreciate the extra help.



Adrian

[Adrian Chadd]

On 16 January 2012 22:32, Atom Smasher <at...@smasher.org> wrote:

> On Tue, 17 Jan 2012, richo wrote:
>
>> This would be a different argument if all the devs were paid a salary.
>

> ==============

>
> what percentage of linux devs are on salary to develop linux?

That's the wrong question.

The question is "what is a good minimum threshold for the number of
paid developers on ${PROJECT} (which is project-specific!) to create a
sustainable project, given the requirements of developers and users."

Then you see whether the number of developers meets this threshold.

[Mike Meyer]

On Tue, 17 Jan 2012 21:27:24 +0000
Mark Blackman <ma...@exonetric.com> wrote:
> I'd have thought PC-BSD and iXsystems are the natural people to to
> take over that role in any case. The FreeBSD foundation seems less
> interested in the "for end-users" angle as well.

If that's the case, is there any reason for cutting "FreeBSD"
releases?

No, I'm serious. If FreeBSD is being run by developers for developers
(first rule of organizations: they're run for the benefit of the
people who run them), how do they benefit from a release? If users
move to some other organizations releases, and the developers don't
get any benefit from them, why do them?

On a less radical note, how about taking in the resources suggested
for the "sponsored branch", and using those to reorganize and expand
the role of release engineering? Maybe get help from PC-BSD and
iXsystems as well?

Make STABLE the "sponsored" branch owned by the expanded RE group. To
justify this, change it to an "always production ready" approach. Set
up a CI system to test it regularly, and back out changes that break
the build or tests. This does *not* include testing ports or anything
else outside the base system.

RELEASES become a snapshot of the new "always production ready" STABLE
that has ports (and anything else included that's outside the base
system) built for it and tested on it. The goal is that doing the work
to keep STABLE production ready will significantly decrease the amount
of work required to do a release.

<mike

[Adrian Chadd]

. I'm replying to the OP because honestly, this thread has gotten a
bit derailed.

If you'd like to see:

.. more frequent releases? then please step up and help with all the
infrastructure needed to roll out test releases, including building
_all_ the ports. A lot of people keep forgetting that a "release" is
"build all the ports for all the supported platforms".

.. longer lifecycle? Then please step up and contribute patches for
features for your favourite branch. As a developer doing this in my
spare time I'm only really working on new features on -HEAD and maybe
backporting fixes to 9.x. What _I_ would like is someone to take on
the task of testing and backporting net80211/ath fixes to 8.x and 7.x.

.. longer branch lifecycle? Same as above. None of the developers are
going to reject bugfixes and backported drivers to a legacy, stable
branch. We may be a bit against the idea of porting entire new
subsystems to legacy, stable branches - but if there's a good enough
reason _and_ it's been tested _and_ there's a need for it - _I_
wouldn't say no.

If you care this much to comment on it, please consider caring enough
to step up and assist. Or, pay a company like ixSystems for FreeBSD
support and get them to do this for you. Otherwise you're just
re-iterating the same stuff I'm sure all the developers know but are
just out of manpower/time/money/resources to do anything about.



Adrian
(who _did_ step up and take over a subsystem, so I'm speaking from
recent experience.)

[Devin Teske]

> -----Original Message-----
> From: owner-free...@freebsd.org [mailto:owner-freebsd-
> hac...@freebsd.org] On Behalf Of Garrett Cooper
> Sent: Monday, January 16, 2012 4:07 PM
> To: WBen...@futurecis.com
> Cc: freebsd...@freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
>
> On Mon, Jan 16, 2012 at 3:32 PM, William Bentley <Wil...@futurecis.com>
> wrote:
> > I also echo John's sentiments here. Very excellent points made here.
> > Thank you for voicing your opinion. I was beginning to think I was the
> > only one who felt this way.
> >
> > I also have several FreeBSD installations spread across different
> > development/production systems and it is not feasible to always
> > upgrade to the latest and greatest. Part of why FreeBSD is difficult
> > to adopt into more of the commercial/government sectors is because of
> > this fast paced release cycle and most of the important patches/fixes
> > are not backported far enough. This is why most of my customers decide
> > to use Solaris or RedHat and not FreeBSD. (Not looking to start a
> > flame war about the OS choice/etc just pointing out the Release cycle
> > model). I would love to push FreeBSD harder but it is becoming
> > increasingly difficult as of late.
> >
> > We seem to have lost our way around the release of FreeBSD 7. I am all
> > in favor of new features but not at the risk of stability and proper
> > life cycle management.
> >
> > Are me and John the only people that feel this way or are we among the
> > minority?
>
> You aren't. There are other people like Devin Teske's group that feel the
same
> (they're upgrading from 4.x to 8.2! Brave man.. and godspeed to him),

Thanks!

Actually, we're jumping from 4.11 to 8.1 (not 8.2 -- reason as follows).

A lot of the problems we're having in 8.1 still exist in 8.2 (but will go-away
in 8.3, according to what we're seeing already-committed to RELENG_8 tag beyond
the RELENG_8_2_0_RELEASE tag -- that is, if 8.3 ever gets produced!). Therefore,
we've seen no need to push 8.2 (in-fact, we've internally black-listed it
because it doesn't fix anything we care about). So far, we've made over 10
patches to FreeBSD-8.1, and not a one of them would have been needed for 8.3,
but all of them would still be needed for 8.2.

I might add that we're doing an in-place binary migration from 4.11 to 8.1 using
a very sophisticated sh(1) script named "host_rebuild" which we'll be releasing
later this year. It allows binary migration both forwards, backwards, and even
stationary (re-installing the same OS, to either migrate architecture or simply
rebuild the OS).


> along with
> some development organizations that depend on long release cycles (IronPort,
> Isilon, etc).

I brought this up in last weekend's BAFUG meeting...

We're _very_ interested in replicating the long-lifecycle of the 4-series with a
newer series. But which one?

Right now, we're jumping to the 8-series, but after seeing that one of the major
focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
enable), I'm ready to say that the 9-series should instead be the "chosen
outlier" when it comes to picking one single release to have an ultra-wide
lifecycle.

The 9-series represents the first release to integrate a journaled filesystem
by-default into the system (aka boot) filesystem(s). We were pleasantly
surprised to see that the default installer enabled SU+J by-default when
choosing "guided" and "auto" for disk partitioning.

NOTE: We hated gjournal -- too clunky as a "bolt-on" solution. SU+J is a breath
of fresh-air as it's truly integrated into the filesystem and recognized at the
base FreeBSD level.
--
Devin


> That being said. More people, more likelihood to succeed with what you
need,
> like julian@ suggests. I like long release cycles too for stuff that I find
critical and
> "in production", like my router. My fileserver is a slightly different story,
but I just
> got off the CURRENT bandwagon off on to the 9-STABLE bandwagon :).
> Cheers,
> -Garrett

> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Igor Mozolevsky]

On 17 January 2012 23:01, Adrian Chadd <adr...@freebsd.org> wrote:

> If you'd like to see:
>

> ... more frequent releases? then please step up and help with all the

> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".

I don't know this so I'm asking: does fixing a port to work on a
pending release involve substantial changes (as in functionality cf.
cosmetic) to the "core" or just patching the port to work with the
core? If latter, maybe it's worthwhile uncoupling the two (core OS and
ports)?


--
Igor M. :-)

[Andriy Gapon]

on 17/01/2012 23:46 Ian Lepore said the following:

> Now, before we're even really completely up and running on 8.2 at work,
> 9.0 hits the street, and developers have moved on to working in the 10.0
> world. What are the chances that any of the patches I've submitted for
> bugs we fixed in 8.x are ever going to get commited now that 8 is well
> on its way to becoming ancient history in developers' minds?

My opinion is that this will have more to do with your approach to pushing the
patches (and your persistence) rather than with anything else. As long as
stable/8 is still a supported branch or the bugs are reproducible in any of the
supported branches.

--
Andriy Gapon

[Andriy Gapon]

on 18/01/2012 01:01 Adrian Chadd said the following:
> .. I'm replying to the OP because honestly, this thread has gotten a

> bit derailed.
>
> If you'd like to see:
>

> ... more frequent releases? then please step up and help with all the

> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".
>

> ... longer lifecycle? Then please step up and contribute patches for

> features for your favourite branch. As a developer doing this in my
> spare time I'm only really working on new features on -HEAD and maybe
> backporting fixes to 9.x. What _I_ would like is someone to take on
> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.
>

> ... longer branch lifecycle? Same as above. None of the developers are

> going to reject bugfixes and backported drivers to a legacy, stable
> branch. We may be a bit against the idea of porting entire new
> subsystems to legacy, stable branches - but if there's a good enough
> reason _and_ it's been tested _and_ there's a need for it - _I_
> wouldn't say no.

And another 2 cents from me: we also have this KPI/KBI stability policy for the
stable branches. So if anyone would like to have a "stable" branch but with
some super wanted/needed/requested change added, then that would be a bit harder
to arrange. I personally would call that a custom branch. And that of course
can also be done, even as an "official" custom branch, but interested people
would need either to take the job upon themselves or find (motivate, interest)
those who would the job for them.

> If you care this much to comment on it, please consider caring enough
> to step up and assist. Or, pay a company like ixSystems for FreeBSD
> support and get them to do this for you. Otherwise you're just
> re-iterating the same stuff I'm sure all the developers know but are
> just out of manpower/time/money/resources to do anything about.
>
>
>
> Adrian
> (who _did_ step up and take over a subsystem, so I'm speaking from
> recent experience.)

--
Andriy Gapon

[Dieter BSD]

Atom writes:
> i bought myself a LENOVO T510 when it first came out, around early 2010.
> it's got an i5 CPU and Arrandale GPU. it's two years old and on freeBSD i
> STILL can't run xorg properly with it.

I have a machine from 2005-08 that FreeBSD still doesn't support properly
in 2012. After much research I figured out that SATA NCQ was an essential
feature, and choose a mainboard with nforce4 to get it. FreeBSD still
doesn't support NCQ on nforce after all these years. Linux has had
NCQ on nforce4 since Oct 2006. FreeBSD also doesn't properly support
the onboard VIA firewire chip, which is still found on new mainboards
today. I don't necessarily expect support for every exotic chip out
there the first day they hit the street, but these are both popular
chips, and it is 6.5 years later. I'm not sure how an OS is supposed
to have "The power to serve" when it can't even talk to disks properly.
And all the device drivers that think it is ok to lollygag around
for absurd lengths of time with interrupts turned off, thus causing
data to be lost.

Damien writes:
> Check this PR I opened some months ago:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=161123&cat=kern
>
> It was planned for 9.0-RELEASE, there is no mention of 8.x
> That's just the kind of problem John raises here.

Hey, at least you have a fix, and it is even in a release (I'm
assuming it made it into 9.0). The bigger problem is all the
bugs that don't have fixes at all.

Igor writes:
> patches go ignored (no, I don't have a reference)

Here is a PR that contains a patch, yet is still open after
several years. Also fixes an even older PR from Dec 2006.
Dinky little patch, works great. Should be easy enough
to code inspect, test, and check in.
http://www.FreeBSD.org/cgi/query-pr.cgi?pr=127717&cat=

Mark writes:
> Why is everyone so afraid of running -STABLE?

Experience.

John writes:
> Is three per year an insane schedule ? Remember, I am simultaneously
> advocating that FreeBSD stop publishing two production releases
> simultaneously, which is almost oxymoronic

Why is publishing two production releases almost oxymoronic?
Seems like a very good policy to me. Say you are running 8.1.
It is good to have the choice of going to a low risk 8.2 with bugfixes
or going to 9.0 with some major new feature at the expense of more work
and higher risk. If you want the option of sticking with a major
release series (say 8.x) for a long time, then there needs to be at
least two production releases supported. As fast as major releases
are coming out, probably 3 or 4. Why are major releases coming out
so often? Gotta compete in the large number war. NetBSD was at
1.x for years and years, then suddenly someone decided to change
the numbering scheme and they're off to the races. Firefox has
caught the same insanity.

I see complaints from medium-to-large sites, yet FreeBSD's budget is
so small. Surely it must be possible for these medium-to-large sites
to pay into a fund to improve things. FreeBSD clearly needs more
developers to fix problems, to code review, test, and check in patches,
and to improve the documentation. Judging from this email thread there
is a demand for more/better release engineering and backporting as well.

[Ian Lepore]

On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
> on 17/01/2012 23:46 Ian Lepore said the following:
> > Now, before we're even really completely up and running on 8.2 at work,
> > 9.0 hits the street, and developers have moved on to working in the 10.0
> > world. What are the chances that any of the patches I've submitted for
> > bugs we fixed in 8.x are ever going to get commited now that 8 is well
> > on its way to becoming ancient history in developers' minds?
>
> My opinion is that this will have more to do with your approach to pushing the
> patches (and your persistence) rather than with anything else. As long as
> stable/8 is still a supported branch or the bugs are reproducible in any of the
> supported branches.

Well I submitted a sort of random sample of the patches we're
maintaining at work, 11 of them as formal PRs and 2 posted to the lists
here recently. So far two have been committed (the most important one
and the most trivial one, oddly enough). I'm not sure just how pushy
one is supposed to be, I don't want to be a jerk. Not to mention that I
wouldn't know who to push. That's actually why I'm now being active on
the mailing lists, I figured maybe patches will be more accepted from
someone the commiters know rather than just as code out of the blue
attached to a PR.

I think it would be great if there were some developers (a team, maybe
something not quite that formal) who concentrated on maintenance of
older code for the user base who needs it. I'd be happy to contribute
to that effort, both on my own time, and I have a commitment from
management at work to allow me a certain amount of billable work hours
to interface with the FreeBSD community, especially in terms of getting
our work contributed back to the project (both to help the project, and
to help us upgrade more easily in the future).

I have no idea if there are enough developers who'd be interested in
such a concept to make it work, co-op or otherwise. But I like the fact
that users and developers are talking about their various needs and
concerns without any degeneration into flame wars. It's cool that most
of the focus here is centered on how to make things better for everyone.

-- Ian

[Atom Smasher]

On Tue, 17 Jan 2012, Mark Felder wrote:

>> linux is, in fact, an operating system. debian, red hat, ubuntu,
>> gentoo, etc are distributions of that OS.
>
> It's not really worth getting into this argument, but I'll reiterate
> that no, it's not an OS -- it's a kernel. Without the userland utilities
> the distros provide it's not very usable. Linus and co don't maintain
> the shell or the rc subsystem or anything like that. They only work on
> the kernel and in-tree drivers. We need to be comparing FreeBSD to a
> full blown distro.

================

if it makes you feel better, then pick a distribution of linux, and
compare it's successes and/or failings to freeBSD.

whether or not linux is an OS or "just a kernel" is irrelevant here, but
at the same time an interesting distinction (and let's not debate it here,
just acknowledge that it's been pointed out) since freeBSD is both a
kernel and a collection of core utilities. in some ways freeBSD is like
the linux kernel, in other ways it's more like a distribution of linux.
would freeBSD benefit from breaking up those things into explicitly
different projects? like linux & GNU?

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"No matter how cynical you get,
it is impossible to keep up."
-- Lily Tomlin

[Doug Barton]

First, let's do away with the whole, "If you step up to help, your help
will be accepted with open arms" myth. That's only true if the project
leadership agrees with your goals.

We also need to take a step back and ask if throwing more person-hours
at the problem is the right solution, or if redesigning the system to
better meet the needs of the users *as a first step* is the right answer?

On 01/17/2012 15:01, Adrian Chadd wrote:
> .. I'm replying to the OP because honestly, this thread has gotten a

> bit derailed.
>
> If you'd like to see:
>

> ... more frequent releases? then please step up and help with all the

> infrastructure needed to roll out test releases, including building
> _all_ the ports. A lot of people keep forgetting that a "release" is
> "build all the ports for all the supported platforms".

Does it need to be? I've been pushing a long time now to have a branched
ports tree. If we have a "stable" version of the ports where only
known-good changes are promoted then that frees us up quite a bit to
redefine what a "release" is.

> ... longer lifecycle? Then please step up and contribute patches for

> features for your favourite branch. As a developer doing this in my
> spare time I'm only really working on new features on -HEAD and maybe
> backporting fixes to 9.x. What _I_ would like is someone to take on
> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.

So you want to do all the fun stuff, and have someone else do your scut
work? Good luck with that. :) Maybe what we need to do is redefine what
it means to be a FreeBSD committer. "From now on, your commit bit comes
with XYZ privileges, but also ABC responsibilities." Sure, we'd lose
some people, but what would we gain?

Also, your premise is flawed. We (speaking generally) suck at supporting
more than one -stable branch. We *really* suck at supporting three. Six
months ago when the machinery was just beginning to spin up for
9.0-RELEASE I tried to get the PTB to reconsider. I was told that my
concerns were invalid because it was basically ready to go as is.

The plan I laid out at the time was to have no more than 2 stable
branches extant at any given time. Lengthen the periods where each
stable branch is supported, and terminate the oldest one when the newest
one is released.

> ... longer branch lifecycle? Same as above. None of the developers are

> going to reject bugfixes and backported drivers to a legacy, stable
> branch. We may be a bit against the idea of porting entire new
> subsystems to legacy, stable branches - but if there's a good enough
> reason _and_ it's been tested _and_ there's a need for it - _I_
> wouldn't say no.

But committers already fail to MFC *existing* bug fixes to stable
branches (even ones they generated). This is especially true for the
older branches. So how is the idea of users generating more new bug
fixes going to help?

What I'd like to see us do is to rethink what a "release" is. In
particular, I'd like to see us start to do more point releases (e.g.,
8.2.1) which involve only updates to the base, and don't involve the
whole ports and doc machinery. This would combine the current patch
releases done for security purposes. Ideally of course we'd have a
branch were known-good stuff was merged from the -stable branch, so an
8.2.1 wouldn't (necessarily) be what's in stable/8 at the time. However
I'm not sure we have the personnel for that, so even doing stable/8 ->
8.2.N would be an improvement over what we have.

One area where user involvement *would* be really welcome here is in the
area of regression testing. It would be much easier to cut a point
release if we had a series of regression tests, submitted by users so as
to reflect real world conditions, that we could run against the new
version. That way we could at least be sure that we didn't break
anything that current users of that branch are relying on.

Several people have mentioned 3x/year as a good release schedule, I
don't see any reason why we couldn't do point releases in that timescale.

The other thing I think has been missing (as several have pointed out in
this thread already) is any sort of planning for what should be in the
next release. The current time-based release schedule is (in large part)
a reaction to the problems we had in getting 5.0 out the door. However I
think the pendulum has swung *way* too far in the wrong direction, such
that we are now afraid to put *any* kind of plan in place for fear that
it will cause the release schedule to slip. Aside from the obvious folly
in that (lack of) plan, it fails to take into account the fact that the
release schedules already slip, often comically far out into the future,
and that the results are often worse than they would have been otherwise.

Meta-note, there is going to be a strong knee-jerk reaction to that last
paragraph to the effect that I'm attacking individuals who are involved
in the release process. I'm not. The *system* is deeply flawed, so the
heroic efforts of those doing their best to make that system work are in
vain. That's tragic for all concerned, including those who've given so
generously of their time and effort.

I tried to make the point back in June that there was no reason to cut
9.0-RELEASE yet because we don't have solid support for clang in either
the base, or ports (amongst several other reasons) and that the delay
for getting that working would be a great "excuse" for slipping the
support schedule for 8 so that we could release 9.0 not-too-long before
7 was about to go EOL, and make the 8/9/10 release schedules fit the
new, (hopefully) more rational model. Perhaps we can reconsider that
idea for 10.0.


Doug

--

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

[John Kozubik]

Hi Devin,

On Tue, 17 Jan 2012, Devin Teske wrote:

> I brought this up in last weekend's BAFUG meeting...
>
> We're _very_ interested in replicating the long-lifecycle of the 4-series with a
> newer series. But which one?
>
> Right now, we're jumping to the 8-series, but after seeing that one of the major
> focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
> enable), I'm ready to say that the 9-series should instead be the "chosen
> outlier" when it comes to picking one single release to have an ultra-wide
> lifecycle.
>
> The 9-series represents the first release to integrate a journaled filesystem
> by-default into the system (aka boot) filesystem(s). We were pleasantly
> surprised to see that the default installer enabled SU+J by-default when
> choosing "guided" and "auto" for disk partitioning.

There's two parallel suggestions being put forth here, both of which are
interesting:

- Allow a related party to adopt a release (as I understand it) and
provide a sub-community taht donates resources to tending and updating
that release.

- Picking a "chosen" release to really dive into, officially, and polish
and extend it, like 4.

If I had to pick, I'd say the second one, but I'm not sure either one is
the right direction. I think a more sustainable, balanced approach that
can be extended for every release into the future would be best.

I don't really want to see some semi-official "fork", or "extended
release" - it would duplicate a lot of existing effort as well as raise
questions about how "official" it was. Would vmware support it as a real
release ? Large organizations might disqualify it the same way they would
STABLE.

As for picking 8 or 9 to be the "chosen" exception - that would help me a
lot in the short term, but if things are being done wrong, they should be
fixed in the long run.

I think the real choice that has to be made is "when will we halt
proclaiming two simultaneous releases as production ?" and since 9 is
already here, it can't be 8/9, it has to be 9/10. You could progress 8.x
along its current trajectory, possibly building 8.4 a year or so from now
and then be done with it, and then that would be the last short/unfocused
release.

Then you postpone 10.0-RELEASE until January 2017.

Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch.

Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle.

On Tue, 17 Jan 2012, Adrian Chadd wrote:

> OP - if you'd like to see FreeBSD's stable release schedule pushed
> forward a bit quicker then please, step up and offer to assist. No-one
> is going to say no. Everyone will appreciate the extra help.

I don't really know how much upheaval is implied in pushing 10.0 to 2017,
developing only one "production" release, and running 9.x up to 9.15 (or
whatever) but I can contribute USD $10k per year that this course was
followed, or $50k over five years. We can contribute some hardware,
hosting and bandwidth as well.

Are there any others here who can chip in, or whose firms can ?

[Mark Felder]

On Tue, 17 Jan 2012 16:25:12 -0600, Matthew D. Fuller
<full...@over-yonder.net> wrote:

> On Tue, Jan 17, 2012 at 02:50:08PM -0600 I heard the voice of
> Mark Felder, and lo! it spake thus:
>>
>> I've seen several other things hit -STABLE right after the freeze
>> ended early January which surprise me that they weren't included in
>> -RELEASE and we didn't have another RC.
>
> You mean the 9.0-RELEASE that's scheduled to be done (after having
> already slipped a month) at the beginning of Sept 2011? At some point
> (well before those add'l patches you're talking about, IMO) you have
> to STOP and release the damn thing already.
>
>

Yeah, but how much sense does it make to do a -RELEASE with critical bugs?
For example, gmultipath guarantees a panic on various hardware just by
breaking a path. This was fixed in a full rewrite discussed this summer
and publicized in November. Now anyone with shiny 9.0 (or even 8.2)
running gmultipath risks a panic. The fix IS the rewrite. But it's s total
rewrite and so patching that onto 9.0 as errata doesn't really make sense
(rewrite adds features too), so now the choices for a stable gmultipath is
-STABLE or patiently waiting for 9.1.

So yeah, 9.0 slipped hard. Perhaps it should have slipped a bit further
until blockers like gmultipath and the cdrom/CAM stuff were fully
addressed. But it's impossible to release 100% bug free software.... where
exactly *do* you draw the line? :-/

I certainly would not be better than anyone else at managing any portion
of this project. I'm just glad I have the ability to find and apply fixes
myself when necessary.

[John Kozubik]

Hi Doug,

Thanks a lot for these comments and insight - response below...

On Tue, 17 Jan 2012, Doug Barton wrote:

> I tried to make the point back in June that there was no reason to cut
> 9.0-RELEASE yet because we don't have solid support for clang in either
> the base, or ports (amongst several other reasons) and that the delay
> for getting that working would be a great "excuse" for slipping the
> support schedule for 8 so that we could release 9.0 not-too-long before
> 7 was about to go EOL, and make the 8/9/10 release schedules fit the
> new, (hopefully) more rational model. Perhaps we can reconsider that
> idea for 10.0.

Just previously in this thread, I suggested the following:


<quote>

You could progress 8.x along its current trajectory, possibly
building 8.4 a year or so from now and then be done with it, and then that
would be the last short/unfocused release.

Then you postpone 10.0-RELEASE until January 2017.

Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch.

Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle.

</quote>


I wonder if this is too aggressive in that direction, or if this would be
a decent balance ?

[Andriy Gapon]

on 18/01/2012 01:36 Ian Lepore said the following:

> On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
>> on 17/01/2012 23:46 Ian Lepore said the following:
>>> Now, before we're even really completely up and running on 8.2 at work,
>>> 9.0 hits the street, and developers have moved on to working in the 10.0
>>> world. What are the chances that any of the patches I've submitted for
>>> bugs we fixed in 8.x are ever going to get commited now that 8 is well
>>> on its way to becoming ancient history in developers' minds?
>>
>> My opinion is that this will have more to do with your approach to pushing the
>> patches (and your persistence) rather than with anything else. As long as
>> stable/8 is still a supported branch or the bugs are reproducible in any of the
>> supported branches.
>
> Well I submitted a sort of random sample of the patches we're
> maintaining at work, 11 of them as formal PRs and 2 posted to the lists
> here recently.

Just a note: the next best thing you can to _not_ have a patch committed is to
just open a PR and stop at that. The best thing being not sharing the patch at
all :-)

> So far two have been committed (the most important one
> and the most trivial one, oddly enough). I'm not sure just how pushy
> one is supposed to be, I don't want to be a jerk.

Some things that help:
- send a problem description and a patch (or a short description and a link to a
PR) to a relevant mailing list
- maintain a discussion of the patch if it arises
- try to be interesting and keep the interested folks hooked
- find some folks who recently committed stuff in the area of the patch and
contact them directly
- don't just wait for too long, remind about yourself and the patch, try
different mailing lists/people
- never give up
- stay technical, never get bitter or overly emotional
- don't refuse when offered a commit bit :-)

> Not to mention that I
> wouldn't know who to push. That's actually why I'm now being active on
> the mailing lists, I figured maybe patches will be more accepted from
> someone the commiters know rather than just as code out of the blue
> attached to a PR.

That helps. And, as I've said above, being pro-active about the patches helps too.

> I think it would be great if there were some developers (a team, maybe
> something not quite that formal) who concentrated on maintenance of
> older code for the user base who needs it.

Yes, it would be great if some current developers found themselves
interested/motivated to do that kind of work. Or if some new developers joined
the ranks to do the job.

> I'd be happy to contribute
> to that effort, both on my own time, and I have a commitment from
> management at work to allow me a certain amount of billable work hours
> to interface with the FreeBSD community, especially in terms of getting
> our work contributed back to the project (both to help the project, and
> to help us upgrade more easily in the future).

That sounds great! I am sure that this approach will be productive.

> I have no idea if there are enough developers who'd be interested in
> such a concept to make it work, co-op or otherwise. But I like the fact
> that users and developers are talking about their various needs and
> concerns without any degeneration into flame wars. It's cool that most
> of the focus here is centered on how to make things better for everyone.


--

Andriy Gapon

[Daniel Eischen]

On Tue, 17 Jan 2012, Igor Mozolevsky wrote:

> On 17 January 2012 23:01, Adrian Chadd <adr...@freebsd.org> wrote:
>
>> If you'd like to see:
>>
>> ... more frequent releases? then please step up and help with all the
>> infrastructure needed to roll out test releases, including building
>> _all_ the ports. A lot of people keep forgetting that a "release" is
>> "build all the ports for all the supported platforms".
>
> I don't know this so I'm asking: does fixing a port to work on a
> pending release involve substantial changes (as in functionality cf.
> cosmetic) to the "core" or just patching the port to work with the
> core? If latter, maybe it's worthwhile uncoupling the two (core OS and
> ports)?

IMHO, the two are already uncoupled too much. The problem I have
with ports is that there is not a -stable branch that tracks with
-stable core. I don't need the latest and greatest ports, just
security and bug fixes. It doesn't even have to be every port,
just the commonly used ports. There's not enough man power for
this, unfortunately, but I'm still happy that at least we _do_
have _a_ ports system :-)

--
DE

[Igor Mozolevsky]

On 18 January 2012 00:00, Andriy Gapon <a...@freebsd.org> wrote:

> Just a note: the next best thing you can to _not_ have a patch committed is to
> just open a PR and stop at that.  The best thing being not sharing the patch at
> all :-)

[snip]

> Some things that help:
> - send a problem description and a patch (or a short description and a link to a
> PR) to a relevant mailing list
> - maintain a discussion of the patch if it arises
> - try to be interesting and keep the interested folks hooked
> - find some folks who recently committed stuff in the area of the patch and
> contact them directly
> - don't just wait for too long, remind about yourself and the patch, try
> different mailing lists/people
> - never give up
> - stay technical, never get bitter or overly emotional
> - don't refuse when offered a commit bit :-)

Seriously, WTF is the point of having a PR system that allows patches
to be submitted??! When I submit a patch I fix *your* code (not yours
personally, but you get my gist). No other project requires a
non-committer to be so ridiculously persistent in order to get a patch
through.

Such system is plainly wrong---it simply discourages people from
sending "this works for me"(TM) fixes. The committers have to realise
three things: they can and do write broken code now and then, most
people who write patches to help the fBSD along don't have the time to
become full time committers (otherwise they'd already be, right?), and
there's only so many times one is willing to bang their head against a
wall with no results---as Einstein pointed out "Insanity: doing the
same thing over and over again and expecting different results"...

I'm not saying that responding to reasonable requests from people who
are in the process of testing and committing the patch, but expecting
the end-users to chase committers to have a fix included is plainly
wrong!..


--
Igor M.

[Devin Teske]

> -----Original Message-----
> From: owner-free...@freebsd.org [mailto:owner-freebsd-
> hac...@freebsd.org] On Behalf Of Julian Elischer
> Sent: Tuesday, January 17, 2012 10:56 AM
> To: Mark Felder
> Cc: freebsd...@freebsd.org
> Subject: Re: FreeBSD has serious problems with focus, longevity, and lifecycle
>

> On 1/17/12 7:39 AM, Mark Felder wrote:
> > Why is everyone so afraid of running -STABLE? Plenty of stuff gets
> > MFC'd. Yeah, I agree -- running -RELEASE is difficult. Hell, it's
> > frustrating to us that VMWare only supports -RELEASE and it took until
> > ESX 5 to officially support 8.2!
> >
> > More releases / snapshots of -STABLE helps people on physical servers,
> > but anyone who runs VMs on Xen or VMWare won't get any support for
> > those versions because they didn't go through the QA process yet.
> > FreeBSD is increasingly becoming a third world citizen thanks to
> > virtualization efforts being focused on Linux, so I feel that more
> > frequent releases won't help as many people as you think.
>
> I'm going to go both ways on this one.
>
> Where I used to work (Devin Teske is now there) we used to use the 'stable'
> branch and rolll our own releases.

We still do this today, but have only further enhanced the procedure.

Within FreeBSD announcing a new release, we can be ready to ship said-release within 3-6 weeks.

However, that's not to say that our customers can take said-new-release every 3-6 weeks. Our largest customer is not-surprisingly the fastest at turn-around but at-best could only do maybe 2 releases at-most in a single year. Our smaller customers are taking OS upgrades much slower (every-other year if we're lucky; more like once every 3 years).

For both our large and small customers, we actively back-port device support in-accordance with hardware manufacturing windows.

This is to explain that our hardware suppliers notify us ahead-of time when a particular piece of hardware is about to become unavailable. At that time we are usually given a choice of hardware to evaluate as replacements for the existing EOM production-line.

We're usually given at least 3-9 months prior-notice before our current production-line goes EOL.

For each candidate replacement we try each FreeBSD release that we're currently using in production. If it doesn't work, we try another candidate hardware. If we can't seem to find a winning combo that works with our existing -RELEASE, we then start trying newer releases until we find drivers working for each/every required piece of hardware (network cards, RAID cards, serial ports/cards, Adaptec SCSI cards, Fibre HBAs, etc.). When we find a release that contains the necessary drivers, we back-port.

At this time, it's worth noting that we use ONLY monolithic kernels and we deliver them via packages. When we back-port new device support, we just roll a new kernel, ship it via package, pkg_add, reboot.

Similarly, if the patch is in userland, we package up the replaced binaries (produced by using the release engineering procedures documented in build(7) and [more importantly] release(7)).

The net effect is that we run a -RELEASE with patches from either the same -STABLE, a higher -RELEASE, higher -STABLE, or (as a last-resort) -CURRENT or HEAD. We've been known to roll FreeBSD-4.11 kernels with bits back-ported from RELENG_8.

So, I guess what I’m trying to say is that if you're going to take your production environment extremely seriously (as though 1.5-Trillion globally-economic-dollars depended on it) you-too would take a serious look at release(7) and the Release Engineer's handbook.

It really is worth maintaining your own release, taking required fixes from -STABLE (preferred) or higher (as necessary) to satisfy your customers (which are nearly almost always going to have a different release schedule than that-of any OS, be-it FreeBSD, Linux, or other distribution).


> the criticality of those systems was hard to over-emphasize. In 2005 we worked
> out we processed 1.5 trillion dollars of transactions on those systems.
>

I'm going to have to sit down with DaveR, JPL, and others to get an updated metric for 2011. I'd be willing to bet that we've increased transactional load over the years (with respect to FreeBSD, we brought on one new sizable customer since then and expanded the scope of existing FreeBSD customers to new overseas installations as well as several new sites in the States).



> The other side of the coin is that we had the resources to have someone (me)
> tracking the branch.

That person is now (me) plus I have Dave Robison (DaveR) to lean on occasionally (and you're always a great help, DaveR).

I'd argue that it's not the man-power... it's whether management sees the importance in allowing one (or two) persons to spin his/her wheels, developing a laudable solution to the problem at-hand (precisely what we've done; mitigating extra/busy work).

However, sometimes you just have to take initiative. The company didn't really officially "approve" any project that involved re-architecting our internal release engineering ... I had to take it upon myself over the last 3.5 years to do said monster-undertaking (in my ``spare'' time).



> I only spun a release when I thought it was a good time to do
> so, but I always had a year or so advance warning of when a new release was
> likely to be needed so I could select a good moment from over a wide range.

Likewise!

When Julian was here, the company had the same top-executives (such as Cayford), and likewise, I too have the same guidance.

If/When we ever find ourselves in the boat of our deployed release not supporting some hardware we ask ourselves three things:

1. Can we supplant missing support by making an out-of-band purchase of older hardware? (e.g. an onboard network card doesn't work, so we'll just throw an Intel PRO/100 PCI card into one of the extra slots)

2. Can we back-port missing driver support?

NOTE: I then go do research to answer yes/no.

3. How hard is it to back-port missing support if above-answer is YES?

NOTE: I then look at how hard it is which takes many things into consideration.

4. Is answer to above "days", "weeks", or "fat-chance"?

5. If answer to above is "days", I'm often instructed to do the back-port.

6. If answer is instead "weeks", we way our other options, including...

7. Can we "pre-ship" a newer OS having tested that it "plays-well with others" (in a heterogeneous environment)(example: shipping 8.1 workstations but still using a 4.11 server stack because workstations require better Vid-card support but servers do not).

8. Can we find another supplier that has the ability to source older hardware?

9. Failing any/all "easy" solutions, we then make a blanket statement that "it's time to move our customers to the next release" in which we then start enroads to regression test our product on said newer release as all other tricks to stay on the current release won't work.

It is through the above procedure that we accommodate customers that may or may-not have the annual budget to either:

a. do a "tech refresh" and/or

b. update the OS

in concordance to abate both EOM and EOL timelines dictated by hardware manufacturers (which we can only hope to influence even with *our* sizeable purchasing power; NOTE: We simply can't influence manufacturers like Google, Microsoft, Apple, etc. can).


> Also ran a layer on the top of the sources where I could add cherry-picked back-
> ports and changes as part of our release.
>

Yup, we've maintained that ability to this day. It's the only thing that's saved us. In transitioning to 8.1 we've already cherry-picked 8 patches in-wholesale from RELENG_8.

> If it came to that maybe all the people who are currently saying they need better
> support of the 8.x branch could get together and together, support someone to
> do that job for them..would 1/5th of a person be too expensive for them?
>
> if not, what is a reasonable cost? Is it worth 1/20 th of a person?
>

An interesting thought. Open to discussion on this one (meaning: I'm willing to volunteer).
--
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Steven Hartland]

----- Original Message -----
From: "Hans Petter Selasky" <hsel...@c2i.net>


> On Tuesday 17 January 2012 20:54:51 Steven Hartland wrote:
>> boot time fixes (disable memtest),
>
> Hi,
>
> Another noticeable part is that ufsread.c in boot2 uses very small block sizes
> to read the file system data. If that could be fixed boot times would drop too
> !

It might but not the same order of magnitude I suspect
as this was like 30-60+ delay depending on memory size ;-)

Regards
Steve

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to postm...@multiplay.co.uk.

[Eitan Adler]

On Tue, Jan 17, 2012 at 7:16 PM, Igor Mozolevsky <ig...@hybrid-lab.co.uk> wrote:

> Seriously, WTF is the point of having a PR system that allows patches
> to be submitted??! When I submit a patch I fix *your* code (not yours
> personally, but you get my gist). No other project requires a
> non-committer to be so ridiculously persistent in order to get a patch
> through.

It takes time to review and test patches. There are a lot of people
that think "it only takes 30 seconds to download the patch, apply, and
commit." This is just not true.

When I take PRs committers
1) Download the PR
2) Read the surrounding code sufficiently to understand what it does
3) Read the patched code to find the bug
4) Read the patch to see if it fixes the bug
5) Ensure that it is the most appropriate way to fix the bug
6) Apply the patch and test the affected issue.
7) Find the person who wrote the original code (or at least one other
person) and have them review it
- this person usually goes through steps 1-6 too.
8) Apply the patch to head and commit
9) Verify the changes are correct didn't cause any regressions
10) MFC to stable[789]

And this assumes the patch was perfect, there really was a bug, and
everyone thinks things through properly. The process take anywhere
from half an hour for obvious fixes to multiple days in addition to
the committer's work, school, and family obligations..

Being persistent sometimes gives the committer the motivation to go
through all those steps. As a part of the "bugbusting" team I've
taken quite a few bugs and been the "annoying persistent" person for
other people. As a result I've closed quite a few bugs.

> Such system is plainly wrong---it simply discourages people from
> sending "this works for me"(TM) fixes.

Yes and no. The system is bad, it shouldn't take 5 years to commit a
correct patch, but at the same time "this works for me patches" still
need to go through all of the above.

> The committers have to realise
> three things: they can and do write broken code now and then, most
> people who write patches to help the fBSD along don't have the time to
> become full time committers (otherwise they'd already be, right?), and
> there's only so many times one is willing to bang their head against a
> wall with no results---as Einstein pointed out "Insanity: doing the
> same thing over and over again and expecting different results"...

And we need to work to find ways to fix issues while still ensuring
that the above steps are followed.

> I'm not saying that responding to reasonable requests from people who
> are in the process of testing and committing the patch, but expecting
> the end-users to chase committers to have a fix included is plainly
> wrong!..

I agree, and we need to work to find systematic solutions to correct
patches waiting for someone to take a look without compromising the
quality checks committers (should) do.

If you have ideas to make this process easier or more efficient we are
all eager to hear them. I am especially interested to know what *I*
could do to help speed things along in areas I don't know well enough
to commit to.

--
Eitan Adler

[Devin Teske]

Hi John,

I too am not sure. The latter (pick a "chosen" release) option seems a good
route, but like you say, maybe a re-envisioning of the release procedure is
what's needed for long-term.

> I think a more sustainable, balanced approach that can be extended
> for every release into the future would be best.
>
> I don't really want to see some semi-official "fork", or "extended release" -
it
> would duplicate a lot of existing effort as well as raise questions about how
> "official" it was. Would vmware support it as a real release ? Large
organizations
> might disqualify it the same way they would STABLE.
>
> As for picking 8 or 9 to be the "chosen" exception - that would help me a lot
in the
> short term, but if things are being done wrong, they should be fixed in the
long
> run.
>
> I think the real choice that has to be made is "when will we halt proclaiming
two
> simultaneous releases as production ?" and since 9 is already here, it can't
be 8/9,
> it has to be 9/10. You could progress 8.x along its current trajectory,
possibly
> building 8.4 a year or so from now and then be done with it, and then that
would
> be the last short/unfocused release.
>

I often have to deal with "FUD" at work, especially when the developers learn
that FreeBSD has, for example, released FreeBSD 9.0 somewhat indicating that
"oh, no -- we're obsolete?!"

In which I've always had to then explain how "FreeBSD has three versions running
simultaneously at all times -- a legacy release, a stable release, and a future
release," and they are happy with such an explanation.

I usually then go on to explain "back in the day it was 4/5/6, and now it's
8/9/10". Naturally, this is an over-simplified view of the situation, but it
sure would be a nice view if it were absolutely true.

There ought to be a charter that explicitly defines the types of things you can
expect from each release (regardless of which release):

For example, the "legacy" release (which might as well be 8.x now) should:
a. Receive all security patches until deprecated
b. Receive critical bug fixes until deprecated
c. Benefit from trivial hardware device additions (e.g., developer adds "0x10de"
device identifier to if_bgereg.h to add new hardware support to bge(4))

Meanwhile, the "stable" release (which might as well be 9.x now) should:
a. Receive all security patches
b. Receive critical bug fixes
c. Benefit from ALL hardware device changes except experimental ones and those
that completely redesign the driver

Last, the "current" release (which might as well be 10.x now) should:
a. Be the landing zone for all new code, experimental or otherwise.

Finally, the charter ought to also define when a "current" can become "stable"
.. not define some arbitrary timeline which results in situations like that
which was previously mentioned in this thread (9.0 shipped as stable release
with completely broken gmultipath).

> Then you postpone 10.0-RELEASE until January 2017.
>
> Instead of having a legacy branch and two production branches, you would have
> legacy (8) production (9) and ... nothing. Or if you need to have it out
there, 10 is
> the development branch.
>

+1

> Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15 at
the
> end of the cycle.
>

Ought we to have one timeline for stable (aka production) and a different
timeline for legacy?

Say, cut a new release in legacy 1-2 times a year and cut a new release in
production 2-3 times a year?

Just an idea.

> On Tue, 17 Jan 2012, Adrian Chadd wrote:
>
> > OP - if you'd like to see FreeBSD's stable release schedule pushed
> > forward a bit quicker then please, step up and offer to assist. No-one
> > is going to say no. Everyone will appreciate the extra help.
>
>
> I don't really know how much upheaval is implied in pushing 10.0 to 2017,
> developing only one "production" release, and running 9.x up to 9.15 (or
> whatever) but I can contribute USD $10k per year that this course was
> followed, or $50k over five years. We can contribute some hardware,
> hosting and bandwidth as well.
>
> Are there any others here who can chip in, or whose firms can ?

Our firm has chipped in (significantly) in the past, and I'm starting to think
it's 'bout time we do it again. But if we're going to do so, we would want
written statements as to what we're paying for.

I think it's worth opening the discussion to all potential investors to see: if
money were thrown at the problem, what could be achieved? what would the charter
look like? is there even enough like-minded investors that a consensus could be
reached for a common goal?
--
Devin

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Igor Mozolevsky]

On 18 January 2012 01:11, Eitan Adler <li...@eitanadler.com> wrote:

> It takes time to review and test patches. There are a lot of people
> that think "it only takes 30 seconds to download the patch, apply, and
> commit."  This is just not true.

I fully understand that and it is not what I was saying, what I was
saying was about the patches that were being plainly ignored/allowed
to go stale. What you said below is perfectly reasonable once a
committer is actively involved in dealing with a patch, then I, and
anyone else for that matter, would be very reasonably expected to be
involved in the process and understands that someone else is working
on the issue you've address. The problem, however, lies in the time
between a patch is submitted and is "picked up", if the latter ever
occurs!.. That is where the discouragement occurs.

[snip]

> And this assumes the patch was perfect, there really was a bug, and
> everyone thinks things through properly.  The process take anywhere
> from half an hour for obvious fixes to multiple days  in addition to
> the committer's work, school, and family obligations..

I hope I've address what you say here just above :-) and
wholeheartedly agree with everything else you've said, but you are
addressing the problem from a different angle: nobody is ever going to
disagree that _once_ someone has picked up a patch it will take them
time to get it through whatever steps necessary. But, as I said above,
it's getting to *this* stage that is the lengthy and a disheartening
process...

[snip]

> If you have ideas to make this process easier or more efficient we are
> all eager to hear them. I am especially interested to know what *I*
> could do to help speed things along in areas I don't know well enough
> to commit to.

The problem, which I suspect is very difficult to overcome in what I
call the "bazaar" environment, is the enforcement. One way to
"encourage" people to fix their code would be to prevent them from
committing to -CURRENT once they pass a certain threshold of
"unattended" patches. Of course then, committers will be whinging that
they'd be resigning if they can't commit to -CURRENT, but quite
frankly, why should anyone have the commit privilege if they can't be
bothered to address the bugs, are those people just using the FreeBSD
project to boost their CV (with great powers comes great
responsibility!)?


--
Igor M. :-)

[Julian Elischer]

On 1/17/12 12:11 PM, Mark Saad wrote:
> Here are My 2 Cents ,
>
> 1. Support each release longer, or develop a better way to MFS ( Merge
> from Stable ) bug fixes, and driver updates to RELEASE. It always
> seams that there are a number of things in X-STABLE I would love to
> have in X.3-RELEASE and X.4-RELEASE, and I do not want all of X-STABLE
> just some new drivers and fixes .
>
> 2. Spell out the entire RELEASE road map at the beginning of the
> release. So for 9.0-RELEASE set tentative dates for 9.1, 9.2, 9.x etc
> .

I think by the ".2" release of a line we should have some idea
as to whether a particular lineage is going to provide a good basis
for extended life.

if for example we were to declare that 8 is really quite good,
we might decide to declare it as having a longer life and allow 9 to
die earlier as we go forward.
I do understand the requirement for a stable basis for work but I
can not say how many of the changes for newer hardware will get ported
back. or by who.

[Julian Elischer]

On 1/17/12 3:36 PM, Ian Lepore wrote:
> On Wed, 2012-01-18 at 01:17 +0200, Andriy Gapon wrote:
>> on 17/01/2012 23:46 Ian Lepore said the following:
>>> Now, before we're even really completely up and running on 8.2 at work,
>>> 9.0 hits the street, and developers have moved on to working in the 10.0
>>> world. What are the chances that any of the patches I've submitted for
>>> bugs we fixed in 8.x are ever going to get commited now that 8 is well
>>> on its way to becoming ancient history in developers' minds?
>> My opinion is that this will have more to do with your approach to pushing the
>> patches (and your persistence) rather than with anything else. As long as
>> stable/8 is still a supported branch or the bugs are reproducible in any of the
>> supported branches.
> Well I submitted a sort of random sample of the patches we're
> maintaining at work, 11 of them as formal PRs and 2 posted to the lists
> here recently. So far two have been committed (the most important one
> and the most trivial one, oddly enough). I'm not sure just how pushy
> one is supposed to be, I don't want to be a jerk. Not to mention that I
> wouldn't know who to push. That's actually why I'm now being active on
> the mailing lists, I figured maybe patches will be more accepted from
> someone the commiters know rather than just as code out of the blue
> attached to a PR.

you are supposed to be as pushy as you need to be..
If you really want your patches in I'd suggest teh following method:

1/ post a summary email explaining all teh bugs and patches
2/ see if anyone takes them up
3/ for the remaining problems, find the names of developers who
have committed to that code and contact them asking for their assistance.
4/ report back here ;-)

[Julian Elischer]

On 1/17/12 2:41 PM, Matthew D. Fuller wrote:
> On Tue, Jan 17, 2012 at 06:57:19PM +0000 I heard the voice of
> Hugo Silva, and lo! it spake thus:
>> Come to think about it, those days are pretty much gone since 4.x
>> (incidentally, many of us who've stuck with FreeBSD for this long
>> think of 4.x as an epic series).
> Having been a FreeBSD user for a very long time, I don't think of 4.x
> as epic. I think of 5.x as a clusterf...un. 4.x didn't last such a
> long time because everyone thought it was awesome, it was because the
> next version was still so broken it was the only thing we had to
> release.
>
5 was not out on a limb for so long because it was a clusterfun, it was
out there because it was a rework of how almost everything in the
kernel worked. Everything written since 1978 had to be rewritten
to some extent.

[Matthew D. Fuller]

On Wed, Jan 18, 2012 at 01:41:53AM +0000 I heard the voice of
Igor Mozolevsky, and lo! it spake thus:

>
> The problem, however, lies in the time between a patch is submitted
> and is "picked up", if the latter ever occurs!.. That is where the
> discouragement occurs.

Quite. For instance, we're now well past the 3 year mark since I
submitted docs/127908, which fixes 1 sentence in a manpage. So far, I
can't see that anybody but me has ever looked at it. That doesn't
serve to encourage me to nibble at anything substantial.


(In fairness, I should note that I also maintain several ports, and so
submit a steady trickle of PR's there. Almost none of them take more
than a week from submission to application and closing, and it's
fairly common for it to be less than 24 hours. I know the ports team
carries a huge load with such things, but they're carrying it well.)


--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[Julian Elischer]

On 1/17/12 3:50 PM, Doug Barton wrote:
> First, let's do away with the whole, "If you step up to help, your help
> will be accepted with open arms" myth. That's only true if the project
> leadership agrees with your goals.

"leadership" doesn't really control development here. action does.

> We also need to take a step back and ask if throwing more person-hours
> at the problem is the right solution, or if redesigning the system to
> better meet the needs of the users *as a first step* is the right answer?
>

careful, you are starting to sound reasonable there..

> On 01/17/2012 15:01, Adrian Chadd wrote:
>> .. I'm replying to the OP because honestly, this thread has gotten a
>> bit derailed.
>>
>> If you'd like to see:
>>
>> ... more frequent releases? then please step up and help with all the
>> infrastructure needed to roll out test releases, including building
>> _all_ the ports. A lot of people keep forgetting that a "release" is
>> "build all the ports for all the supported platforms".
> Does it need to be? I've been pushing a long time now to have a branched
> ports tree. If we have a "stable" version of the ports where only
> known-good changes are promoted then that frees us up quite a bit to
> redefine what a "release" is.

that's another 'man hours' problem (branched ports)

>> ... longer lifecycle? Then please step up and contribute patches for
>> features for your favourite branch. As a developer doing this in my
>> spare time I'm only really working on new features on -HEAD and maybe
>> backporting fixes to 9.x. What _I_ would like is someone to take on
>> the task of testing and backporting net80211/ath fixes to 8.x and 7.x.
> So you want to do all the fun stuff, and have someone else do your scut
> work? Good luck with that. :) Maybe what we need to do is redefine what
> it means to be a FreeBSD committer. "From now on, your commit bit comes
> with XYZ privileges, but also ABC responsibilities." Sure, we'd lose
> some people, but what would we gain?
>
> Also, your premise is flawed. We (speaking generally) suck at supporting
> more than one -stable branch. We *really* suck at supporting three. Six
> months ago when the machinery was just beginning to spin up for
> 9.0-RELEASE I tried to get the PTB to reconsider. I was told that my
> concerns were invalid because it was basically ready to go as is.
>
> The plan I laid out at the time was to have no more than 2 stable
> branches extant at any given time. Lengthen the periods where each
> stable branch is supported, and terminate the oldest one when the newest
> one is released.
>

I certainly think 9.0 was premature.. 8.x just started.. this should
have been 8.3.

>> ... longer branch lifecycle? Same as above. None of the developers are
>> going to reject bugfixes and backported drivers to a legacy, stable
>> branch. We may be a bit against the idea of porting entire new
>> subsystems to legacy, stable branches - but if there's a good enough
>> reason _and_ it's been tested _and_ there's a need for it - _I_
>> wouldn't say no.
> But committers already fail to MFC *existing* bug fixes to stable
> branches (even ones they generated). This is especially true for the
> older branches. So how is the idea of users generating more new bug
> fixes going to help?

usually it's because they just forgot..

[Matthew D. Fuller]

On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of
Julian Elischer, and lo! it spake thus:

>
> 5 was not out on a limb for so long because it was a clusterfun, it
> was out there because it was a rework of how almost everything in
> the kernel worked.

I'm not saying it was a cluster because it was a huge amount of very
deep work; it's because that huge amount of very deep work completely
gated our next release. Now, sure, changing external circumstances
caught us with our pants down, and the tools we were using (like CVS)
made it hard to do anything else. But that just means there were
good reasons why it happened; doesn't make it less clusterfull :)


The two circumstances (giant rework, and long period between major
releases) are duals of each other. If we chop off giant piles of
stuff to do for FreeBSD-next, it's going to take a very long time.
And if we instead just set very long times (Jan 2017 for 10?!
Insanity!) for -next, we're going to end up with giant reworks and
huge differences.

And _both_ faces are very bad. The one means we wait forever for any
new work, and the other means that it takes enormous amounts of work
as a user to transistion across the barrier.

--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[Devin Teske]

On Jan 17, 2012, at 7:05 PM, "Matthew D. Fuller" <full...@over-yonder.net> wrote:

> On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of
> Julian Elischer, and lo! it spake thus:
>>
>> 5 was not out on a limb for so long because it was a clusterfun, it
>> was out there because it was a rework of how almost everything in
>> the kernel worked.
>
> I'm not saying it was a cluster because it was a huge amount of very
> deep work; it's because that huge amount of very deep work completely
> gated our next release. Now, sure, changing external circumstances
> caught us with our pants down, and the tools we were using (like CVS)
> made it hard to do anything else. But that just means there were
> good reasons why it happened; doesn't make it less clusterfull :)
>
>
> The two circumstances (giant rework, and long period between major
> releases) are duals of each other. If we chop off giant piles of
> stuff to do for FreeBSD-next, it's going to take a very long time.
> And if we instead just set very long times (Jan 2017 for 10?!
> Insanity!) for -next, we're going to end up with giant reworks and
> huge differences.
>
> And _both_ faces are very bad. The one means we wait forever for any
> new work, and the other means that it takes enormous amounts of work
> as a user to transistion across the barrier.
>

We could adopt a cycle similar to the Linux Kernel...

Odd numbered releases are "experimental" while even numbered releases are "stable"

(ducks for flying fruit)

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

[Julian Elischer]

On 1/17/12 7:12 PM, Devin Teske wrote:
>
> On Jan 17, 2012, at 7:05 PM, "Matthew D. Fuller"<full...@over-yonder.net> wrote:
>
>> On Tue, Jan 17, 2012 at 06:49:02PM -0800 I heard the voice of
>> Julian Elischer, and lo! it spake thus:
>>> 5 was not out on a limb for so long because it was a clusterfun, it
>>> was out there because it was a rework of how almost everything in
>>> the kernel worked.
>> I'm not saying it was a cluster because it was a huge amount of very
>> deep work; it's because that huge amount of very deep work completely
>> gated our next release. Now, sure, changing external circumstances
>> caught us with our pants down, and the tools we were using (like CVS)
>> made it hard to do anything else. But that just means there were
>> good reasons why it happened; doesn't make it less clusterfull :)
>>
>>
>> The two circumstances (giant rework, and long period between major
>> releases) are duals of each other. If we chop off giant piles of
>> stuff to do for FreeBSD-next, it's going to take a very long time.
>> And if we instead just set very long times (Jan 2017 for 10?!
>> Insanity!) for -next, we're going to end up with giant reworks and
>> huge differences.
>>
>> And _both_ faces are very bad. The one means we wait forever for any
>> new work, and the other means that it takes enormous amounts of work
>> as a user to transistion across the barrier.
>>

the trouble with 5 was that it had to be all-or-nothing.

there is no such thing as a partly SMP system. (well, not one that
you'd want to run).

the size of the "giant pile of stuff" was not of our choosing.

[Atom Smasher]

On Tue, 17 Jan 2012, Mark Felder wrote:

> To be fair, it could be worse -- OpenBSD secretly wants you to run
> snapshots and CURRENT as the RELEASEs are mostly unmaintained outside of
> the most extreme security concerns. Even the packages are kept at the
> exact version of the time of release.
=============

and how many corps are running openBSD? talk about an OS that seems to
exist only as a playground for its developers...

--
...atom

________________________
http://atom.smasher.org/
762A 3B98 A3C3 96C9 C6B7 582A B88D 52E4 D9F5 7808
-------------------------------------------------

"All censorships exist to prevent anyone from challenging
current conceptions and existing institutions. All progress
is initiated by challenging current conceptions, and executed
by supplanting existing institutions. Consequently, the first
condition of progress is the removal of censorships."
-- George Bernard Shaw

[richo]

On 18/01/12 10:07 +1300, Atom Smasher wrote:
>On Tue, 17 Jan 2012, Mark Felder wrote:
>
>>To be fair, it could be worse -- OpenBSD secretly wants you to run
>>snapshots and CURRENT as the RELEASEs are mostly unmaintained
>>outside of the most extreme security concerns. Even the packages
>>are kept at the exact version of the time of release.
>=============
>
>and how many corps are running openBSD? talk about an OS that seems
>to exist only as a playground for its developers...
>

This is more or less like Debian in regards to their packaging.

Admittedly, OpenBSD is way up there on the paranoia scale, but I know of
plenty of big companies running OpenBSD on large scale routing
infrastructure.

--
richo || Today's excuse:

Your Pentium has a heating problem - try cooling it with ice cold
water.(Do not turn off your computer, you do not want to cool down the
Pentium Chip while he isn't working, do you?)
http://blog.psych0tik.net

[Mark Felder]

On Tue, 17 Jan 2012 15:07:56 -0600, Atom Smasher <at...@smasher.org> wrote:

> and how many corps are running openBSD?

Works amazingly well as an edge router. You get pf, openbgpd, openspfd....
much higher performance that 50K cisco gear. The bugs we've hit have been
fixed promptly as well. Pretty decent little setup for a budget. But yeah,
not many do what we do.

[Matthew D. Fuller]

On Tue, Jan 17, 2012 at 07:20:15PM -0800 I heard the voice of

Julian Elischer, and lo! it spake thus:
>

> the trouble with 5 was that it had to be all-or-nothing.
>

> [...]

>
> the size of the "giant pile of stuff" was not of our choosing.

As may be, it's beside my point. Whether due to malice, incompetence,
or the unalterable ways of the universe, 5 spent something approaching
forever "not ready to release", and depending on who you ask, kept
that status until it became known as "6.0". And that, not "4 is
awesome", is the principal reason 4 kept chugging so long.

--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.

[Doug Barton]

On 01/17/2012 19:20, Julian Elischer wrote:
> the trouble with 5 was that it had to be all-or-nothing.
>
> there is no such thing as a partly SMP system. (well, not one that you'd
> want to run).
>
> the size of the "giant pile of stuff" was not of our choosing.

.. again, with all due respect to those who worked so hard to get 5.0
out the door ... That's not quite true.

The original goal for 5.0 was to completely remove the Giant lock (and
do other cool SMP-related stuff). Eventually it was realized that this
was too big a goal to fully accomplish in 5.0 (albeit too late in the
process) and the goal was changed to do the basic framework for the new
SMP model; and lay the groundwork for "some things run under Giant for
now, and we'll remove it from them ASAP." That actually turned out to
last through 6, making 7 the realization of what 5.0 was supposed to be.

So what we need to do is to learn from the mistakes that were made, and
figure out how we can make *reasonable* plans for both new features, and
the framework for the future development that we want; without making
the "all or nothing" mistake again.

Doug

--

It's always a long day; 86400 doesn't fit into a short.

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/

[Roman Kurakin]

Devin Teske wrote:
> [...]

> We could adopt a cycle similar to the Linux Kernel...
>
> Odd numbered releases are "experimental" while even numbered releases are "stable"
>

I do not know the current state things in Linux kernel, but as far as I
know 2.6 branch was
not "stable". It was branch with a lot of experimental code and with a
lot of API change.

rik

[Andriy Gapon]

on 18/01/2012 02:16 Igor Mozolevsky said the following:

> Seriously, WTF is the point of having a PR system that allows patches
> to be submitted??! When I submit a patch I fix *your* code (not yours
> personally, but you get my gist).

Let me pretend that I don't get it. It is as much your code as it is mine if
you are a user of FreeBSD. I just happen to have a commit bit at this point in
time.

> No other project requires a
> non-committer to be so ridiculously persistent in order to get a patch
> through.

There are about 5000 open PRs for FreeBSD base system, maybe more.
There are only a few dozens of active FreeBSD developers. Maybe less for any
given particular point in time (as opposed to a period of time).
And dealing with PRs is not always exciting.
Need I continue?

P.S. Using GNATS for the PR database doesn't help either, in some technical ways.
--
Andriy Gapon

[Andriy Gapon]

on 18/01/2012 01:09 Devin Teske said the following:

> I'm ready to say that the 9-series should instead be the "chosen
> outlier" when it comes to picking one single release to have an ultra-wide
> lifecycle.

But how can you say that without knowing what will (can) come in 10. Maybe it
will have something that would be a complete re-write, but something that you
would super-want.
IMO, it's the whole purpose of our present stable branches policy to let users
try/test/use new/advanced features sooner, all while having a choice.

[Andriy Gapon]

on 17/01/2012 00:28 John Kozubik said the following:
> FreeBSD is becoming an operating system by, and for, FreeBSD developers

Just want to express my _personal_ opinion on this statement.

I think that the proper tense for the statement would perfect - "has become".
And I think that that is inevitable at present, because the FreeBSD project is a
purely community driven/developed project. A project by the community. And
it's natural that it has become a project for the community. The community of
the project's developers.
Let's see. The project has no management. There is no hierarchy of reporting.
There are no assignments. No monetary leverage. No structure. No single
vision and will.

Let's omit a discussion of a possibility of a project "by users".

Instead let's try to see how projects perceived to be "for users" typically
work. My personal observation is that those projects are always commercial
(which can be in a variety of ways). That is, they are "for users", because
they look to make some money from their user base. Either via direct sales, or
via support contracts, or via sales of related products and services, or via
monetary deals with other corporations, or via voluntary donations from users
and/or corporate sponsorship, or a combination.
And those projects internally are also based on money. They are corporations:
they have management, they have hierarchy, they have assignments, they have
plans, they have salaries, they QA teams, etc.

Take for a popular example of Linux. How much is for users the kernel.org?
Compare it to the most popular distributions which produce the original products
like Red Hat and Ubuntu. Debian... to me it seems to be more of a "for
developers" thing, not unlike FreeBSD, but with more man-power.

The closest to a corporation that there is now for FreeBSD is the FreeBSD
Foundation. But it plays a very different role - although it depends on the
donations, it doesn't make any product. It doesn't direct the FreeBSD project,
it helps it.

I personally do not see a way to make a volunteer project to be for users as
opposed to being for the said volunteers/community.
I do not have any advice for the users here except either becoming an
influential part of the community or getting a deal with a FreeBSD vendor.
It would be cool if the project had enough users to make a commercial
FreeBSD-oriented "for users" entity viable. Perhaps iXsystems is already it.

P.S. I've just learned a new "word", from the Debian people - "Do-o-cracy" as in
"the doer decides". Seeing some references to a mythical "FreeBSD leadership"
in this thread I couldn't resist a temptation to mention this word.