Should patch releases to stable 11.1 (errata) include fixes for kernel
crashes?
Referring to:
Bug 59 - 11.1-R crashing in sendfile syscall, as used by a uwsgi
process
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=59
https://svnweb.freebsd.org/base?view=revision&revi
On Wed, Aug 7, 2013 at 5:04 PM, Glen Barber wrote:
> Some mirrors have already begun to pick up the change.
> Sorry for the inconvenience. It was my fault. :(
> Glen
Naah, this is still 9.2-RC1 for testing, important that 9.2-RELEASE
gets fine :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.inf
On Wed, Aug 07, 2013 at 04:48:58PM +0200, CeDeROM wrote:
> On Wed, Aug 7, 2013 at 4:31 PM, Glen Barber wrote:
> > On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote:
> >> I am installing the 9.2-RC1 bootonly iso which wants to download stuff from
> >> snapsh
On Wed, Aug 7, 2013 at 4:31 PM, Glen Barber wrote:
> On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote:
>> I am installing the 9.2-RC1 bootonly iso which wants to download stuff from
>> snapshots while it is in releases directory:
>
> Ugh. I'll get this fixed as
On Wed, Aug 07, 2013 at 04:18:41PM +0200, CeDeROM wrote:
> Hello :-)
>
> I am installing the 9.2-RC1 bootonly iso which wants to download stuff from
> snapshots while it is in releases directory:
>
> Installer wants to get 9.2-RC1 stuff from here (where it is missing):
>
&g
Hello :-)
I am installing the 9.2-RC1 bootonly iso which wants to download stuff from
snapshots while it is in releases directory:
Installer wants to get 9.2-RC1 stuff from here (where it is missing):
ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/i386/i386/
While the stuff is at:
ftp
;>
>
> When there is no any information about them , what can they do ?
>>
>
> For example in the announcement for the release, e.g. here [1] for FreeBSD
> 9.1
>
> [1]
> http://www.freebsd.org/**releases/9.1R/announce.html#**availability<http://www.freebsd.
reeBSD 9.1
[1]
http://www.freebsd.org/releases/9.1R/announce.html#availability
bye
Fabian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Dears All ,
In no one of the following directories :
ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.3/
ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/8.4/
ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.0/
ftp://ftp1.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1
On 27. Mar 2012, at 18:57 , Charles Sprickman wrote:
> On Mar 27, 2012, at 2:25 PM, Brett Glass wrote:
>
>> Everyone:
>>
>> I've just noted that as of this month, there is no release of FreeBSD -- on
>> any branch -- whose EOL is less than a year away. Should there not be at
>> least one rele
On Mar 27, 2012, at 2:25 PM, Brett Glass wrote:
> Everyone:
>
> I've just noted that as of this month, there is no release of FreeBSD -- on
> any branch -- whose EOL is less than a year away. Should there not be at
> least one release with extended support?
That will be 8.3:
•
On 27/03/2012 19:25, Brett Glass wrote:
> I've just noted that as of this month, there is no release of FreeBSD --
> on any branch -- whose EOL is less than a year away. Should there not
> be at least one release with extended support?
ITYM 'more than a year away' there...
8.3 is due, in fact, o
Everyone:
I've just noted that as of this month, there is no release of
FreeBSD -- on any branch -- whose EOL is less than a year away.
Should there not be at least one release with extended support?
--Brett Glass
___
freebsd-stable@freebsd.org ma
Portmgr published a new page on their website which describes the
current support and EoL policies for the ports tree and released
packages. The main take-home messages are:
- Support of FreeBSD releases by ports and the ports infrastructure
matches the policies set out by the FreeBSD Security
On Tue, 2011-03-01 at 02:05 -0800, Jeremy Chadwick wrote:
> Not to mention, the block size specified doesn't jibe with what's in the
> FreeBSD Handbook (which uses bs=64k):
>
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/install-pre.html
>
> Other users have pointed this out to me o
On Tue, 2011-03-01 at 10:26 +0100, Patrick Lamaiziere wrote:
> Le Thu, 24 Feb 2011 16:26:23 -0500,
> Ken Smith a écrit :
>
> Hello,
>
> > 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
> > messages are available here:
> >
> >
On Tue, Mar 01, 2011 at 10:26:07AM +0100, Patrick Lamaiziere wrote:
> Le Thu, 24 Feb 2011 16:26:23 -0500,
> Ken Smith a écrit :
>
> Hello,
>
> > 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
> > messages are available here:
> >
> >
Le Thu, 24 Feb 2011 16:26:23 -0500,
Ken Smith a écrit :
Hello,
> 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
> messages are available here:
>
> http://www.freebsd.org/releases/8.2R/announce.html
There is a small typo in the name of the usb image:
«
memsti
When I was looking at this problem myself recently it occurred to me
that one way to handle it would be to have the freebsd-update code build
and populate the temproot directory that mergemaster uses and then offer
the user the option to use that alternative. The process could use
something lik
; :-)
>
> freebsd-update does not use mergemaster, though probably it should.
My understanding is that freebsd-update was introduced prior to releases
being branched, so this issue surfaced at that time. The patch I believe
would be a fix to the freebsd-update client to better handle the
On Fri, Feb 25, 2011 at 03:01:11PM -0500, John Baldwin wrote:
...
> No, release branches long pre-date freebsd-update. However, before we
> switched to svn for source, new branches did not bump all the $FreeBSD$ tags.
>
> That is a side effect of the way that the SVN -> CVS exporter works (and
not use mergemaster, though probably it should.
>
> My understanding is that freebsd-update was introduced prior to releases
> being branched, so this issue surfaced at that time. The patch I believe
> would be a fix to the freebsd-update client to better handle the tag. I
> can'
not use mergemaster, though probably it should.
>
> My understanding is that freebsd-update was introduced prior to releases
> being branched, so this issue surfaced at that time. The patch I believe
> would be a fix to the freebsd-update client to better handle the tag. I
> can'
> On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
>>
>> Read up on the mergemaster manual for options "-F" and "-i" :-)
>
> freebsd-update does not use mergemaster, though probably it should.
My understanding is that freebsd-updat
On Fri, Feb 25, 2011 at 02:42:25PM +0100, Marco van Tol wrote:
>
> Read up on the mergemaster manual for options "-F" and "-i" :-)
freebsd-update does not use mergemaster, though probably it should.
We had this discussion a month or two ago.
Currently there is no way around verifying the ch
On Fri, Feb 25, 2011 at 02:47:44PM +0100, Marek 'Buki' Kozlovský wrote:
> [snip]
> > > I had this problem before and then in my frustration just commented out
> > > this line in freebsd-update.conf:
> > >
> > > #MergeChanges /etc/ /var/named/etc/ /boot/device.hints
> > >
> > > I got lucky that
[snip]
> > I had this problem before and then in my frustration just commented out
> > this line in freebsd-update.conf:
> >
> > #MergeChanges /etc/ /var/named/etc/ /boot/device.hints
> >
> > I got lucky that time, but is this really safe? What if, say, a new
> > daemon has been installed in th
n announced. The announcement
> > messages are available here:
> >
> > http://www.freebsd.org/releases/8.2R/announce.html
> > http://www.freebsd.org/releases/7.4R/announce.html
> >
> > Enjoy. :-)
>
> Great news.
>
> However, a freebsd-update fro
Ken Smith, 2011-02-24 22:26 (+0100):
> Just a quick note for those of you who are not subscribed to the
> freebsd-announce mail list...
>
> 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
> messages are available here:
>
> http://www.freebsd.org/releas
Quoth Ken Smith on Thursday, 24 February 2011:
> Just a quick note for those of you who are not subscribed to the
> freebsd-announce mail list...
>
> 8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
> messages are available here:
>
> http://www.free
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Just a quick note for those of you who are not subscribed to the
freebsd-announce mail list...
8.2-RELEASE and 7.4-RELEASE have been announced. The announcement
messages are available here:
http://www.freebsd.org/releases/8.2R/announce.html
Ivan Voras wrote:
Ivan Voras wrote:
Another data point - the OS in the VM in question hanged today
sometime after 5 AM in the following way:
* console nonresponsive (also to ctrl-alt-del)
* ssh login nonresponsive (timeout)
* ping works (!)
Judging by the last seen timestamp, th
Ivan Voras wrote:
Another data point - the OS in the VM in question hanged today sometime
after 5 AM in the following way:
* console nonresponsive (also to ctrl-alt-del)
* ssh login nonresponsive (timeout)
* ping works (!)
Judging by the last seen timestamp, the machine should hav
Steven Hartland wrote:
We're not running 8 yet but we do have a 7.x box which its under fairly
high IO load doing mrtg graphs which has similar behaviour. When typing
a command on ssh it will freeze for may seconds.
We have a FreeBSD 7.2 cacti box running on a dell 1950 that has the same
prob
Ivan Voras wrote:
2009/10/13 Larry Rosenman :
note huge packet loss. It looks like it's VM fault or something like it.
It sounds like the VM is failing to execute the guest during certain
types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go
amiss to confirm that the VM
On Oct 12, 2009, at 10:45 AM, Thomas Backman wrote:
>Here's the original thread (not from the beginning, though):
>http://lists.freebsd.org/pipermail/freebsd-performance/2009-October/003843.html
>Long story short, my version: when the disk is stressed hard enough,
>console IO becomes COMPLETELY un
On Tue, Oct 13, 2009 at 09:58:09AM +0200, Thomas Backman wrote:
>
> On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote:
...
> >hi,
> >this issue (not specific to FreeBSD, and not new -- it has been
> >like this forever) is discussed in some detail here
> >
> > http://www.bsdcan.org/2009/schedule/
Kris Kennaway wrote:
Ivan Voras wrote:
I recall others having various weird problems in 3.5 that went away when
they upgraded to 4.0.
It would be a good idea except that apparently my installation is
unupgradeable because of "unsupported boot disk" (a SCSI RAID volume).
Ivan Voras wrote:
2009/10/13 Larry Rosenman :
note huge packet loss. It looks like it's VM fault or something like it.
It sounds like the VM is failing to execute the guest during certain
types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go
amiss to confirm that the VM
Larry Rosenman wrote:
On Tue, 13 Oct 2009, Ivan Voras wrote:
As for what data is needed, it depends on what you can get - from this
discussion thread it looks like it would be enough to verify that disk
IO doesn't leave VM processes waiting (i.e. that disk IO doesn't
interfere with CPU-bound o
On Tue, 13 Oct 2009, Ivan Voras wrote:
2009/10/13 Larry Rosenman :
note huge packet loss. It looks like it's VM fault or something like it.
It sounds like the VM is failing to execute the guest during certain
types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go
amiss
2009/10/13 Larry Rosenman :
note huge packet loss. It looks like it's VM fault or something like it.
>>>
>>> It sounds like the VM is failing to execute the guest during certain
>>> types of I/O. A bit of scheduler tracing in the host OS probably wouldn't go
>>> amiss to confirm that the VM r
On Tue, 13 Oct 2009, Ivan Voras wrote:
Robert N. M. Watson wrote:
On 13 Oct 2009, at 14:33, Ivan Voras wrote:
If (1) is highly variable during I/O, it's almost certainly a property of
the VM technology you're using, and there's nought to be done about it in
the guest OS.
Here's an example
Robert N. M. Watson wrote:
On 13 Oct 2009, at 14:33, Ivan Voras wrote:
If (1) is highly variable during I/O, it's almost certainly a
property of
the VM technology you're using, and there's nought to be done about
it in
the guest OS.
Here's an example of a ping session with 0.1s resolution
Robert N. M. Watson wrote:
On 13 Oct 2009, at 14:33, Ivan Voras wrote:
If (1) is highly variable during I/O, it's almost certainly a
property of
the VM technology you're using, and there's nought to be done about
it in
the guest OS.
Here's an example of a ping session with 0.1s resolution
On 13 Oct 2009, at 14:33, Ivan Voras wrote:
If (1) is highly variable during I/O, it's almost certainly a
property of
the VM technology you're using, and there's nought to be done about
it in
the guest OS.
Here's an example of a ping session with 0.1s resolution during a few
seconds-stall
2009/10/13 Robert Watson :
>
> On Tue, 13 Oct 2009, Ivan Voras wrote:
>
>> Thomas Backman wrote:
>>>
>>> I'm copying this over from the freebsd-performance list, as I'm looking
>>> for a few more opinions - not on the problems *I* am having, but rather to
>>> check whether the problem is universal
On Tue, 13 Oct 2009, Ivan Voras wrote:
Thomas Backman wrote:
I'm copying this over from the freebsd-performance list, as I'm looking for
a few more opinions - not on the problems *I* am having, but rather to
check whether the problem is universal or not, and if not, find a possible
common fa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ivan Voras wrote:
> Thomas Backman wrote:
>> I'm copying this over from the freebsd-performance list, as I'm
>> looking for a few more opinions - not on the problems *I* am having,
>> but rather to check whether the problem is universal or not, and if
Thomas Backman wrote:
I'm copying this over from the freebsd-performance list, as I'm looking
for a few more opinions - not on the problems *I* am having, but rather
to check whether the problem is universal or not, and if not, find a
possible common factor.
In other words: I want to hear abou
On Tue, Oct 13, 2009 at 11:13:31AM +0100, Kris Kennaway wrote:
> Luigi Rizzo wrote:
> >On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote:
> >>I'm copying this over from the freebsd-performance list, as I'm
> >>looking for a few more opinions - not on the problems *I* am having,
> >
Luigi Rizzo wrote:
On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote:
I'm copying this over from the freebsd-performance list, as I'm
looking for a few more opinions - not on the problems *I* am having,
but rather to check whether the problem is universal or not, and if
not, fi
On Oct 13, 2009, at 12:35 AM, Luigi Rizzo wrote:
On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote:
I'm copying this over from the freebsd-performance list, as I'm
looking for a few more opinions - not on the problems *I* am having,
but rather to check whether the problem is unive
On Mon, Oct 12, 2009 at 09:48:42PM +0200, Thomas Backman wrote:
> I'm copying this over from the freebsd-performance list, as I'm
> looking for a few more opinions - not on the problems *I* am having,
> but rather to check whether the problem is universal or not, and if
> not, find a possible
o: "freebsd-stable"
Sent: Monday, October 12, 2009 8:48 PM
Subject: Extreme console latency during disk IO (8.0-RC1,previous releases also
affected according to others)
I'm copying this over from the freebsd-performance list, as I'm looking for a few more opinions - not on the
I'm copying this over from the freebsd-performance list, as I'm
looking for a few more opinions - not on the problems *I* am having,
but rather to check whether the problem is universal or not, and if
not, find a possible common factor.
In other words: I want to hear about your experiences,
Hi, Colin. Any news/thoughts on where we are with this?
--
Jo Rhett
Net Consonance : consonant endings by net philanthropy, open source
and other randomness
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/f
On Sep 25, 2008, at 9:32 AM, Lowell Gilbert wrote:
I'm not clear on how this helps. We don't know if there will be a
need to produce a 6.5 release, so there's no way to judge whether 6.4
should be designated "final" or not. The only logical answer is to do
so, which leaves a substantial chance
Jo Rhett <[EMAIL PROTECTED]> writes:
> Each branch is supported by the Security Officer for a limited time
> only, and is designated as one of `Early adopter', `Normal', or
> Final'. The designation is used as a guideline for determining the
> lifetime of the branch as follows.
I'm not clear on h
On Tue, 2008-09-23 at 13:37 -0700, Jo Rhett 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.
A release which is not the final minor release of a branch will
be additionally
ed'. The designation is used as a guideline for determining
> > the lifetime of the branch as follows.
> >
> > Early adopter
> > Releases which are published from the -CURRENT branch will be
> > supported by the Security Officer for a minimum of 6 month
, rather than waiting
until a decision about the support policy is made.
Repeat from the top: nobody is demanding anything. I think this policy
would make a lot more sense, and would promote forward movement. Feel
free to correct me if we overlooked anything. Thanks.
I read the whole thread
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
> up
On Sep 23, 2008, at 4:45 PM, Colin Percival wrote:
jonathan michaels wrote:
On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote:
Some quite lively offline discussion has come to conclusion with
the following suggestions to change the support policy.
Obviously, this is what we feel wo
jonathan michaels wrote:
On Tue, Sep 23, 2008 at 01:37:03PM -0700, Jo Rhett wrote:
Some quite lively offline discussion has come to conclusion with the
following suggestions to change the support policy. Obviously, this
is what we feel would be a good idea, but it's obviously open to
discu
7;, or
> 'Final'. The designation is used as a guideline for determining the
> lifetime of the branch as follows.
>
> Early adopter
> Releases which are published from the -CURRENT branch will be
for support of my hardware and any 'new' machines that might
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 i
;better".
Old text:
Each branch is supported by the Security Officer for a limited time
only, and is designated as one of `Early adopter', `Normal', or
`Extended'. The designation is used as a guideline for determining
the lifetime of the branch as follows.
Early adopt
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 a
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 a
actually promoting the idea of skipping releases. This may not be a
good idea -- it was just a toss out there, but it makes a lot more
sense than the existing policy. Could you at least respond to the
issues raised here?
--
Jo Rhett
Net Consonance : consonant endings by net philant
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
stated support for 6.4 if
it turns out not to be the last release - that would then apply to 6.5.
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'
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
;m 1/4 of a person in this context?
(assuming there was enough trust/etc that I could even do the work --
just for discussion)
Tricky balance -- if you cut a major release every 18-24 months, you
have a 24-month support cycle on the final point release on each
branch, and you continue to rele
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 multip
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) i
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 securi
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
very 18-24 months, you have a
24-month support cycle on the final point release on each branch, and you
continue to release minor releases after the .0 of the next branch in order to
allow .0's to settle for a bit before forcing migration forward, it's hard not
to end up in the many-b
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
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
RELENG_X_Y_Z_RELEASE never changes. That tag gives you the same bits that
are on the FreeBSD X.Y.Z install CD.
RELENG_X_Y is the secu
24+ months from its
>> last production release? Smaller periods of support could be given to minor
>> releases along the way (7.2, for example), but at least companies would know
>> that if they installed a 6.x version, they'd have support for a couple of
>> years, even if tha
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
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
fferent: rather than saying
"Sorry, 6.2 is vulnerable, please upgrade to 6.3", we say "You can live
on 6.2 for up to 18 months and receive *only* security and critical
errata patches".
Don't get me wrong: I would love to see us support all releases for 24
months (or even mo
ion is from my "world view". It's entirely
possible I miss some parts, have forgotten, or remember incorrectly.
OK, before being able to say what is required for support, we need to
define "support".
Currently the entities which has a defined support for releases is the
FreeB
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
the vulnerabilities that would arise, and
the degree to which conservative highly incremental changes could be used to
support a branch long after release. The problem is that the 18 months for
all releases + extra time for extended support releases is still a short
period of time. The tensi
d the release team said
this was all they could do with the resources they have. No further
information has been provided.
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
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?
1 - 100 of 293 matches
Mail list logo
