Two release tracks


Recommended Posts

This is not actually a feature request (something to add to the unRAID distro), but more of a request for an improvement in the unRAID release program.  I doubt that Tom will like it(!), even if he recognizes its usefulness, because it clearly adds more work for him and his staff.  But I think it's worth discussing.

 

Increasingly, I've been thinking that we may be getting too close to the bleeding edge.  We have strongly competing interests, driving interests, that can't be fully reconciled.  We want the long tested stability of a base system, the NAS, the rock solid foundation of our data storage.  But we also want the latest technologies - the latest Docker features, the latest KVM/QEMU tech, full Ryzen support, etc, and that means the latest kernels.  In my view, it's impossible to do both well.  We're trying now, not far behind the latest kernels, but we're seeing more and more issues that seem related to less tested additions and changes to the kernel.  For example, a whole set of HP machines unsupported, numerous Call Traces, and other instabilities, that I really don't think would be present in older but well patched kernel tracks.  But some users are now anxiously awaiting kernels 4.10 and 4.11!

 

So what I'm proposing for consideration is moving to two track releases, a stable track and a 'bleeding edge' track (someone else can come up with a better name).  Currently, 6.2.4 would be the stable release, and 6.3.2 would be the leading edge release.  6.1.9 was a great release, considered very stable.  It was based on kernel 4.1.18, that's the 18th patched release of Linux kernel 4.1.  6.2.4 was a great stable release.  It was based on kernel 4.4.30, the 30th patch release of 4.4.  We're currently on 6.3.2, using kernel 4.9.10.  What I would like to see is the stable release stay farther back, and only move to a new kernel track when it reaches a 15th or 20th patched release (just my idea).  We can still backport easy features, cosmetic features, and CVE's.  Then Tom can be free to move ahead with whatever he wants to add into the latest 'leading edge' releases, with a little less concern for the effects, because there's always a safer alternative.

 

A nice side effect is that the stable releases won't need betas, just an occasional RC or 2 when the move up is larger than usual.  Practically everything added to it has already been tested in the newest releases.  Small non-critical features can be added to both tracks, but larger or more risky features always go in the risky track, not the stable, and are only added to the stable releases when clearly stable themselves.

 

I know this is more work, and that may make it impractical.  I wonder if Tom could concentrate on the latest versions, while Eric maintains and builds the stable releases.  Finding ways to automate the build processes could help too.  But this could keep 2 very different sets of unRAID users happy, those who want stability first and foremost, and those who want the latest tech.  Naturally, there are many who want both, but I personally think it can't be done, not done well.

  • Upvote 5
Link to comment
27 minutes ago, RobJ said:

This is not actually a feature request (something to add to the unRAID distro), but more of a request for an improvement in the unRAID release program.  I doubt that Tom will like it(!), even if he recognizes its usefulness, because it clearly adds more work for him and his staff.  But I think it's worth discussing.

 

Increasingly, I've been thinking that we may be getting too close to the bleeding edge.  We have strongly competing interests, driving interests, that can't be fully reconciled.  We want the long tested stability of a base system, the NAS, the rock solid foundation of our data storage.  But we also want the latest technologies - the latest Docker features, the latest KVM/QEMU tech, full Ryzen support, etc, and that means the latest kernels.  In my view, it's impossible to do both well.  We're trying now, not far behind the latest kernels, but we're seeing more and more issues that seem related to less tested additions and changes to the kernel.  For example, a whole set of HP machines unsupported, numerous Call Traces, and other instabilities, that I really don't think would be present in older but well patched kernel tracks.  But some users are now anxiously awaiting kernels 4.10 and 4.11!

 

So what I'm proposing for consideration is moving to two track releases, a stable track and a 'bleeding edge' track (someone else can come up with a better name).  Currently, 6.2.4 would be the stable release, and 6.3.2 would be the leading edge release.  6.1.9 was a great release, considered very stable.  It was based on kernel 4.1.18, that's the 18th patched release of Linux kernel 4.1.  6.2.4 was a great stable release.  It was based on kernel 4.4.30, the 30th patch release of 4.4.  We're currently on 6.3.2, using kernel 4.9.10.  What I would like to see is the stable release stay farther back, and only move to a new kernel track when it reaches a 15th or 20th patched release (just my idea).  We can still backport easy features, cosmetic features, and CVE's.  Then Tom can be free to move ahead with whatever he wants to add into the latest 'leading edge' releases, with a little less concern for the effects, because there's always a safer alternative.

 

A nice side effect is that the stable releases won't need betas, just an occasional RC or 2 when the move up is larger than usual.  Practically everything added to it has already been tested in the newest releases.  Small non-critical features can be added to both tracks, but larger or more risky features always go in the risky track, not the stable, and are only added to the stable releases when clearly stable themselves.

 

