Hi Devin,
On Tue, 17 Jan 2012, Devin Teske wrote:
I brought this up in last weekend's BAFUG meeting...
We're _very_ interested in replicating the long-lifecycle of the 4-series with a
newer series. But which one?
Right now, we're jumping to the 8-series, but after seeing that one of the major
focal points for 9 is McKusick's SU+J (SoftUpdates Journaling -- tunefs -j
enable), I'm ready to say that the 9-series should instead be the "chosen
outlier" when it comes to picking one single release to have an ultra-wide
lifecycle.
The 9-series represents the first release to integrate a journaled filesystem
by-default into the system (aka boot) filesystem(s). We were pleasantly
surprised to see that the default installer enabled SU+J by-default when
choosing "guided" and "auto" for disk partitioning.
There's two parallel suggestions being put forth here, both of which are
interesting:
- Allow a related party to adopt a release (as I understand it) and
provide a sub-community taht donates resources to tending and updating
that release.
- Picking a "chosen" release to really dive into, officially, and polish
and extend it, like 4.
If I had to pick, I'd say the second one, but I'm not sure either one is
the right direction. I think a more sustainable, balanced approach that
can be extended for every release into the future would be best.
I don't really want to see some semi-official "fork", or "extended
release" - it would duplicate a lot of existing effort as well as raise
questions about how "official" it was. Would vmware support it as a real
release ? Large organizations might disqualify it the same way they would
STABLE.
As for picking 8 or 9 to be the "chosen" exception - that would help me a
lot in the short term, but if things are being done wrong, they should be
fixed in the long run.
I think the real choice that has to be made is "when will we halt
proclaiming two simultaneous releases as production ?" and since 9 is
already here, it can't be 8/9, it has to be 9/10. You could progress 8.x
along its current trajectory, possibly building 8.4 a year or so from now
and then be done with it, and then that would be the last short/unfocused
release.
Then you postpone 10.0-RELEASE until January 2017.
Instead of having a legacy branch and two production branches, you would
have legacy (8) production (9) and ... nothing. Or if you need to have it
out there, 10 is the development branch.
Minor releases come out 2-3 times per year, which gets you to 9.10 or 9.15
at the end of the cycle.
On Tue, 17 Jan 2012, Adrian Chadd wrote:
OP - if you'd like to see FreeBSD's stable release schedule pushed
forward a bit quicker then please, step up and offer to assist. No-one
is going to say no. Everyone will appreciate the extra help.
I don't really know how much upheaval is implied in pushing 10.0 to 2017,
developing only one "production" release, and running 9.x up to 9.15 (or
whatever) but I can contribute USD $10k per year that this course was
followed, or $50k over five years. We can contribute some hardware,
hosting and bandwidth as well.
Are there any others here who can chip in, or whose firms can ?
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
