On 02/09/12 16:33, John Kozubik wrote:
Hello,
On Thu, 26 Jan 2012, Da Rock wrote:
I normally hate to dredge up old threads, but this is like getting
halfway through a story and not finding out the ending... :)
What is the answer? Is there a solution to this?
When I wrote the original post, I was expecting at most a benign
response, and at worst some real blowback ... but I was really
pleasantly surprised to find that my complaints were very well
received, and that a lot of folks were experiencing the same issues
that I was.
It appears to be a classic case of "if one customer complains, 99
others are thinking the same thing".
I was interested from the perspective of what would make FreeBSD a
bigger player on the enterprise level of the market. I know ISP's and
large organisations are not as concerned with "off the shelf" as much as
scalability, automation and customisation, and so don't mind running a
minor dev team/person to achieve what they want; but smaller
organisations would rather have it just work without much input or
technical ability. I don't know what it is like where you are, but here
even larger organisations are biased in this way- even up to a
government level (outsource!).
I have a string of questions on this:
1. Incidentally, what exactly does constitute a major release?
I was defining major releases to be 4.x, 5.x, 6.x ... and so on.
Currently 9.x is the latest major release.
To clarify my question (I thought it was a little corny to put it this
way, a little too shakespearean :) ), what is in a major release? I
suppose it is related to my later question regarding the objectives of a
release.
2. Is there a reason to update the numbers so quickly?
I didn't think so, which was one of the main points of my post. A lot
of other folks have agreed. BUT there were some counter arguments -
specifically that fully new features would be delayed for a much
longer time AND that there would be large architectural gulfs between
major releases.
For instance, we might have waited an extra 3-5 years for any ZFS
support at all in a -RELEASE, and when it appeared, it would introduce
a big upgrade hurdle, as it would be accompanied by major underlying
changes in system architecture.
But my counter to this was that a lot of these features that we did
get introduced to, earlier, were in fact not really usable anyway.
For instance, my firm(s) have not even considered production use of
ZFS until 8.3-RELEASE.
So the question remains, where do we set that dial ?
If it were up to me, I think I would stake out a very loud and clear
mission statement for FreeBSD that explicitly sacrifices new features
for longer lifecycles and deeper investment in particular releases.
I've thought seriously about the points that were made in this thread
supporting faster releases, and I do appreciate what we would be
giving up, but I continue to advocate for a new major release every 5
years.
I don't think that's going to happen, but based on this discussion and
feedback, it appears that we're going to get more frequent minor
releases - possibly 3-4 per year - which makes me very happy.
That sounds fair to increase the lifecycle to 5 years, but I think
hardware support (at least) needs to be available much sooner; perhaps
included in the minor releases. Otherwise users will just go elsewhere
(large corps or desktop users- mostly desktop though), it was trying
even for me as a stubborn mule. Most haven't the patience that I do. I'm
not 100% sure how to do this though...
3. Could a higher bar be set to reach a major release than simply
temporal objectives? One of the differentiating factors between linux
and FreeBSD is the simple fact that linux distros tend to run so fast
through the numbers- and while just a matter of perspective, it could
provide some sense of stability to enterprise users. Weighed against,
of course, the ability to upgrade easily.
I think temporal objectives are decent, provided they are long :)
Long timelines give people and organizations incentive to invest time
and money into a thing. I know very well of several investments in
FreeBSD that my firm(s) did NOT make because we didn't think it was
worth it, given that the release, and underlying arch, were going away.
Fair enough. I left linux for the same reason (but that was exceedingly
extreme). For the same reason drifting [ak]bi between major releases is
probably a bad idea - that would be an imitation of what most of us have
left in linux.
4. If in the case of the former, could some backporting to the stable
and release branches facilitate an easy upgrade to the next major
release?
5. Could binaries be the answer to easier upgrades (customised for
enterprise users)?
I think others have had better comments and insight as far as those
two points are concerned.
I think you would be well served to read the entire comment thread,
and just ignore all of the posts that are speaking about PRs - they
were off-topic almost immediately and devolved from there.
I did. I came across it about a week in, and it was one of the pr
comments that was cross posted which I stumbled on and I searched for
its root. I've been following from the very first post. Hence my interest :)
A good tl;dr is from a post I made early on:
<quote>
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.
</quote>
Again, I don't think this is how it will pan out, but it was my
favorite scenario. I'd be very happy and satisfied if we just got:
a) more frequent (3-4) minor releases
b) just one version declared as "production" at any given time[1]
And I'd be pretty happy if we just got (a), which I think we will.
--john
[1] There were a lot of "me too" posts about more frequent minor
releases, and the short lifecycle of major releases, but I was
surprised that nobody else was bothered by the existence of two
simultaneous "production" releases. To me it seems obviously
distracting and confusing - and results in new revisions of drivers,
etc., skipping the earlier "production" release.
No matter where we decide to set the lifecycle dial for major
releases, I really think we should rename the later one "development" ...
You know, I looked at the 7.x branch (I was sure I installed 7.2 back in
2009) and it only needs another year to reach your goal of 5 years. I
know something like this was mentioned before, but... it does seem
strange to fall short by just "that much" (to quote Smart).
The multiple "cultivated" branches seem a little strange to me too, but
I think there may yet another "ghost" branch which has all the "what
ifs". It seems to me that some efforts towards the start of a major
release "calving" that some sub projects are already distracted by
getting the new features in the "ghost" in the next current (that was
probably already mentioned too, come to think of it :) meh.. ). I think
using svn may relieve some of those effects, allowing cherry picking.
Perhaps provide more complete features than half done in any release?
IF svn was used primarily, would this allow the development team to
focus more on the production branch, with each developer allowed a
branch to themselves that they can break whatever, and with new api,
abi, kbi, kpi, and so on and so forth put to the test (once coordinated
and ready) in the development branch? This would mean 2 branches (dev
and production), long lifecycle, hardware support (and maybe feature) in
the production branch, and a (relatively) stable development branch.
Once time was up (say 5 years), then the dev branch can calve safely
without being too broken (or at least find a snapshot that was stable)
and release a new major branch, instead of waiting for things to finish.
Obviously then any things that finish after this can be introduced in
the next minor release safely. (some of this could already have been
proposed- this is probably an amalgamation) This would probably drop
legacy though- goes the other way, sorry :)
What this means is there would be 9.x and 10.x, with 9.x available for 5
years with active support, and 10.x being basted in low hot oven
throughout that time. That does provide a good focus, but there is the
marketing for volunteer support to consider I suppose. I would think
that private branches might alleviate that a bit though.
No matter what the lifecycle/branches/etc hardware is a big barrier if
you're a user at any level. If the hardware doesn't work you're screwed,
if software doesn't you can patch it easier. I think its harder to patch
a device driver than a software app if you don't have any experience in
driver development. You can also find a work around easier (my
experience, others may vary) for software than hardware. So if only 2
branches then hardware needs to be fully supported in the production
version. What a dream...
I think in the long run a longer cycle and less branches may possibly
even help the driver development to better support hardware in any
branch, so maybe our ideas aren't so far apart?
I think I have let my brain ramble enough through my musings here...
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[email protected]"