I know this is more work, and that may make it impractical.  I wonder if Tom could concentrate on the latest versions, while Eric maintains and builds the stable releases.  Finding ways to automate the build processes could help too.  But this could keep 2 very different sets of unRAID users happy, those who want stability first and foremost, and those who want the latest tech.  Naturally, there are many who want both, but I personally think it can't be done, not done well.

Love this idea!

Link to comment

Love the concept, but have a couple things to add. I don't want to backslide to the zone of not patching security holes for months or more on end, so even the stable would need to be somewhat unstable from that view. The days of being able to run 4.7 for 3+ years without updating (or rebooting!!!) are gone.

 

Also complicating the issue is the ability to seamlessly jump back and forth without major reconfiguration. Ideally you would be able to test a bleeding edge release without compromising the ability to step over (not back, security should be same in both) to the mature release, but I don't think that would be universally possible.

 

Honestly, I think we were VERY close to what you outlined during the period where 6.2.4 was the latest release and 6.3.x was in the RC stage. Perhaps what you are really asking is for the RC stage to be a semi-permanent feature, and opening the beta earlier?

 

If Limetech held the RC for a longer period and let it mature more while the next beta was getting worked out, you would have the end result of your request. Slow down the push for full release, and leave the RC up for months or more, until the beta is truly RC ready. The last RC phase for 6.3.x was really treated more like a beta with the addition of features instead of just fixes. The released track would get only critical security updates, the RC track would get ALL security updates, and the beta track would get feature additions as well. I'm not advocating for a major slowdown, just saying it would be nice to keep the RC feature locked and introduce a new beta when that happens.

Link to comment

If Limetech held the RC for a longer period and let it mature more while the next beta was getting worked out, you would have the end result of your request. Slow down the push for full release, and leave the RC up for months or more, until the beta is truly RC ready.


Only problem with this approach is LT would be back where they started with everyone complaining about how long it is taking for a stable release. I don't personally see how it would be possible to keep two branches active with similar features (I.e. KVM and dockers will most likely be more on the bleeding edge side for the foreseeable future). Personally, in order to realistically have a stable version and a bleeding edge version you would want an unRAID NAS only version (stable) and an unRAID (docker/kvm) version (bleeding edge) - just my opinion.
Link to comment

I think RobJ is proposing something more like the Ubuntu LTS strategy, where periodically you have a well defined, highly stable version that is anointed an LTS version, versus the current development branch which has the latest features, revs quickly, but use at your own risk.  The LTS version is still supported for critical fixes like CVEs.  I probably stretched that metaphor a little to far, but I like the general idea.

Link to comment
9 hours ago, jonathanm said:

Love the concept, but have a couple things to add. I don't want to backslide to the zone of not patching security holes for months or more on end, so even the stable would need to be somewhat unstable from that view.

 

I think everyone is happy with the recent release schedules, and the way we're keeping up with security patching, and I certainly don't want to change that.

 

I don't in any way want to say what Tom should do, so this is just pure speculation, just one idea of what could happen:  if Tom were to give Eric more build responsibility, at the first (or some other day) of each month or every other month, Eric could ask Tom if he could build the next stable release using a given set of CVE patches, and possibly a small set of newer features or enhancements already in the dev track release.  That way, users could expect a stable release on schedule.  At times, the answer might be that no stable release was warranted, no security issues to fix and nothing to add, and notify us accordingly.

 

9 hours ago, jonathanm said:

Also complicating the issue is the ability to seamlessly jump back and forth without major reconfiguration. Ideally you would be able to test a bleeding edge release without compromising the ability to step over (not back, security should be same in both) to the mature release, but I don't think that would be universally possible.

 

That IS a problem, no easy answer.  We saw that recently with the attempts by users to return to 6.2, Dockers not backward compatible.  I'm not sure it should stop this though, just means that users will be more likely to stick with whatever track they select.  However, I'd say that most of the time, *someone* has come up with a set of steps to follow.

 

3 hours ago, tdallen said:

I think RobJ is proposing something more like the Ubuntu LTS strategy

 

I like the LTS strategy, but I didn't want to say it, I didn't want to limit Tom to any particular way of doing it.  But the rationale is very similar.

 

4 hours ago, archedraft said:

Personally, in order to realistically have a stable version and a bleeding edge version you would want an unRAID NAS only version (stable) and an unRAID (docker/kvm) version (bleeding edge) - just my opinion.

 

That's one of the possibilities of course, but I don't personally like it.  I think there are probably a number of happy users still on 6.2.4, running VM's.  To me, it's a philosophical choice users can make - run with what has been better tested and works fine for them, even if not as 'modern' or feature rich, or keep up with the latest tech, knowing there's a risk of more issues.  If you need support for something that's only available in a certain release, you want that release no matter what it takes.  Once you have the feature support you need, users can stick there, until the stable releases catch up with them, and then they can stay on the stable track.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.