FreeBSD Looks Ahead to 6.0

I was catching up on mailing list archives when I came across an announcement from Scott Long of FreeBSD's release engineering team, noting that after the rather substantial amount of time that it took to take FreeBSD 5 to a -STABLE designation, their release schedule will be speeding up in the future. With the official release of FreeBSD 5.3 coming Real Soon Now, a new branch for 6.0 is now tentatively scheduled for mid-2005. It would seem that while the version numbers may increase more rapidly, so will the rate at which new features are merged from -CURRENT, so end users can get new features faster.

Comments

first positive post

[Anonymous Coward]

BSD lives!

Re:first positive post

[YU Nicks NE Way]

No, it's double-plus undead.

RTFA -- It's Quite Interesting

[akpoff]

1. Move to a timeline-based release cycle rather than feature-based.
2. Development of major features in Perforce. The goal is to keep the head branch from going unstable very often and allows major features to stay under development if it isn't ready for -STABLE branch point. Appears CVS will still be used for the main tree.
3. Frequent scheduled releases will keep the bug count under control.
4. Current plan is to branch for 6-STABLE in the May/June 2005 time frame with 6.1/.2 etc in 4-6 month intervals thereafter.

Two very big, interesting changes. Given the very usable ports tree moving to scheduled releases for the core system makes a lot of sense. The decision to move development of major features out of the main CVS tree compliments the scheduled-release strategy. If anyone can make it work it'll be the FreeBSD team.

Congratulations on achieving 5-STABLE and best wishes on 6-CURRENT development!

Re:RTFA -- It's Quite Interesting

[ulib]

TFA is really worth reading. And, as you say, moving to scheduled releases is a very good idea: even if 4.10 for production use is still very good in most cases, I think users are going to appreciate releases at more regular intervals.
For all that they've done and all that they'll do, kudos to the FreeBSD team!
--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

time-based releases a bad-thing(tm)?

[CaptainPinko]

With feature based release you get the pressure to get things done because everyone is waiting for you. I'm worried that with time-based releases a lot of features will languish with tweaking or becoming more and more ambitious and they'll never get finished to be merge since there is no pressure. I'd rather see feature-based for at least one majour feature in a release. In other words keep it feature-based but bite off only a little (and not more than chew) and aim for that bite to be doable in 9-13 months (to leave for debugging, testing, etc.).

Re:time-based releases a bad-thing(tm)?

[ArbitraryConstant]

That could potentially be an issue, but it's also possible for a group of developers to work on their own branch, bringing in changes from CURRENT from time to time. SMP on OpenBSD took longer than the 6-month release interval, so there was a seperate SMP branch until the work was close enough to completion to make it into a release.

Re:time-based releases a bad-thing(tm)?

[archen]

I think that even of you only a "few" features you run the risk of having something not work out and still missing the time schedule (as the DragonFly BSD guys said about SMP in FreeBSD). This isn't neccesarily the end of the world - it's just a schedule and they can always change it back so I'm willing to see how this all goes.

I think they want to avoid what happened to 5x stable. Many people like me have had all the features we need in 5x for a long time, but they keep pushing off 'stable' because of some new tweak. This time schedule may allow for development to continue at the same rate, while getting the userbase fresh releases with bugfixes and improvements.

Re:time-based releases a bad-thing(tm)?

[Eivind Eklund]

I'm a FreeBSD developer.

Our experience, after doing this for 10 years (I personally have been a developer for 7.5 years) is that we get serious problems whenever we try to go feature based, because we get wrong priorities, and it end up with releases taking too long and there being less feature development overall.

This is why we want to switch back to a time based release cycle. We have had long discussions about this (there have been hundreds of messages debating various issues around it), and the overall result is that we believe things get better in close to every way with time based releases, based on what happens in practice.

As we introduce fairly major features reasonably often, there will be major features introduced to releases. We just stop promising major features that are not yet implemented in a particular release. If there were nothing major new, we wouldn't bother with the work of cutting a new -stable branch.

Eivind.

Re:MFCed?!

[compass46]

MFCed stands for "Merged From Current". It means that something from -CURRENT was backported to -STABLE. For example, if bugs are found in something while working on FreeBSD-6 and they exist in FreeBSD-5, the fixes from FreeBSD-6 might be MFCed to fix the problem in FreeBSD-5.

The quick answer.

[ulib]

I know, I know.. one shouldn't judge things solely on the basis of who's saying them.
..But do you know who you're listening to?
"sold nearly 2,000 copies of my beta system"..
"remove assholes like x and y from the team".. "I made money off *my* work"..
"it's not usable in a production environment, not without my patches"..
"they won't be getting my patches unless I see public apology from a and b"..
..Does this ring a bell??.. :-DDD

--
Being able to read *other people's* source code is a nice thing, not a 'fundamental freedom'.

Re:The quick answer.

[DashEvil]

I think there was a typo in your post.

Surely you meant "Operating systems copied and rebranded by T. Hawkins: 1".

Re:The quick answer.

[DashEvil]

Where can you find the source for this OS (the embedded one), I wouldn't mind having a look at your 1337 coding skillz, since I've not seen a single line you've written yet.

Time Based releases work

[Anonymous Coward]

OpenBSD already does this and it shows. Things get introduced into the tree and gradually grow to perfection between releases, with snapshots regularly giving users a chance to test and give feedback. Theo gets angry if the current tree won't compile for more than 20 minutes.

