On Tue, 17 Jan 2012, Andriy Gapon wrote:
on 17/01/2012 00:28 John Kozubik said the following:
we going to run RELEASE software ONLY
My opinion: you've put yourself in a box that is not very compatible with
the current FreeBSD release strategy. With your scale and restrictions you
probably should just use the FreeBSD source and roll your own releases from
a stable branch of interest (including testing, etc). Or have your own
"branch" where you could cherry-pick interesting changes from any FreeBSD
branches. Tools like e.g. git and mercurial make it easy. Of course, this
strategy is not as easy as trying to persuade the rest of FreeBSD
community/project/thing to change its ways, but perhaps a little bit more
realistic. You can bond with similarly minded organizations to share
costs/work/etc. It's a community-driven project after all.
Suppose for a moment we get the .x release process fixed: we start cutting
regular point releases from -STABLE on a 6-month cycle (just a strawman).
freebsd-update's update and upgrade features actually make tracking -STABLE at
release engineered time slices plausible.
One reason that's true is that between 5.x and 6.x, the FreeBSD Project
underwent a substantive change in our approach to binary interfaces. In 4.x
and before, the letters "ABI" rarely hit the mailing lists. In 6.x and later,
it's a key topic discussed whenever merges to -STABLE come up. We now really
care about keeping applications running as the OS moves under them. We also
build packages to better-defined ABIs -- not perfectly, but OK.
I think John gets a lot of what he wants if we just fix our release cycle.
Robert
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
