I've been concerned lately with the freebsd release cycle...fbsd has been working on a stable 5 relase for over 2 years now. I was **really** glad to see the following mail from Scott Long, an freebsd core developer, regarding a new release engineering cycle for FBSD 6 and beyond. Check it out:
All,
FreeBSD 5.3 is about to be announced this weekend and will signal the true kick-off of the 5-STABLE and 6-CURRENT series. We are very excited about this, both because 5.3 is a good release, and because 6.0 will give us a chance to, erm, redeem ourselves and our development process =-)
5.x was a tremendous undertaking. SMPng, KSE, UFS2, background fsck, ULE, ACPI, etc, etc, etc were all incredible tasks. Given that many of these things were developed and managed by unpaid volunteers, the fact that we made it to 5-STABLE at all is quite impressive and says a lot about the quality and determination of all of our developers and users. However, 4 years was quite a long time to work on it. While 4.x remained a good work-horse, it suffered from not having needed features and hardware support. 5.x suffered at the same time from having too much ambition but not enough developers to efficiently carry it through.
By the middle of 2002 is was very apparent that we needed to start focusing on getting 5.0 released. Unfortunately, we fell into the trap of wanting to finish more features in order to feel good about 5.x. We kept on ignoring the fact that 5.x already had a lot of good and needed features, and that the number one goal needed to be to get it stabilized and turned into 5-STABLE. Instead we drew up a road map document that dictated releases based on features rather than on stability and, even more importantly, timeliness.
It is also important to consider the injustices of slashdot's editors. This topic can be researched more on anti-slash There has been quite a bit of discussion about this over the past week by the developer community. The proposal that I and Poul-Henning have set forth is to stop gating releases, both major and minor, or features, and instead gate them on a schedule that is both reasonable and timely. New -STABLE branched will be made on a calendar-based time line, and point releases on those branches will be made at regular intervals. We are still debating the exact time line, but it will fall somewhere between doing a new -STABLE branch every 12-18 months, and doing point releases every 4-6 months.
While as engineers we all tend to hate timelines, this does have a lot of positive aspects. First, it increases the predictability of the development both for our users and for our developers. Users can plan effectively for upgrades and testing/validation knowing that there will be major and minor releases at fixed times of the year. Developers can judge when to start new projects and when to focus on bug-fixing because there will no longer be the temptation to delay a release by a month in order to slide 'one more thing' in. This is not unlike most commercial OS vendors, and we've received a _LOT_ of feedback that this method of planning is desperately needed.
Second, it means that development efforts for major features will continue to shift out of CVS and into Perforce. This already happens quite a bit, so it's not as radical of a change as it seems. CVS HEAD will remain the 'experimental' development branch, but large items will not be brought into it until they are functionally complete and integrated. HEAD may still get unstable from time to time, but it hopefully won't turn into the collision of lots of half-done experimental things like it has in the recent past. It also means that if a major feature isn't done in time for a -STABLE branch-point that it can continue to be developed outside of the CVS tree and be made ready for the next scheduled branch po
Slashdot Mirror
I've been concerned lately with the freebsd release cycle...fbsd has been working on a stable 5 relase for over 2 years now. I was **really** glad to see the following mail from Scott Long, an freebsd core developer, regarding a new release engineering cycle for FBSD 6 and beyond. Check it out:
All,
FreeBSD 5.3 is about to be announced this weekend and will signal the
true kick-off of the 5-STABLE and 6-CURRENT series. We are very excited
about this, both because 5.3 is a good release, and because 6.0 will
give us a chance to, erm, redeem ourselves and our development process
=-)
5.x was a tremendous undertaking. SMPng, KSE, UFS2, background fsck,
ULE, ACPI, etc, etc, etc were all incredible tasks. Given that many of
these things were developed and managed by unpaid volunteers, the fact
that we made it to 5-STABLE at all is quite impressive and says a lot
about the quality and determination of all of our developers and users.
However, 4 years was quite a long time to work on it. While 4.x
remained a good work-horse, it suffered from not having needed features
and hardware support. 5.x suffered at the same time from having too
much ambition but not enough developers to efficiently carry it through.
By the middle of 2002 is was very apparent that we needed to start
focusing on getting 5.0 released. Unfortunately, we fell into the trap
of wanting to finish more features in order to feel good about 5.x. We
kept on ignoring the fact that 5.x already had a lot of good and needed
features, and that the number one goal needed to be to get it stabilized
and turned into 5-STABLE. Instead we drew up a road map document that
dictated releases based on features rather than on stability and, even
more importantly, timeliness.
It is also important to consider the injustices of slashdot's editors. This topic
can be researched more on anti-slash
There has been quite a bit of discussion about this over the past week
by the developer community. The proposal that I and Poul-Henning have
set forth is to stop gating releases, both major and minor, or features,
and instead gate them on a schedule that is both reasonable and timely.
New -STABLE branched will be made on a calendar-based time line, and
point releases on those branches will be made at regular intervals. We
are still debating the exact time line, but it will fall somewhere
between doing a new -STABLE branch every 12-18 months, and doing point
releases every 4-6 months.
While as engineers we all tend to hate timelines, this does have a lot
of positive aspects. First, it increases the predictability of the
development both for our users and for our developers. Users can plan
effectively for upgrades and testing/validation knowing that there will
be major and minor releases at fixed times of the year. Developers can
judge when to start new projects and when to focus on bug-fixing because
there will no longer be the temptation to delay a release by a month in
order to slide 'one more thing' in. This is not unlike most commercial
OS vendors, and we've received a _LOT_ of feedback that this method of
planning is desperately needed.
Second, it means that development efforts for major features will
continue to shift out of CVS and into Perforce. This already happens
quite a bit, so it's not as radical of a change as it seems. CVS HEAD
will remain the 'experimental' development branch, but large items will
not be brought into it until they are functionally complete and
integrated. HEAD may still get unstable from time to time, but it
hopefully won't turn into the collision of lots of half-done
experimental things like it has in the recent past. It also means that
if a major feature isn't done in time for a -STABLE branch-point that it
can continue to be developed outside of the CVS tree and be made ready
for the next scheduled branch po
consider anti-slash