FreeNAS 9.2.0-BETA now available!

[jyavenard]

What are the change policies of ixsystems when it comes to release?

I find it surprising that you would still have feature changes happening when a beta is out, or that you have such significant changes being added when a RC is out...

Certainly different to most projects out there (including FreeBSD, they would have frozen the branch long ago)

And once 9.2 is release, will there be a 9.2-stable branch that can be tracked?

 

[cyberjock]

14.04 will have more in common with 13.10 than with 12.04.

I'd be advocating 14.04 if it were out as I always recommend the latest LTS.

I've never had a 100% smooth upgrade from one LTS to the next. There's always something that broke, and broke hard. Last time it was lirc (the infrared framework); it changed from being a user app into a kernel module: syntax of configuration file changed, IR code changed.. They also changed desktop manager radically. If you upgrade small each time: it's less work

I've never had an upgrade go smoothly for me under any condition(and I've never done an LTS to LTS upgrade). I'm also not a linux wizard so when things break I'm more or less going straight to Google to see what broke and how to fix it.

 

[warri]

That's unfortunate. It has been in FreeBSD base for a while now. Is there a possibility to configure NFSv4 outside of the GUI?

If I'm interpreting#3582 and #3583 correctly, you are lucky and NFSv4 is supported in 9.2.0 but can only be configured via CLI.

 

[cyberjock]

What are the change policies of ixsystems when it comes to release?

I find it surprising that you would still have feature changes happening when a beta is out, or that you have such significant changes being added when a RC is out...

Certainly different to most projects out there (including FreeBSD, they would have frozen the branch long ago)

And once 9.2 is release, will there be a 9.2-stable branch that can be tracked?

I'm not an iXsystems employee, but I don't think there's any hard and fast policies. Normally its just bug fixes after it hits RC. But, there has been(and probably always will be) exceptions. For example, when 9.1.0 was in RC status the jail system was trashed and rewritten from scratch just a week before -RELEASE was made. I don't remember there being a RC with the new jail. It was just thrown out there with "fixes will come later" status. That's why 9.1.1 was so soon after 9.1.0.

 

[jgreco]

Try to keep it in perspective, jyavenard.

Large projects like FreeBSD tend to get bogged down in release engineering cycles, and especially where the kernel is concerned, that's a good idea. However, when it comes right down to it, try to remember that FreeNAS is basically just a very nicely packaged FreeBSD. There's less to go seriously wrong. The underlying bits are likely to be stable. FreeNAS is largely about exposing existing FreeBSD/ZFS capabilities through an appliance interface. There's a focus on stability of the core functionality, of course, but the edges are a little fuzzy.

 

[jkh]

What are the change policies of ixsystems when it comes to release?

Our policy is to do a series of carefully managed changes, each commit strenuously scrutinized beforehand and then committed, by hand, to a frozen branch with one full release cycle per change, complete with QA and regression testing.

In practice, however, we just do whatever the hell we want!

We're getting better though. There were some ill-advised changes made between 9.2.0-BETA and 9.2.0-RC (which is still not out) that seemed like a good idea at the time but had repercussions. Those have now been fixed, the resulting embarrassment helping to make practice more closely adhere to policy going forward! Sometimes you have to do something stupid multiple times before it sinks in just why it's stupid. Like drinking a quart of scotch all by yourself: Really not a good idea, but some of us had to learn that lesson multiple times before it finally stuck! ;)

 

[jyavenard]

In practice, however, we just do whatever the hell we want!

Just what I thought :)

We're getting better though. There were some ill-advised changes made between 9.2.0-BETA and 9.2.0-RC (which is still not out) that seemed like a good idea at the time but had repercussions. Those have now been fixed, the resulting embarrassment helping to make practice more closely adhere to policy going forward! Sometimes you have to do something stupid multiple times before it sinks in just why it's stupid. Like drinking a quart of scotch all by yourself: Really not a good idea, but some of us had to learn that lesson multiple times before it finally stuck! ;)

I saw one of your "optimisation" being reversed....

I think preventing any engineers to commit in the last minute because "it would be such a pity to miss out" or "it's very safe" or "oh give me 5 more minutes" is doomed to fail :)

I've personally had to manage that for years and no matter what, it never really get through.

 

[cyberjock]

I saw one of your "optimisation" being reversed....

Please tell me it's not one for the AES-NI stuff!

 

[jyavenard]

Please tell me it's not one for the AES-NI stuff!

actually, my bad... the one I was alluding to was in fact from Josh Paetzel.

It was a tongue in cheek comment anyway

 

[cyberjock]

ah.. ok. Shoo.