Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 09 Feb 2012 23:23:42 +1000
From:      Da Rock <9Phackers@herveybayaustralia.com.au>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Moving on ...
Message-ID:  <4F33C8DE.8020609@herveybayaustralia.com.au>
In-Reply-To: <alpine.BSF.2.00.1202082202530.19710@kozubik.com>
References:  <20120119005658.218280@gmx.com> <alpine.BSF.2.00.1201191511470.19710@kozubik.com> <4F19188A.4090907@herveybayaustralia.com.au> <4F213CEB.4020207@herveybayaustralia.com.au> <alpine.BSF.2.00.1202082202530.19710@kozubik.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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...



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F33C8DE.8020609>