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
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
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 raised. If
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
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
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
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
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 is
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
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
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
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?
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
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
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 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
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 drivers, no
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
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
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 (both
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 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
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
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
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)
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
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 production release?
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
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
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, although
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
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
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
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
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,
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 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),
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
Of course.
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 the requirements
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
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
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
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
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 something we
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 while
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 factor is
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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 extend
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
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
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
(hardware)
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
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
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
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 agrees
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
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
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
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
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 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
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
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
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
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
-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
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
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 people
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
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 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
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 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
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 site: (snip)
On
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 EoL
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
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,
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.
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:
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 September 8
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
95 matches
Mail list logo
