On Tuesday 23 September 2008 04:42:13 pm Jo Rhett wrote:
> John, we're already committed to upgrade to 6.3 (since it will
> currently be supported longer than 6.4). 6.2 support isn't part of
> this conversation, it has entirely revolved around support periods for
> upcoming releases.
Then r
John, we're already committed to upgrade to 6.3 (since it will
currently be supported longer than 6.4). 6.2 support isn't part of
this conversation, it has entirely revolved around support periods for
upcoming releases.
On Sep 23, 2008, at 1:10 PM, John Baldwin wrote:
Jo, so it seems to me
Jo, so it seems to me that you could just start by maintaining your own set of
extended support patches for the FreeBSD releases you care about. I don't
think you have to be a committer or secteam@ member to do this. It does mean
that you might not be able to fix a bug in, say, 6.2 at the same
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote:
It also doesn't seem reasonable to expect that decision to be rushed
in
advance of the necessary evaluation of the success or otherwise of
both
6.4 and 7.1 releases - especially when we're talking about these being
only a month or so away anyway.
On Sep 23, 2008, at 12:45 AM, Ian Smith wrote:
I mean seriously, if you were to say "We will support 6.4 for 24
months
*unless* we find it necessary to release 6.5 then I'd be totally
happy. But
that's not what is being said.
I believe that's exactly what has been said. rwatson@ and simon
On Tue, 23 Sep 2008, Ian Smith wrote:
>On Mon, 22 Sep 2008, Jo Rhett wrote:
> > I think you are using "last release" in a different way. "the last release"
> > is always the most release release. Right now 6.3 will have support for
> > longer than 6.4 will, which is the nature of the problem I ra
On Mon, 22 Sep 2008, Jo Rhett wrote:
> On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
> > This is precisely what we already do -- we guarantee we will support the
> > last release on a branch for 24 months after the release. The point of
> > concern being discussed is that we can't tell you
On Sep 22, 2008, at 3:46 PM, Robert Watson wrote:
The key point here holds, however: I think we should not ever be in
the position of telling people that support lifetime on a release
has been reduced.
I agree. However, there are other ways of doing this than to create
overlapping window
On Sep 22, 2008, at 2:56 PM, Doug Barton wrote:
I'd also like to point out that there is another chicken-egg problem
that has been glossed over in this thread. You have said many times
that
it's hard for a company to devote resources to testing a given release
candidate without knowing in adva
On Sep 22, 2008, at 1:54 PM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will
support the last release on a branch for 24 months after the
release. The point of concern being discussed is that we can't
tell you for sure which minor release will be the last r
On Sep 22, 2008, at 1:32 PM, Robert Watson wrote:
Long answer: we're under-manned for our current commitments, and
have seen longer advisory cycles than we would like. My guess is
that we could eat the first 25% of a person just catching up on
current obligations so as to reduce latency on
On Mon, Sep 22, 2008 at 5:37 PM, Doug Barton <[EMAIL PROTECTED]> wrote:
> Dylan Cochran wrote:
>> One of the biggest (and most prominent, though not obviously so)
>> issues is the lack of concurrency with regards to releases. With the
>> default system, having multiple freebsd releases side by side
On Mon, 22 Sep 2008, Robert Watson wrote:
I think you are using "last release" in a different way. "the last
release" is always the most release release. Right now 6.3 will have
support for longer than 6.4 will, which is the nature of the problem I
raised. If you always supported the most
Dylan Cochran wrote:
> One of the biggest (and most prominent, though not obviously so)
> issues is the lack of concurrency with regards to releases. With the
> default system, having multiple freebsd releases side by side (both
> different versions, and different architectures) is infeasible. This
Jo Rhett wrote:
> On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote:
>> Or to put it another way, what to you is "support" in terms of
>> FreeBSD releases. As far as I am aware, if you stick on a
>> RELENG_X_Y_Z_RELEASE tag
>> then the most you get is security fixes. No new features,
>> no new driver
On Mon, 22 Sep 2008, Jo Rhett wrote:
On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will support the
last release on a branch for 24 months after the release. The point of
concern being discussed is that we can't tell you for sure wh
On Mon, 22 Sep 2008, Jo Rhett wrote:
On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
Lack of human resources, to use a vile term, is currently the limiting
factor. What happens when that is cleared is another question, but in the
end there aren't a whole lot of paths to greater efficiency
On Sep 22, 2008, at 12:41 PM, Robert Watson wrote:
Lack of human resources, to use a vile term, is currently the
limiting factor. What happens when that is cleared is another
question, but in the end there aren't a whole lot of paths to
greater efficiency here:
...
This is an inherently man
On Sep 21, 2008, at 1:57 AM, Robert Watson wrote:
This is precisely what we already do -- we guarantee we will support
the last release on a branch for 24 months after the release. The
point of concern being discussed is that we can't tell you for sure
which minor release will be the last r
On Mon, 22 Sep 2008, Jo Rhett wrote:
Again, what you are saying makes a lot of sense, and I have no problem with
it. We're just missing the crucial bit -- what is it going to take to reach
that goal? Regardless of commit bits, etc and such forth. Is 10 hours a
week of one person enough? Doe
On Sep 20, 2008, at 1:56 PM, Simon L. Nielsen wrote:
2 years for each supported branch would be excellent, although I'm
open to alternatives. Right now 6.4 will EoL before 6.3 will :-(
Eh, where did you get that information? AFAIK the EoL date of 6.4 has
not yet been decided (and I should kn
On Sep 20, 2008, at 12:04 PM, Gary Palmer wrote:
Actually Robert, to be fair to Jo, I suspect it is more proper to say
"$COMPANY wants extended support lifetimes. What can I, or $COMPANY,
do to help make that happen?". I think its been misinterpreted as
Jo saying "Let me do the work". He has o
On Sep 20, 2008, at 3:37 AM, Robert Watson wrote:
The tension here is between making promises we can definitely keep
and starting to make promises that we can't. We'd like to err on
the former, rather than latter, side.
Yes. This is well understood and I agree with those priorities.
You a
On September 19, 2008 09:41 pm Gary Palmer wrote:
> On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
> > Without input from the current release team extending the support
> > schedule is not possible.
>
> Inquiry - is release team the constraint?
>
> Or to put it another way, what to you
On Sat, Sep 20, 2008 at 9:52 PM, Aristedes Maniatis <[EMAIL PROTECTED]> wrote:
>
> On 21/09/2008, at 10:34 AM, netgeek wrote:
>
>> Perhaps there is a middle ground here? What about a statement that each
>> major branch (6.x, 7.x) will be supported for at least 24+ months from its
>> last productio
On Sat, 20 Sep 2008, Simon L. Nielsen wrote:
- The more branches are supported, the more versions of both third
party code and FreeBSD code need to be supported and the more likely
it is that the software differs meaning that we need to adopt the
fix to the branch. The real painful case for
On Sat, 20 Sep 2008, netgeek wrote:
Don't get me wrong: I would love to see us support all releases for 24
months (or even more) after they ship. I think our users would appreciate
that also.
Perhaps there is a middle ground here? What about a statement that each
major branch (6.x, 7.x) w
On 21/09/2008, at 10:34 AM, netgeek wrote:
Perhaps there is a middle ground here? What about a statement that
each major branch (6.x, 7.x) will be supported for at least 24+
months from its last production release? Smaller periods of support
could be given to minor releases along the way
Robert Watson wrote:
When it comes to commercial OS products, like Windows and Mac OS X,
there is often a strict requirement to live on the most recent minor
release in order to continue to receive support. For example, you won't
make a lot of headway turning up at Apple and demanding security
On 2008.09.19 21:30:11 -0700, Jo Rhett wrote:
> On Sep 19, 2008, at 8:57 PM, David N wrote:
> > How long are you expecting support for a RELENG to last, 1, 2, 3
> > years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates)
>
> 2 years for each supported branch would be excellent, altho
On Sat, Sep 20, 2008 at 11:37:25AM +0100, Robert Watson wrote:
> You already identified the end goal: extend support lifetimes. You placed
> constraint on how that could be accomplished: you were going to do the
> work.
Actually Robert, to be fair to Jo, I suspect it is more proper to say
"$COM
On Fri, 19 Sep 2008, Jo Rhett wrote:
Look, I understand what you're saying here. And I don't discredit or
disagree that it shouldn't be handled this way. But what you have addressed
is a stepwise integration policy of a developer, and does not address how to
get a business to commit those r
On Sep 19, 2008, at 9:41 PM, Gary Palmer wrote:
On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
Without input from the current release team extending the support
schedule is not possible.
Inquiry - is release team the constraint?
I don't know. I asked why not, and was told the rel
On Fri, Sep 19, 2008 at 07:38:32PM -0700, Jo Rhett wrote:
> Without input from the current release team extending the support
> schedule is not possible.
Inquiry - is release team the constraint?
Or to put it another way, what to you is "support" in terms of
FreeBSD releases?
As far as I am a
On Sep 19, 2008, at 8:57 PM, David N wrote:
How long are you expecting support for a RELENG to last, 1, 2, 3
years? 5 years? (comparison, Ubuntu LTS is 3 years, security updates)
2 years for each supported branch would be excellent, although I'm
open to alternatives. Right now 6.4 will EoL b
2008/9/20 Jo Rhett <[EMAIL PROTECTED]>:
>
> On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
>>>
>>> To get a business to commit resources to a project there must be an
>>> actual goal.
>>
>> [1] The FreeBSD project would have to commit resources too. Its community
>
> Of course. This is what t
On Fri, Sep 19, 2008 at 10:38 PM, Jo Rhett <[EMAIL PROTECTED]> wrote:
>
> On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
>>>
>>> To get a business to commit resources to a project there must be an
>>> actual goal.
>>
>> [1] The FreeBSD project would have to commit resources too. Its community
On Sep 19, 2008, at 7:07 PM, Aragon Gouveia wrote:
To get a business to commit resources to a project there must be an
actual goal.
[1] The FreeBSD project would have to commit resources too. Its
community
Of course. This is what the requirements analysis is ;-)
For (a), (b), and (z), t
>From what I've gathered so far...
| By Jo Rhett <[EMAIL PROTECTED]>
| [ 2008-09-20 02:46 +0200 ]
> To get a business to commit resources to a project there must be an
> actual goal.
[1] The FreeBSD project would have to commit resources too. Its commun
First, I'd like to thank you for taking the time to respond to this
seriously. I hope you'll read my reply in the very serious, and not
accusative tone it is meant. (I am a little tired and fried at the
moment, I may not use the best phrasing. I hope I do.)
On Sep 19, 2008, at 4:20 AM, R
On Thu, 18 Sep 2008, Jo Rhett wrote:
Thank you. If you don't mind I'd prefer to widen the scope a touch because
6.2 will eventually go away, and frankly it is probably better to look
forward than to resurrect an unsupported version. So I would probably
state:
Jo's $EMPLOYER has significant
Hi,
Jo Rhett wrote:
I agree with pretty much everything you've said here, with the obvious
exception that I don't know what's involved in the release management
process to do as you've said.
Also for my own self, rather than resurrect 6.2 I'd personally rather
focus on what we could do to ex
At 05:46 PM 9/18/2008, Jo Rhett wrote:
I'd rather just drop this tangent.
Me too.
---Mike
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECT
I agree with pretty much everything you've said here, with the obvious
exception that I don't know what's involved in the release management
process to do as you've said.
Also for my own self, rather than resurrect 6.2 I'd personally rather
focus on what we could do to extend the support pe
Quoting Jo Rhett, who wrote on Thu, Sep 18, 2008 at 11:58:00AM -0700 ..
> On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote:
> > You seem to be *demanding* quite a lot lately.
>
>
> I have demanded nothing. I have made a suggestion or two -- presented
> the background which pretty much everyone a
On Thu, Sep 18, 2008 at 12:23:45PM -0700, Jo Rhett wrote:
> On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
> > (1) Become a contributor to the community by developing and
> > maintaining patches against unsupported branches, especially against
> > older releases such as 4.x and 5.x where the b
On Sep 18, 2008, at 2:03 PM, Mike Tancsa wrote:
I had a search and I see some PRs you have submitted, but I guess
you commit under a different @freebsd.org email address ?
I don't commit. I submit and others commit. This hasn't really been
a handicap ;-)
Thats most excellent! I think pe
On Sep 18, 2008, at 1:20 PM, Lowell Gilbert wrote:
I've kind of lost the drift, but it sounds to me as though Jo Rhett is
tentatively offering to take on extended support for 6.2, but not
earlier versions. Aside from programming skills, what would Jo need
to bring to the table in order to provid
On Thu, Sep 18, 2008 at 05:03:05PM -0400, Mike Tancsa wrote:
> At 04:13 PM 9/18/2008, Jo Rhett wrote:
>> On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote:
>>> I am sorry, I meant, what have you contributed currently or in the
>>> past to FreeBSD ? i.e. what code, or money or physical resources
>>> (
On Thu, 18 Sep 2008, Lowell Gilbert wrote:
Jo Rhett <[EMAIL PROTECTED]> writes:
We have no 4.x or 5.x systems nor do we have any interest in maintaining
those. So perhaps a good idea, but not something I can help with.
I *did* offer to work on maintenance for 6.2, but was told it would be
At 04:13 PM 9/18/2008, Jo Rhett wrote:
On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote:
I am sorry, I meant, what have you contributed currently or in the
past to FreeBSD ? i.e. what code, or money or physical resources
(hardware) or time testing code ?
I do a lot of testing and patches regar
Jo Rhett <[EMAIL PROTECTED]> writes:
> We have no 4.x or 5.x systems nor do we have any interest in
> maintaining those. So perhaps a good idea, but not something I can
> help with.
>
> I *did* offer to work on maintenance for 6.2, but was told it would be
> rejected by the developers. Would I e
On Sep 18, 2008, at 12:46 PM, Mike Tancsa wrote:
I am sorry, I meant, what have you contributed currently or in the
past to FreeBSD ? i.e. what code, or money or physical resources
(hardware) or time testing code ?
I do a lot of testing and patches regarding components we use. Search
the
On Sep 18, 2008, at 9:23 PM, Jo Rhett wrote:
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
Let's consider three more productive avenues by which you can
offer assistance with the problem of how to increase branch
support lifetimes:
(1) Become a contributor to the community by developin
At 03:39 PM 9/18/2008, Jo Rhett wrote:
On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote:
I am not familiar with your company nor any developers that work for
you. Perhaps you could elaborate on how you have contributed to
FreeBSD ?
In my $EMPLOYER the main proposal would be to dedicate more of
On Sep 18, 2008, at 12:25 PM, Mike Tancsa wrote:
I am not familiar with your company nor any developers that work for
you. Perhaps you could elaborate on how you have contributed to
FreeBSD ?
This domain is my vanity domain, actually. Well not vanity but the
domain I use on the rare occa
On Thu, 18 Sep 2008, Jo Rhett wrote:
And my e-mails have always discussed ways to get more resources.
Recently we even had a group of people trying to arrange for more
explicit corporate support for testing and release process. For
some reason unclear to me, not a single developer has step
At 03:11 PM 9/18/2008, Jo Rhett wrote:
committing that time. (besides the obvious "giving back to the
community part" which we do anyway)
I am not familiar with your company nor any developers that work for
you. Perhaps you could elaborate on how you have contributed to FreeBSD ?
On Sep 18, 2008, at 12:01 PM, Robert Watson wrote:
So far, this conversation has largely consisted of you telling us
that you don't like what we're doing and demanding that we change.
I'm not sure what is going on in your life to make you so defensive
that someone saying "I have resources, I
On Thu, 18 Sep 2008, Jo Rhett wrote:
On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote:
Indeed, there is no easy solution. Extending support lifetime takes more
resources of course.
And my e-mails have always discussed ways to get more resources. Recently
we even had a group of people trying
First, thanks for taking the question seriously ;-)
On Sep 18, 2008, at 8:47 AM, Dylan Cochran wrote:
problem can't be solved just by extending time with the hope that the
resources will be allocated (no offense to your character, but that
No offense taken. I would never suggest we do anythin
On Sep 18, 2008, at 8:21 AM, Freddie Cash wrote:
Maybe I'm missing something here, but it seems like Jo just wants to
argue
for the sake of arguing.
You are missing a lot. You're not reading even half of what I am
saying.
re: ignored. I don't ignore anything. If something is answered
On Sep 18, 2008, at 6:32 AM, Wilko Bulte wrote:
Indeed, there is no easy solution. Extending support lifetime takes
more
resources of course.
And my e-mails have always discussed ways to get more resources.
Recently we even had a group of people trying to arrange for more
explicit corp
On Wed, 17 Sep 2008, Jo Rhett wrote:
Please stop avoiding even considering what people are offering to you.
So far, this conversation has largely consisted of you telling us that you
don't like what we're doing and demanding that we change. Let's consider
three more productive avenues by w
On Sep 18, 2008, at 5:46 AM, Wilko Bulte wrote:
You seem to be *demanding* quite a lot lately.
I have demanded nothing. I have made a suggestion or two -- presented
the background which pretty much everyone agrees with, made some
suggestions about how to improve it.
My last post was exp
On Thu, Sep 18, 2008 at 12:25 AM, Jo Rhett <[EMAIL PROTECTED]> wrote:
> I understand what you mean, but the statement is blatantly false as stated.
> Anyone selling software to the US Government *must* specify (or meet,
> depending) a minimum support period, and must also specify a cost the agency
Maybe I'm missing something here, but it seems like Jo just wants to argue
for the sake of arguing.
First Jo wrote:
>No other answer. But nobody has yet provided what the EoL period is
>going to be. I have no problems with a period being extended ;-) But
>the business needs to know the min
Quoting Jeremy Chadwick, who wrote on Thu, Sep 18, 2008 at 06:18:40AM -0700 ..
> On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote:
> > Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 ..
> > > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote:
> > > > An important fact
On Thu, Sep 18, 2008 at 02:46:09PM +0200, Wilko Bulte wrote:
> Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 ..
> > On Sep 17, 2008, at 4:33 PM, Robert Watson wrote:
> > > An important factor is whether or not we consider the release a
> > > highly maintainable release, and
Quoting Jo Rhett, who wrote on Wed, Sep 17, 2008 at 09:25:27PM -0700 ..
> On Sep 17, 2008, at 4:33 PM, Robert Watson wrote:
> > An important factor is whether or not we consider the release a
> > highly maintainable release, and while we have intuitions at the
> > time of release, that's someth
Andrew Snow wrote:
Another thing that I believe would help: Voting on PRs.
Currently a maintainer has no idea if a PR is due to one guy's flakey
hardware or if 50 people have had the same problem and are waiting for a
fix.
For each major problem report, there are probably many people who tr
Another thing that I believe would help: Voting on PRs.
Currently a maintainer has no idea if a PR is due to one guy's flakey
hardware or if 50 people have had the same problem and are waiting for a
fix.
For each major problem report, there are probably many people who tried
FreeBSD on part
On Sep 17, 2008, at 4:33 PM, Robert Watson wrote:
An important factor is whether or not we consider the release a
highly maintainable release, and while we have intuitions at the
time of release, that's something we can only learn in the first
couple of months after it's in production. I do
On Wed, 17 Sep 2008, Jo Rhett wrote:
On Mon, 15 Sep 2008, Jo Rhett wrote:
Robert, I'd like to point out to you that when I complained about 6.2's
accelerated EoL, I was soundly boxed around the ears and told that I
should have been paying attention to the projected EoL date when we
decided t
On Mon, 15 Sep 2008, Jo Rhett wrote:
Robert, I'd like to point out to you that when I complained about
6.2's accelerated EoL, I was soundly boxed around the ears and told
that I should have been paying attention to the projected EoL date
when we decided to roll out 6.2 across the business.
On Sep 16, 2008, at 12:38 AM, Matthew Seaman wrote:
On 'long term support of release branches' -- a volunteer project is
always
going to struggle to provide this without some form of income to
support the
necessary hardware and personnel resources needed. Or in other
words, if
FreeBSD users
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote:
I think FreeBSD is getting in a difficult position now because
there's
so much cool new stuff being shoe-horned in, but without the
necessary
volume of contributors to back it up with testing and bug fixes.
On Sep 15, 2008, at 11:
On Tue, 16 Sep 2008, Andrew Snow wrote:
Mark Linimon wrote:
So, in your opinion, what's the way to reconcile all these demands
(features + stability + long-term support of release branches) with a group
that is 95%-plus volunteer effort?
Its important to me that people keep using FreeBSD.
On Mon, 15 Sep 2008, Jo Rhett wrote:
On Sep 6, 2008, at 4:06 AM, Robert Watson wrote:
Unfortunately, it's a little hard to tell at time-of-release whether a
particular release will become extended life or not. This is because
extended support status is dependent on the success of the release
On Tue, Sep 16, 2008 at 06:51:32PM +1000, Andrew Snow wrote:
> Mark Linimon wrote:
>> So, in your opinion, what's the way to reconcile all these demands
>> (features + stability + long-term support of release branches) with
>> a group that is 95%-plus volunteer effort?
>
> Its important to me that
Mark Linimon wrote:
So, in your opinion, what's the way to reconcile all these demands
(features + stability + long-term support of release branches) with
a group that is 95%-plus volunteer effort?
Its important to me that people keep using FreeBSD. Numbers are
important. To that end I'm hap
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Mark Linimon wrote:
| On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote:
|> I think FreeBSD is getting in a difficult position now because there's
|> so much cool new stuff being shoe-horned in, but without the necessary
|> volume of
On Tue, Sep 16, 2008 at 04:30:26PM +1000, Andrew Snow wrote:
> I think FreeBSD is getting in a difficult position now because there's
> so much cool new stuff being shoe-horned in, but without the necessary
> volume of contributors to back it up with testing and bug fixes.
We're interested in su
Jo Rhett wrote:
Because frankly we're going to be forced to run our own internal
release management process instead.
I guess this is not surprising, as this appears to be what every other
business using significant amounts of freebsd in production are doing
today.
I'm afraid you've hit the na
On Sep 6, 2008, at 4:06 AM, Robert Watson wrote:
Unfortunately, it's a little hard to tell at time-of-release whether
a particular release will become extended life or not. This is
because extended support status is dependent on the success of the
release ...
from earlier branch adopters.
On Sep 5, 2008, at 1:19 PM, Ben Kaduk wrote:
Normal
Releases which are published from a -STABLE branch will be
supported by the Security Officer for a minimum of 12 months after the
release.
Extended
Selected releases will be supported by the Security Officer for a
minimum of 24 months afte
On Fri, 5 Sep 2008, Ben Kaduk wrote:
To quote from the same website:
Early adopter
Releases which are published from the -CURRENT branch will be
supported by the Security Officer for a minimum of 6 months after the
release.
Normal
Releases which are published from a -STABLE branch will be
On Thu, Sep 4, 2008 at 2:40 PM, Jo Rhett <[EMAIL PROTECTED]> wrote:
Where can one find the expected EoL for these releases?
>
>> On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote:
>>>
>>> http://www.freebsd.org/security/security.html#supported-branches
>>> To quote from the above web
Where can one find the expected EoL for these releases?
On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote:
http://www.freebsd.org/security/security.html#supported-branches
To quote from the above web site: (snip)
On Sep 4, 2008, at 6:36 AM, Wesley Shields wrote:
These are the exist
On Wed, Sep 03, 2008 at 09:24:04PM -0700, Nathan Way wrote:
> >
> > Where can one find the expected EoL for these releases? I've poked
> > around the website and can't find any notes mentioning this, although
> > several people have been making posts suggesting that people should
> > review the E
>
> Where can one find the expected EoL for these releases? I've poked
> around the website and can't find any notes mentioning this, although
> several people have been making posts suggesting that people should
> review the EoL schedule when planning their upgrades.
http://www.freebsd.org/secu
Where can one find the expected EoL for these releases? I've poked
around the website and can't find any notes mentioning this, although
several people have been making posts suggesting that people should
review the EoL schedule when planning their upgrades.
On Aug 22, 2008, at 5:51 AM, Ke
If memory serves me right, Eugene Grosbein wrote:
> On Sun, Aug 24, 2008 at 01:45:08AM +0200, Svein Skogen wrote:
>
>> In 25 words or less, what are the major changes in 7.0->7.1 and 6.3->6.4
>> for us end users?
>
> In more words, but pretty interesting:
>
> http://people.freebsd.org/~bmah/rel
On Sun, Aug 24, 2008 at 01:45:08AM +0200, Svein Skogen wrote:
> In 25 words or less, what are the major changes in 7.0->7.1 and 6.3->6.4
> for us end users?
In more words, but pretty interesting:
http://people.freebsd.org/~bmah/relnotes/6-STABLE/relnotes-i386.html
http://people.freebsd.org/~bma
Ken Smith wrote:
> We're about to start the release cycle for FreeBSD-7.1 and FreeBSD-6.4.
> The proposed schedule for the "major events" of the cycle is:
>
> Freeze August 29
> BETASeptember 1
> Branch September 6
> 6.4-RC1 Septembe
95 matches
Mail list logo