It allows gradual changes to happen, I can only remember one "flag day" when the binaries went from a.out to ELF format. Everything else has been pretty gradual. I happen to like installing snapshots, and have found them to be pretty stable, stable as a rock in my experience.

Kudos to FreeBSD for going this route. It will mean wider exposure. The one problem is regular upgrades and supporting past releases. If it took 4 years to get 5 ready for stable, in that time OpenBSD has had 8 releases (one every 6 months). Noone has the resources to support all the old releases, so they only support the past two releases.

Now if all the *BSDs will continue to cooperate, and maybe spread the release dates out so each can share in the publicity we can have a release each quarter. Of course I didn't notice the schedule of release dates, maybe FreeBSD will choose to release every 9 months, or 72 weeks or biennially or whatever.

Re:Private message for Mr. Hawkins

[gtoomey]

At the risk of damaging my karma, any post promoting HawkinsOS is a troll.

Kudos

[molnarcs]

I just want to express my deep respect for FreeBSD developers. All the hype is around linux these days, and rightly so: it is a wonderful system. But few know that there are now ~100 paid developers working on linux (which is 'just' a kernel) at any given time, while there are none in FreeBSD. Yes, yes, PHK now is payed to do FreeBSD-only development for 8-10 months. There are others who receive either support from their employers to work on FreeBSD part-time, or some grants or others, but all in all, the FreeBSD project has 1/100 of the resources linux has.

Of course, I realize that from a user/technical standpoint, this means nothing. But there are too many trolls out here who are bent on conducting a smear campaign against FreeBSD developers, going even as far as to question their programming skills. Now think about this: these developers have kept up with the pace linux development dictates with 1/100 of the resources linux development has. It is still one of the most reliable operating systems out there, no matter what disgruntled HawkinsOS guys will tell you about FreeBSD not being 'enterprise ready.' In fact, if you check netcraft's monthly reports about the most reliable sites, 4-5 sites from the top 10 is always running FreeBSD. In october, the top three sites having the fewest failed requests all ran FreeBSD (the 4th is Net~ or Open~).

So I just can't emphasize enough how impressed I am (as a desktop user btw) with the work of these guys. And now this announcment! Excellent ideas there! And I hope to see ULE allowed in -STABLE again soon :))) (did I say I was a desktop user?).

Thanks guys ... for everything!

Re:Kudos

[archen]

Now think about this: these developers have kept up with the pace linux development dictates with 1/100 of the resources linux development has.

That sort of depends on what you mean by resources. An interesting thing was said by one of the DragonFly BSD guys, in that their development moved much more quickly because there weren't as many people involved in the project (as in FreeBSD). It's not neccesarily the size of the team, but the quality and how well they work together. Once you reach a criticle mass for a given team, you end up losing more and more productivity to human overhead as people are added.

I think Linux may start to feel unnessesary pressure due to corperate interests - which might slow things down more than advance them.

Re:Kudos

[molnarcs]

Yeah, you might be right, I haven't thought of that from this perspective. Still, a bit more resources (necessary hardware for testing/writing drivers, at least a handful of developers working full time on FreeBSD wouldn't hurt :)).

One thing they should do is to update the Foundations website. Advertise. Make donating easier and more compelling. An outdated website is not a good incentive to contribute. The best thing would be if they could achieve steady funding. I'm just a student, and my monthly budget is 76000HUF (~380$). Hungary is cheap, so that's OK, but it isn't much (it just covers my monthly expenses, it is not enough to save up), yet I think I could afford a monthly 5$ to help them. But I would only do that if I saw a very well organized 'campaign' to do that. A professional, easy to use website, specific goals (target amount for each month), way to track it, publicity, publicity, publicity. I think it would even be worth for the project to pay someone to organize this (let's say he or she would get x% of the income). I also think that income should be calculable.

In other words, this 'campaign' (I'm looking for a better expression, english is not my native language!) should focus on getting to those who are willing to contribute (even very small amounts, like 5$) for a set amount of time (6-12-x months) - thus to make the 'income' as a said, predictable.

Just an idea...

Re:gvinum still broken

[Brandybuck]

How many enterprise ready operating systems have you written?

And I see that you've written *none*! All you've done is take FreeBSD and tweak it bit here and there. That is a much different thing from writing an operating system.

Maybe my only claim to fame is homebrewing software (not counting the real time embedded systems software I do at work), but at least I'm secure enough not to feel the need to engage in casting puerile aspersions at my competitors.

An error occurred while loading http://www.hawkinsos.com/

I was going to look up what "several fortune 100 companies" were using HawkinsOS, but apparently the demand is so high it's swamped your server.

Perforce

[Rubel]

Perforce is stable, fast, and well-tested. I don't see how using a great tool is a handicap, even for an open-source project.

Re:gvinum still broken

[Chreo]

You're getting rather pathetic... 1) Gvinum works and the RAID5 bug have been fixed in 5-STABLE stoopido! Anyone who is advanced anough to use RAID5 and vinum knows how to fix this issue by updating to latest 5-STABLE! 2) ULE patches are available that fixes things as well. If you feel the need to use ULE just grab'em or wait until ULE is MFC'd. Now please be so kind to eat shit or release those patches that you "claim" to have. If you even have anything... In your case, seeing is believing and we ain't seen nothing but whining yet from you. So either you put up or you STFU!