Upcoming Releases Schedule...

Doug Barton dougb at FreeBSD.org
Mon Sep 22 21:56:09 UTC 2008

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
>> then the most you get is security fixes.  No new features,
>> no new drivers, no bugfixes.  So if I am interpreting things
>> correctly, you are asking for security fixes to be ported to
>> RELEASE tagged branches for longer?
> That is what I and my $EMPLOYER want yes, although as I said I am
> willing to support other efforts.  (ie I am unlikely to be the
> difference between make or break on this effort, so if more support was
> something that got other businesses involved enough to achieve that
> change, then....)

Just to be clear, what you are interested in is a longer support period
for security patches to be merged into a branch such as RELENG_6_3
(which only has security fixes applied to it now). Is that correct?

Assuming that I'm correct on that assumption, I would suggest that you
gather a community of people who share a similar interest and quite
simply do the work. It should be pretty obvious based on any given
security advisory what will need to change, and if you get enough people
involved there won't be that much work for any one person or company.

There is even a mailing list for this sort of thing, freebsd-eol. It's
not very active right now, but that doesn't mean you can't change that.
As Robert pointed out, project history is such that those who identify a
given need and fill it are generally "absorbed" into the "official"
canon as it were, so at some point in the future you (pl.) might
actually become part of the answer to the "more resources" questions
that you keep insisting on an answer to.

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 advance how long that release will be
supported. Several people (including Robert, who is part of the release
team) have said that we can't make a firm conclusion on how long a given
release will be supported until we have a pretty good idea how
"successful" a given release will be, which requires people actually
testing and using it. Do you see the problem?

Finally I would like to suggest that everyone interested in the problems
of supporting releases for longer than their announced EOL to please
take that discussion to the freebsd-eol list. AFAICT it isn't really on
topic for -stable.




    This .signature sanitized for your protection

More information about the freebsd-stable mailing list