CLARITY re: challenge: end of life for 6.2 is premature with buggy 6.3

[Freddie Cash]

On Mon, Jun 9, 2008 at 3:25 PM, Jo Rhett <jrhett at netconsonance.com> wrote:
> On Jun 8, 2008, at 3:27 PM, Freddie Cash wrote:
>> Like I said, you have to define what you mean by "stable" and
>> "unstable" before the discussion can continue.
>>
>> "stable" can mean many things to many people.  You talk about feature
>> stability.  Other may talk about "number of open bugs" as being
>> unstable.  Others may talk of API/ABI stability.  Other may mean "code
>> that don't crash a system".
>>
>> Your view of "stable" meaning "features don't change" is no where near
>> my definition of stable (systems that don't crash, and where I can run
>> binaries from older point releases on newer point releases).
>
> I don't care about features, I care about uptime.  "stable" in my brain
> means that there isn't 150 revisions to the cvs tree in the 2 months post
> release regarding kernel and core drivers.  "stable" is also overloaded with
> meaning "will be around long enough that I can focus on other projects
> instead of replacing it nearly instantly with a new release"
>
> FWIW, since you clearly misunderstood my point of view.

Actually, I believe you misunderstood me, as you quoted me out of
context, and quoted my reply to someone else.  :)

My message to you was "define what you mean by stable and unstable".
Which, if I follow correctly, you define as "never having any commits
to the codebase".

I care about uptime as well (along with performance and
maintainability).  And so far, none of our systems using em(4) cards,
bge(4) cards, twa(4) cards, gmirror(8) (although I've since moved
those to 7-STABLE with ZFS alongside), running on bare metal or in VMs
have any issues with 6.3-RELEASE or 7.0-RELEASE.

But, how does "the number of commits since release" have any bearing
on uptime of a system you haven't tested?  ;)  Those seem to be
completely unrelated to me.

-- 
Freddie Cash
fjwcash at gmail.com