HEADS UP: Release schedule for 2006
Scott Long
The following is the approximate schedule for FreeBSD releases in 2006:
Jan 30: Freeze RELENG_5 and RELENG_6
Mar 20: Release FreeBSD 6.1
Apr 3: Release FreeBSD 5.5
Jun 12: Freeze RELENG_6
Jul 31: Release FreeBSD 6.2
Oct 23: Freeze RELENG_6
Dec 11: Release FreeBSD 6.3
A 'freeze' means that the tree will be closed to changes except with
specific approval, and the focus will be on producing, testing, and
fixing release candidates. The release dates are targets that we hope
to make, but we will continue with the policy of only releasing once
all of the showstoppers are cleared, i.e. we will release when it is
ready.
FreeBSD 5
5.5 will be the final release from the RELENG_5 tree. We are doing it
to provide support for users who have committed to FreeBSD 5 and who
need more time to transition to FreeBSD 6. However, in order to keep
forward progress with FreeBSD 6, we will produce this in parallel with
the 6.1 release, and thus it will not be our main focus. Users who are
using FreeBSD 5 are strongly encouraged to evaluate FreeBSD 6. After
this final release, the security team will provide security update
support through 2007.
FreeBSD 6
There will be three FreeBSD 6 releases in 2006. It will be our primary
focus for bugfixes, performance enhancements, and incremental
functionality and driver additions. There will likely be one more
release in 2007, after which we will begin focus on FreeBSD 7.
FreeBSD 7
We will start preparing for FreeBSD 7.0 in June 2007.
I'll hopefully update the release engineering pages soon to reflect
this. If you have any questions, please feel free to contact me and the
rest of the release engineering team. Thanks!ott
Scott
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Scott Long
> are at least up to 5.3; my laptop is happy at 5.4. I have
> what I believe to be a rationalquestion. Why should I go
> beyond v5.5? More to the point, why can't minor security
> tweaks be maintained indefinitely for 5.5?
Security updates will be maintained for quite a while. However, it
takes manpower to test each proposed security change, so it's very hard
to justify doing them 'indefinitely'. The stated policy from the
security team is 2 years. So they will probably support 5.5 into
2008, but I wanted to be conservative in my statement in case they
have different plans.
> What will
> releases -6 and -7 offer that can;t reasonably be dropped
> into -5?
Significant performance and stability enhancements that simply cannot
be broken up and backported to FreeBSD 5. We are marching towards a
'Giant-less' kernel, which means continuing better SMP performance and
better UP responsiveness. With 6.0 we are finally starting to see the
benefit of the SMPng work that we've been doing for 5 years.
Joao Barros
> FreeBSD 7
> We will start preparing for FreeBSD 7.0 in June 2007.
>
> I'll hopefully update the release engineering pages soon to reflect
> this. If you have any questions, please feel free to contact me and the
> rest of the release engineering team. Thanks!ott
There have been some questions on the lists about what to expect from
release x.y and I personnally have always looked at the TODO list like
http://www.freebsd.org/releases/6.0R/todo.html
For 6.0 I noticed there were more updates on that page for bugs and
their fixes than for features per se. My sugestion, maybe at a first
stage setting the TODO list has it's advantages, one knows what to
expect from a release, it's clearly stated and documented there and
the developers can see their goals.
This is valid for minor and major releases of course.
How about it?
--
Joao Barros
Scott Long
> On Fri, Dec 16, 2005 at 02:59:09PM +0000, Joao Barros wrote:
>
>>On 12/16/05, Scott Long <sco...@samsco.org> wrote:
>>
>>
>>>FreeBSD 7
>>>We will start preparing for FreeBSD 7.0 in June 2007.
>>>
>>>I'll hopefully update the release engineering pages soon to reflect
>>>this. If you have any questions, please feel free to contact me and the
>>>rest of the release engineering team. Thanks!ott
>>
>>There have been some questions on the lists about what to expect from
>>release x.y and I personnally have always looked at the TODO list like
>>http://www.freebsd.org/releases/6.0R/todo.html
>>For 6.0 I noticed there were more updates on that page for bugs and
>>their fixes than for features per se. My sugestion, maybe at a first
>>stage setting the TODO list has it's advantages, one knows what to
>>expect from a release, it's clearly stated and documented there and
>>the developers can see their goals.
>>This is valid for minor and major releases of course.
>>
>>How about it?
>>
>
>
> every N months? I think it's a great idea to have some
> clues about where we're going, or hope to be going.
>
> gary
>
>
>
>
The release TODO list is maintained on the FreeBSD.org website, though
it's usually only active during release cycles. I used to also email it
out in text format to the mailing lists on a weekly basis.
Scott
Wilko Bulte
> On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
>
> release cycle and come up with a binary update mechanism supported well by
> the OS? Increasing the speed of releases is good. Increasing the number
> of deployed systems out of date because there are no easy binary upgrade
> mechanisms is bad.
>
> It has been bad, it's getting worse.
So, when will you fix it? Or hire someone to fix it? FreeBSD after
all is mostly a volunteer operation.
--
Wilko Bulte wi...@FreeBSD.org
Uwe Laverenz
> So, when will you fix it? Or hire someone to fix it? FreeBSD after
> all is mostly a volunteer operation.
Yes, this certainly is correct, and many users think this way. This
might be the reason why we don't hear or read much about the existing
problems and annoyances with FreeBSD, people just stay quiet. The
problem is that this doesn't help to make things better, because many
users will simply vote with their feet and quit using FreeBSD.
Uwe
Peter Jeremy
>I agree. And after all, tracking a security branch isn't too difficult,
...
># cd /usr/src
># patch < /path/to/patch
># cd /usr/src/gnu/usr.bin/cvs/cvsbug
># make obj && make depend && make && make install
># cd /usr/src/gnu/usr.bin/send-pr
># make obj && make depend && make && make install
>
>Is that difficult?
Speaking as a developer, I think it's trivially easy.
As an end user, I don't think this is acceptable. Firstly, it
requires that the user has installed the src distribution - which is
optional. Secondly, the user is expected to use development tools
without understanding what they do - this is scary for them. Running
the above commands is OK as long as nothing goes wrong but the
"support" group (who inhabit -questions and answer seemingly silly
questions) are going to have to cope with people who've made a typo
somewhere in the sequence and can't explain exactly what they did -
without putting them off FreeBSD.
I think FreeBSD Update shows the way forward but IMHO there needs to
be an "official" binary update tool accessible from www.freebsd.org.
--
Peter Jeremy
Kris Kennaway
> On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
>
> release cycle and come up with a binary update mechanism supported well by
> the OS? Increasing the speed of releases is good. Increasing the number
> of deployed systems out of date because there are no easy binary upgrade
> mechanisms is bad.
>
> It has been bad, it's getting worse.
Suggestions are nice, but who do you think will work on solving this?
Kris
Chuck Swiger
> On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
>
> release cycle and come up with a binary update mechanism supported well by
> the OS? Increasing the speed of releases is good. Increasing the number
> of deployed systems out of date because there are no easy binary upgrade
> mechanisms is bad.
>
> It has been bad, it's getting worse.
YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an
IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries,
including X11, KDE, printing, Mozilla, etc worked just fine.
Upgrading the ports from there was somewhat annoying, as this guy's machine had
~400 or so, but deleting them all, and then using "pkg_add -r " works just fine
if you want to grab the latest current binaries. From there you can portupgrade
as usual.
Now, if you want to talk about upgrading to intermediate patch releases, you've
got a valid point there. :-)
--
-Chuck
Scott Long
> On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote:
>
>>I agree. And after all, tracking a security branch isn't too difficult,
>
> ...
>
>># cd /usr/src
>># patch < /path/to/patch
>># cd /usr/src/gnu/usr.bin/cvs/cvsbug
>># make obj && make depend && make && make install
>># cd /usr/src/gnu/usr.bin/send-pr
>># make obj && make depend && make && make install
>>
>>Is that difficult?
>
>
> Speaking as a developer, I think it's trivially easy.
>
> As an end user, I don't think this is acceptable. Firstly, it
> requires that the user has installed the src distribution - which is
> optional. Secondly, the user is expected to use development tools
> without understanding what they do - this is scary for them. Running
> the above commands is OK as long as nothing goes wrong but the
> "support" group (who inhabit -questions and answer seemingly silly
> questions) are going to have to cope with people who've made a typo
> somewhere in the sequence and can't explain exactly what they did -
> without putting them off FreeBSD.
>
> I think FreeBSD Update shows the way forward but IMHO there needs to
> be an "official" binary update tool accessible from www.freebsd.org.
>
FreeBSD Update was written by, and is continuously maintained by the
actual FreeBSD Security Officer. It's as official as it gets. If
the only barrier to acceptance is that it's not distributed from the
FreeBSD.org domain, then a) that's a silly argument, and b) it's easily
solvable so long as Colin agrees.
Scott
Matthew D. Fuller
Joe Rhett, and lo! it spake thus:
>
> Increasing the number of deployed systems out of date [...]
This doesn't make any sense. If you install a 6.0 system, in 6 months
(assuming you installed it right when 6.0 was cut, for simplicity), it
will be 6 months out of date. It's neither more nor less out of date
if the current release is then 6.1, or 6.2, or 8.12; it's still 6
months back.
A case could, in fact, be made that more common releases lead to far
FEWER deployed systems out of date, since it makes it far easier for
those who already use binary upgrades instead of source to get things
faster.
Now, this is not to say that easier incremental binary upgrades are a
bad thing, but bad analogy doesn't help anybody...
--
Matthew Fuller (MF4839) | full...@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Erich Dollansky
Scott Long wrote:
> Peter Jeremy wrote:
>
>> I think FreeBSD Update shows the way forward but IMHO there needs to
>> be an "official" binary update tool accessible from www.freebsd.org.
>>
>
> FreeBSD Update was written by, and is continuously maintained by the
> actual FreeBSD Security Officer. It's as official as it gets. If
> the only barrier to acceptance is that it's not distributed from the
> FreeBSD.org domain, then a) that's a silly argument, and b) it's easily
> solvable so long as Colin agrees.
>
isn't this the problem Microsoft faces all the while when users download
the latest security patch from somewhere in the Internet?
Teaching water and drinking wine?
Erich
Matthew Seaman
> Upgrading the ports from there was somewhat annoying, as this guy's machine had
> ~400 or so, but deleting them all, and then using "pkg_add -r " works just fine
> if you want to grab the latest current binaries. From there you can portupgrade
> as usual.
>
> Now, if you want to talk about upgrading to intermediate patch releases, you've
> got a valid point there. :-)
Doesn't creating a binary updates system that's going to be practical to use
require implementation of that old and exceedingly bikesheddable subject: packaging
up the base system? After all, you're going to need some mechanism for auditing
servers down the line (yes, this machine has had the vital fix to the foo daemon applied), and while bumping the patch level on the release sorta works to do that,
it implies a new kernel and a reboot for each patch applied if it's going to be
visible.
Cheers,
Matthew
--
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
Chris Gilbert
> YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade
> on an IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x
> binaries, including X11, KDE, printing, Mozilla, etc worked just fine.
>
> Upgrading the ports from there was somewhat annoying, as this guy's machine
> had ~400 or so, but deleting them all, and then using "pkg_add -r " works
> just fine if you want to grab the latest current binaries. From there you
> can portupgrade as usual.
>
> Now, if you want to talk about upgrading to intermediate patch releases,
> you've got a valid point there. :-)
I've had some success with this as well, but doing a pkg_add -r then mixing
that with ports (if the ports are cvsuped to head and not to the release
branch you installed) can cause issues.
One particular issue is in regards to gnome/gtk/glib applications.
They have some sort of crazy library name bumping for each version, and you
will get lots of crap like "libgnomeui.so.400 not found" if you have binary
libs/apps from pkg_add which are trying to link to libraries installed via
an updated ports.
However, this behavior seems to have gotten better recently with the latest
glib, I don't see as many libfoo.so.<3 digit number> rather I see stuff like
libglade-2.0.so.0. (which is much better!)
Maybe this should be directed toward the FreeBSD Gnome team, but it can get
really out of hand when you update ports and try to update/install some small
gtk app, then it wants to get latest gnomevfs, which will want to update gtk,
which will want to update glib.... and then because of the library naming you
have to remove every single glib/gtk/gnome app and recompile them all from
ports. (can't use packages since they will be out of sync here)
I tried installing a small game called gtetrinet a couple weeks ago (with a
perfectly functioning GTK/glib install) and ended up spending 4 hours
tracking down tons of libs/apps which used these libraries or a library that
depends on said libraries.
Also, I'm aware that there is a gnome update script... however it's possible
for things to go really wrong if a user inadvertently uses portupgrade or a
port which gets pulled into this mess. (There was a huge warning label in the
glib port at one point saying "DON'T DO THIS USE THE SCRIPT")
And that still doesn't solve the problem with desktop users who just want to
grab binaries and install them... my Wife was unlucky enough to have this
happen to her, and even though she has been using FreeBSD successfully for a
few years, it trashed her dependency tree to the point where I just had to
nuke most of her applications and recompile everything for her. (Not good!)
Perhaps this subject should be moved to another list and focused on what would
be a good way to create a stronger package/binary management and updating
system for FreeBSD? (That plays nicely with ports, and also handles
kernel/world/security updates)
--
Regards,
Chris Gilbert
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Brian Candler
> And that still doesn't solve the problem with desktop users who just want to
> grab binaries and install them... my Wife was unlucky enough to have this
> happen to her, and even though she has been using FreeBSD successfully for a
> few years, it trashed her dependency tree to the point where I just had to
> nuke most of her applications and recompile everything for her. (Not good!)
Here here!
I recently tried to upgrade Mozilla from 1.0.7 to the current ports version
(1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways,
and I ended up having to portupgrade almost everything. That then broke me
in all sorts of other ways, like finding that 'unison' was upgraded and its
protocol was no longer compatible with 'unison' on other systems, so they
needed upgrading too. Plus I had to remember to abort the upgrade before it
started rebuilding openoffice, to avoid my system becoming polluted with
java...
I have no problem with libraries called libgtk.so.400 or whatever, but the
whole point of this scheme is that it should be possible to have multiple
versions installed at the same time.
So, if the new Mozilla port really requires the newest version of gtk, then
it should simply go build that version of gtk and install it alongside my
existing version, so all the ports linked against the older versions
continue to work. Setting FORCE_PKG_REGISTER might do this, but if that
works so well, why is it not the default? And then there are various flags
to portupgrade / pkg_install which explicitly tell them to leave stale
versions of shared libraries around, 'just in case' they are needed.
> Perhaps this subject should be moved to another list and focused on what would
> be a good way to create a stronger package/binary management and updating
> system for FreeBSD? (That plays nicely with ports, and also handles
> kernel/world/security updates)
I'd like to see that.
I think Dragonfly have some good ideas, like using the filesystem to build a
virtual library environment on the fly. That is, when an application runs it
sees a /lib directory populated with only the libraries it needs, and the
exact versions of them. Extending this so that it is possible to have
multiple versions of the same application (/usr/bin/foo) installed, for
instant upgrade and rollback, would be even better. (I know there are
existing solutions which install lots of symlinks, and some ideas can
probably be taken from those too)
Regards,
Brian.
Daniel O'Connor
> I recently tried to upgrade Mozilla from 1.0.7 to the current ports version
> (1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways,
> and I ended up having to portupgrade almost everything. That then broke me
> in all sorts of other ways, like finding that 'unison' was upgraded and its
> protocol was no longer compatible with 'unison' on other systems, so they
> needed upgrading too. Plus I had to remember to abort the upgrade before it
> started rebuilding openoffice, to avoid my system becoming polluted with
> java...
>
> I have no problem with libraries called libgtk.so.400 or whatever, but the
> whole point of this scheme is that it should be possible to have multiple
> versions installed at the same time.
In an ideal world this would all Just Work (tm).
Unfortunately, developers don't have infinite resources so you experience
problems like you are seeing.
It doesn't help that there is almost no binary compatibility between various
releases of libraries (GNOME is really good for doing this in my experience).
> So, if the new Mozilla port really requires the newest version of gtk, then
> it should simply go build that version of gtk and install it alongside my
> existing version, so all the ports linked against the older versions
> continue to work. Setting FORCE_PKG_REGISTER might do this, but if that
> works so well, why is it not the default? And then there are various flags
> to portupgrade / pkg_install which explicitly tell them to leave stale
> versions of shared libraries around, 'just in case' they are needed.
I think the reason it isn't the default is because it pollutes your disk with
multiple copies of things that may not be necessary. In a lot of cases it
will cause weird errors (eg one binary ends up with more than one version of
a library linked to it at run time because its dependents weren't all
upgraded)
> I think Dragonfly have some good ideas, like using the filesystem to build
> a virtual library environment on the fly. That is, when an application runs
> it sees a /lib directory populated with only the libraries it needs, and
> the exact versions of them. Extending this so that it is possible to have
> multiple versions of the same application (/usr/bin/foo) installed, for
> instant upgrade and rollback, would be even better. (I know there are
> existing solutions which install lots of symlinks, and some ideas can
> probably be taken from those too)
I don't see how this can fix the problem where you have a program that depends
on 2 libraries and each of those depend another library. If they are linked
to 2 different versions of that 3rd library you can get very odd behaviour.
This *is* an annoying problem, but the solutions are far from simple..
(Lots more man power would help)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Brian Candler
> This *is* an annoying problem, but the solutions are far from simple..
Agreed - and I was mainly agreeing to the suggestion to take this off-list.
Perhaps each of the possible solutions could be stuck onto a wiki whiteboard
so that they could be annotated with their strengths and weaknesses.
Spil Oss
can only say
Please add this kind of information to the Handbook
Any addition to the handbook on tracking down problems and smarter
ways to fix things would be greatly appreciated. I found myself
recompiling my kernel to test changes to a device's driver, but now
you tell me I could have done that a lot smarter!
Whenever I get my 'knickers-in-a-twist' when using FreeBSD my first
point of reference is 'The Handbook'. Any additional information in
there would greatly be appreciated.
Learning-curve is very, very steep when you're used to lslpp and
windowsupdate to patch your system. I _do_ appreciate that most
developers and users are very experienced in using FreeBSD, but that
makes it increasingly difficult for the not-so-fortunate to come up to
speed with the use of FreeBSD.
Spil.
On 12/17/05, Kövesdán Gábor <gabor.k...@t-hosting.hu> wrote:
> Wilko Bulte wrote:
>
> >On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote..
> >
> >
> >>On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote:
> >>
> >>
> >>>There will be three FreeBSD 6 releases in 2006.
> >>>
> >>>
> >>While this is nice, may I suggest that it is time to put aside/delay one
> >>release cycle and come up with a binary update mechanism supported well by
> >>the OS? Increasing the speed of releases is good. Increasing the number
> >>of deployed systems out of date because there are no easy binary upgrade
> >>mechanisms is bad.
> >>
> >>It has been bad, it's getting worse.
> >>
> >>
> >
> >So, when will you fix it? Or hire someone to fix it? FreeBSD after
> >all is mostly a volunteer operation.
> >
> >
> >
> I agree. And after all, tracking a security branch isn't too difficult,
> but the most people think that they have to do a complete "make
> buildworld" after a security advisory, but this isn't true. For example
> there was that cvsbug issue in September:
> ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug.asc
> One can read here:
>
> b) Execute the following commands as root:
>
> # cd /usr/src
> # patch < /path/to/patch
> # cd /usr/src/gnu/usr.bin/cvs/cvsbug
> # make obj && make depend && make && make install
> # cd /usr/src/gnu/usr.bin/send-pr
> # make obj && make depend && make && make install
>
> Is that difficult? I don't think so. No reboot required and it doesn't
> take more than 5 minutes even on a slower machine. Only the
> vulnerabilities in the kernel are problematic for servers, since they
> require a reboot. I think I'll submit a PR with a patch to clarify this
> in Handbook. Do you consider this useful?
>
> Regards,
>
> Gabor Kovesdan
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"
Brooks Davis
> On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote:
> > all is mostly a volunteer operation.
>
> repeatedly stated that they won't integrate the efforts, which makes
> os-upgrade capability minimal and easily broken. (see current efforts)
This statement makes no sense. The core team wouldn't have much to
do with this other than possibly being involved in making any service
official. Also, approval is never given to include a non-existent
feature. Easy, binary updates sound like a great idea, but without
seeing actual code thats all anyone can say other than offering advice.
If volunteering is conditional on acceptance of the work, that's a
chicken-egg problem and is not resolvable. We simply can't maintain
quality if we accept non-existent code just because the idea sounds
good.
-- Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
Matthew D. Fuller
Jo Rhett, and lo! it spake thus:
>
> No, you're missing the point. More core OS upgrades means less
> incremental patches (which are easier to apply than a full update).
Right. I don't understand how B follows A here.
These patches come from where? Security advisories, mailing list
discussions, and eating too much beef right before bed and waking up
at 2am with brilliant ideas? Why would there be less of them, just
because RELENG_X_Y_RELEASE tags are laid down more often?
> Huh? That's backwards. If we can't schedule the downtime for a
> full operating system upgrade (which takes far longer than it
> should) then the system won't get upgraded.
Having done full OS upgrades a number of times, I can't remember the
last time it took more than 5 or 10 minutes (during most of which the
system can keep running its normal services, just a little more
crunched on CPU or I/O). Well, OK, I can; it was when I moved servers
from 2.2.x to 4.x. But that's a rather exceptional case, and next
time THAT happens, I'm darn well using it as an excuse to strongarm
new hardware out of somebody and replace the server at the same
time...
> Not to be rude, but I think your definition of analogy is wrong.
No, you're right. "Hyperbole" was probably a better word, but even
that doesn't quite fit. My ability to find the right word is flaky at
times. I don't understand the basis of your assertion that more
common tagging means suddenly you can't apply individual patches.
> Back to the point, the comments aren't "bad". Your idea that binary
> operating system upgrades from ISO are "easier" demonstrates that
> you're talking about home computers, not production servers.
Oh, no. Heck, I find that upgrades from SOURCE are "easier". In
fact, just last month I bought my first CD burner, so it wasn't until
a few weeks ago that I even burned my first ISO (and that, just to
test the burner and figure out how to do it), and I've never booted or
installed off one. For small groups of servers, I NFS mount
installworlds, and for larger groups, I rdist out binaries. But it
always comes from source.
Peter Jeremy
>I and many others have offered to work on this. The core team has
>repeatedly stated that they won't integrate the efforts, which makes
>os-upgrade capability minimal and easily broken. (see current efforts)
On Thu, 2005-Dec-22 14:05:32 -0800, Jo Rhett wrote:
>On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote:
>> This statement makes no sense. The core team wouldn't have much to
>> do with this other than possibly being involved in making any service
>> official. Also, approval is never given to include a non-existent
>> feature. Easy, binary updates sound like a great idea, but without
>> seeing actual code thats all anyone can say other than offering advice.
>> If volunteering is conditional on acceptance of the work, that's a
>> chicken-egg problem and is not resolvable. We simply can't maintain
>> quality if we accept non-existent code just because the idea sounds
>> good.
>
>What are you talking about? These issues have been repeatedly brought up
>in the mailing lists, and what it would require to make it possible to
>handle appropriately (namely, core os packages or a similar versioning
>mechanism) and the arguements have often been given.
I agree with Brooks. I don't recall ever seeing a message from -core
(or anyone else talking on behalf of the Project) stating that code to
make binary updates possible would not be integrated. For that matter,
I don't recall ever seeing code offered to implement such a feature.
Core OS packages have been discussed but I don't recall the idea ever
being vetoed. Some work have been done in breaking bits of the base OS
out into packages (perl, games and UUCP come to mind) but packaging the
entire system is a major undertaking. In any case, I don't see how
packaging the system would help you. Taking Solaris as an example of
an OS which is broken up into lots of packages, patches don't replace
whole packages, they replace individual files.
--
Peter Jeremy
Peter Jeremy
>But FreeBSD Update suffers from all of the same limitations that I've been
>describing because of lack of integration with the Core OS.
>
>1. modified kernels are foobar
> ..yet are practically mandatory on production systems
>
>2. modified sources are foobar
> ..yet many common production situations require source compilation options
So you want to be able to make arbitrary changes you your source code
and compilation options and then expect the FreeBSD project to provide
a tool that will apply binary fixes to the resultant executables?
I don't know that modified kernels are mandatory. A lot of work has
been going on to reduce the need to re-compile the kernel for common
situations. Likewise, I don't know that "many common" and "require"
go together - IMHO, 'desire' or 'would be nice' are more appropriate
descriptions. Would you care to provide some details of what you
believe can be done to reduce your need to re-compile the OS.
I'm not sure that FreeBSD Update is totally unusable for you. If you
have the situation where you have a modified FreeBSD that you need to
roll out to a large number of hosts, you just need to have your own
FreeBSD Update server - you test the changes in your environment and
then roll them out as you require.
AFAIK, Colin hasn't fully productised FreeBSD Update to date but has
not rejected the idea of doing so.
>3. FreeBSD Update can't handle updates of jails and other situations that
>package systems deal with just fine.
I don't run jails so I'm not familiar with the problems here. Maybe you'd
like to explain the problems you run into.
--
Peter Jeremy
Matthew D. Fuller
On Fri, Dec 23, 2005 at 10:02:51AM +0000 I heard the voice of
Brian Candler, and lo! it spake thus:
>
> That's good for you and a certain clan of highly experienced FreeBSD
> system administrators. However I believe that there's a far larger
> pool of people for whom binary installs and upgrades makes much more
> sense.
Oh, yes. I've almost precisely zero interest in such things myself,
but I'm quite aware that other people want them for both irrational
and thoroughly sensible reasons. Me, I don't remember the last time
ANY system I ran was on a -RELEASE longer than it took to install and
pull up to the latest along whatever branch I thought appropriate for
it, but that's me. With any luck, none of the people gasping in
horror and calling for smelling salts at the thought will ever know
what services they use end up coming from boxes I control 8-}
I'm just in this fray for kicks, because I think the "BSD will implode
if we start releasing more often without this" perspective is a little
nutty. I don't see how it really makes anything materially worse than
it currently is for that group of people (sure, it may be pretty bad
now, but I don't really buy that releasing more often makes it all
that much worse).
Colin Percival
> I think the real concern here is: for how long after RELEASE_X_Y are binary
> patches for it made available?
I build FreeBSD Update patches for all the branches supported by the
FreeBSD Security Team.
To answer a couple of other questions:
FreeBSD Update is something which I _personally_ support; it isn't
supported by the _project_, because at the moment there isn't anyone
else who could take over running it if I get hit by a bus.
Re the long list of requests people have made (starting with "amd64
support" and "make this officially supported by the project"), I'll
get to those as soon as I have time. Sadly, I have a pesky thing
called "a full time job" and my FreeBSD time has been occupied with
portsnap lately.
Colin Percival
Joseph Koshy
phk> version control brought to programming.
www.infrastructures.org
www.isconf.org
--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
Ed Maste
> Linux has an extremely neat solution for this (sshfs) but I don't know of
> anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in
> architecture which allows filesystems to run in userland. I believe it makes
> an sftp connection to the remote host, and then exposes it as if it were a
> real filesystem.
In fact, FreeBSD's got Fuse & sshfs as well. Csaba Henk did the port
as a Google SoC project. See <http://fuse4bsd.creo.hu/> and
/usr/ports/sysutils/fusefs* .
--
Ed Maste
Sandvine Incorporated
Brian Candler
> On Sat, Dec 24, 2005 at 03:32:18PM +0000, Brian Candler wrote:
>
> > Linux has an extremely neat solution for this (sshfs) but I don't know of
> > anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in
> > architecture which allows filesystems to run in userland. I believe it makes
> > an sftp connection to the remote host, and then exposes it as if it were a
> > real filesystem.
>
> In fact, FreeBSD's got Fuse & sshfs as well. Csaba Henk did the port
> as a Google SoC project. See <http://fuse4bsd.creo.hu/> and
> /usr/ports/sysutils/fusefs* .
Looks like very recent work. Thanks for the pointer - although it seems it's
not available for FreeBSD <6.0 unfortunately.
John-Mark Gurney
> > You are putting words in the mouth of core@ -
>
> Sorry. As said before, the topic is always struck down and nobody from
> core has ever stood up to say "we'll support this". I don't know whose on
> core this week, nor will I at any given time. I just know that core has
> either struck it down or been Silent.
I believe core has a policy of never supporting vaporware... There is
always the chicken and egg problem with arguments like this... I'll
code this if you agree to support it and maintain it/I will agree to
support it once you code it... In FreeBSD, and many open source
projects, no code, no support, how can you support or even agree to
support something that doesn't exist? And then as soon as FreeBSD
agrees to support something that doesn't exist, either a) other people who
were interested in the project stop, even if you end up never producing
a bit of code, or b) someone else produces better code, drops the
support for the original, but then the author complains about being
told they'd support his code, and going with another code base...
Bottom line: Once code exists, then support can be talked about..
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Joseph Koshy
ml> in the project. Hint: it is not primarily technical in nature.)
For those curious to know how the project works, the following online
resources may help:
A project model for the FreeBSD Project
http://www.freebsd.org/doc/en_US.ISO8859-1/books/dev-model/index.html
The FreeBSD development process: a case study
http://www.cs.colostate.edu/puml/pub/FreeBSD_TSEVersion.pdf
The FreeBSD Committers Guide
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/
--
FreeBSD Volunteer, http://people.freebsd.org/~jkoshy
Eric Anderson
>On Thu, 12 Jan 2006 18:07, Jo Rhett wrote:
>
>
>>On Fri, Jan 06, 2006 at 10:20:11PM +1030, Daniel O'Connor wrote:
>>
>>
>>>I imagine there are a few committers interested, but I'd say you need to
>>>ask the right way first..
>>>
>>>
>>As in...?
>>
>>
>
>I don't know any personally, but then again I only know about 3 committers
>which is not a large percentage.
>
>
>
>>But again, there are lots of people interested in this topic. Colin for
>>an obvious one. But if Colin can't convince the team to take this on,
>>where do you start?
>>
>>
>
>Colin is a committer.
>You write the code under his guidance.
>He commits it.
>
>So, there you go, problem solved.
>
>
That's true, if you can find a committer willing to help - and I think
that's the issue. I've tried numerous times to contact committers of
certain areas, asking quick questions, or things like 'if I build this,
would it be comittable?' - with about 80% of the time receiving no
response. Now, I'm not complaining, or claiming they should reply -
they are volunteers and already busy doing their regular life stuff in
addition to the FreeBSD code they contribute. I'm just mentioning it as
a data point, that it is pretty hard to find a committer willing to
mentor someone, or at a minimum, give them pointers. The -hackers list
is excellent as far as answering most technical questions (rapidly!),
but in the end, it is pretty difficult to find a committer to listen to
you, unless you already have patches ready to roll, since that takes
less time of course.
Maybe, on the FreeBSD developers page, we could have a list of
categories and mentors for those categories for those willing to work on
code to contact with questions, etc. Then committers could volunteer as
a mentor for a category they enjoy.. Or is it enough to just post to
-hackers asking 'anyone want to mentor me?' ?
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
Gleb Smirnoff
On Thu, Jan 12, 2006 at 07:13:46AM -0600, Eric Anderson wrote:
E> That's true, if you can find a committer willing to help - and I think
E> that's the issue. I've tried numerous times to contact committers of
E> certain areas, asking quick questions, or things like 'if I build this,
E> would it be comittable?' - with about 80% of the time receiving no
E> response. Now, I'm not complaining, or claiming they should reply -
E> they are volunteers and already busy doing their regular life stuff in
E> addition to the FreeBSD code they contribute. I'm just mentioning it as
E> a data point, that it is pretty hard to find a committer willing to
E> mentor someone, or at a minimum, give them pointers. The -hackers list
E> is excellent as far as answering most technical questions (rapidly!),
E> but in the end, it is pretty difficult to find a committer to listen to
E> you, unless you already have patches ready to roll, since that takes
E> less time of course.
First you should to check whether given person is active now in CVS and/or
mailing lists. If he is not, then you have a lesser chance to get answer.
If he is active, then don't hesitate to ask for help. And don't be afraid
to send a reminded, if discussion freezes.
And don't forget that email goblins can eat your email. This is quite often
a reason for "ignoring", at least for myself.
E> Maybe, on the FreeBSD developers page, we could have a list of
E> categories and mentors for those categories for those willing to work on
E> code to contact with questions, etc. Then committers could volunteer as
E> a mentor for a category they enjoy.. Or is it enough to just post to
E> -hackers asking 'anyone want to mentor me?' ?
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Eric Anderson
> Eric,
>
>On Thu, Jan 12, 2006 at 07:13:46AM -0600, Eric Anderson wrote:
>E> That's true, if you can find a committer willing to help - and I think
>E> that's the issue. I've tried numerous times to contact committers of
>E> certain areas, asking quick questions, or things like 'if I build this,
>E> would it be comittable?' - with about 80% of the time receiving no
>E> response. Now, I'm not complaining, or claiming they should reply -
>E> they are volunteers and already busy doing their regular life stuff in
>E> addition to the FreeBSD code they contribute. I'm just mentioning it as
>E> a data point, that it is pretty hard to find a committer willing to
>E> mentor someone, or at a minimum, give them pointers. The -hackers list
>E> is excellent as far as answering most technical questions (rapidly!),
>E> but in the end, it is pretty difficult to find a committer to listen to
>E> you, unless you already have patches ready to roll, since that takes
>E> less time of course.
>
>First you should to check whether given person is active now in CVS and/or
>mailing lists. If he is not, then you have a lesser chance to get answer.
>
>
Yep, all the people I email are active on the lists, for sure, and
almost always active (or extremely active) committers.
>If he is active, then don't hesitate to ask for help. And don't be afraid
>to send a reminded, if discussion freezes.
>
>And don't forget that email goblins can eat your email. This is quite often
>a reason for "ignoring", at least for myself.
>
>
Yea, I forget about that, thanks for pointing it out..
>E> Maybe, on the FreeBSD developers page, we could have a list of
>E> categories and mentors for those categories for those willing to work on
>E> code to contact with questions, etc. Then committers could volunteer as
>E> a mentor for a category they enjoy.. Or is it enough to just post to
>E> -hackers asking 'anyone want to mentor me?' ?
>
>
>
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
Mark Linimon
> a committer willing to mentor someone, or at a minimum, give them pointers.
> code to contact with questions, etc. Then committers could volunteer as
> a mentor for a category they enjoy.
You might find http://www.freebsd.org/projects/ideas/ useful.
mcl
Eric Anderson
> On Thu, Jan 12, 2006 at 07:13:46AM -0600, Eric Anderson wrote:
>
>> I'm just mentioning it as a data point, that it is pretty hard to find
>> a committer willing to mentor someone, or at a minimum, give them pointers.
>> [...] Maybe, on the FreeBSD developers page, we could have a list of
>> categories and mentors for those categories for those willing to work on
>> code to contact with questions, etc. Then committers could volunteer as
>> a mentor for a category they enjoy.
>>
>
> You might find http://www.freebsd.org/projects/ideas/ useful.
>
> mcl
>
Well, it's helpful, except a few of the people responsible for projects
on that list are those that are very busy, and somewhat unresponsive.
Are those all people that volunteered to help developers trying to
learn/contribute? If so, great, but if not, they should be replaced
with some other committers with more spare time available.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
Alexander Leidinger
> Mark Linimon wrote:
>> You might find http://www.freebsd.org/projects/ideas/ useful.
> unresponsive. Are those all people that volunteered to help
> developers trying to learn/contribute?
Those are the people which offered to mentor for the SoC + some more. We
asked all of the mentors listed on the SoC page if it's ok for them to get
added on the ideas list too. Additionally we asked some more people or those
other people told us they are willing to help. We didn't asked all developers
directly and we didn't added someone without asking him.
Bye,
Alexander.
--
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
He's dead, Jim
-- McCoy, "The Devil in the Dark", stardate 3196.1
Eric Anderson
> Eric Anderson <ande...@centtech.com> wrote:
>
>> Mark Linimon wrote:
>
>>> You might find http://www.freebsd.org/projects/ideas/ useful.
>
>> unresponsive. Are those all people that volunteered to help
>> developers trying to learn/contribute?
>
> Those are the people which offered to mentor for the SoC + some more. We
> asked all of the mentors listed on the SoC page if it's ok for them to
> get
> added on the ideas list too. Additionally we asked some more people or
> those
> other people told us they are willing to help. We didn't asked all
> developers
> directly and we didn't added someone without asking him.
Ok, well it sounds like it's what I was mentioning then. I really like
this projects page, it gives us wannabe hackers a place to look for cool
ideas to tinker with.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
Anything that works is better than anything that doesn't.
------------------------------------------------------------------------
_______________________________________________
Frode Nordahl
> On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote:
>> FreeBSD Update was written by, and is continuously maintained by the
>> actual FreeBSD Security Officer. It's as official as it gets. If
>> the only barrier to acceptance is that it's not distributed from the
>> FreeBSD.org domain, then a) that's a silly argument, and b) it's
>> easily
>> solvable so long as Colin agrees.
>
> But FreeBSD Update suffers from all of the same limitations that
> I've been
> describing because of lack of integration with the Core OS.
>
> 1. modified kernels are foobar
> ..yet are practically mandatory on production systems
>
> 2. modified sources are foobar
> ..yet many common production situations require source
> compilation options
Modified files cannot be patched, period. No matter what system you
are on. A nice user-experience of backing up the modified file and
reinstalling the default could be added on top to resemble other
systems, but it would not solve your problem.
What you are looking for is enough run-time knobs and a stable ABI
layer for third party drivers so the need for compiling your own
kernel disappears.
> 3. FreeBSD Update can't handle updates of jails and other
> situations that
> package systems deal with just fine.
freebsd-update -b /usr/jail/foo ?
From the manual:
Act on a FreeBSD world based at the directory
basedir. This is suitable for updating jails, but
note that the usual rules about updating locally
modified (or compiled) files apply, and the jail
must belong to the same release version as the run-
ning kernel.
Frode Nordahl
fr...@nordahl.net