J
jkh
Guest
Hi folks,
It probably hasn't escaped anyone's notice that the last couple of weeks have been a little weird in terms of what's been going on with the 9.3-STABLE and 9.3-Nightlies trains. Bits have been freely commingling back and forth, ChangeLogs have been inexplicably large, or missing, or duplicated, and "Just what the heck is going on with the FreeNAS project??" some have been asking.
The short answer is that as alarming as this may have seemed from the outside, the actual "problems" in terms of getting a working FreeNAS up and running (or maintained) have been very small because all of these bits have been coming from the very same branch, and for all intents and purposes, 9.3-Nightlies and 9.3-STABLE have been very close to identical for the last couple of weeks as well, so all your bits are fine (mangled ChangeLogs notwithstanding) even if you tried to update or install in the middle of all this. So, what's been up?
Well, as most of you who are familiar with Source Code Management systems know, and we use git / github to manage all the FreeNAS bits, there can be a lot of different branches in a single repository (or spread across multiple repositories, as FreeNAS is), all being worked on at the same time in parallel in order to facilitate feature, experimental, and production lines of development. It can sometimes get a little hard for even a project's own developers to keep all the changes straight, so keeping the number of such branches low reduces the cognitive overload significantly and also ensures that things don't get "lost" by us failing to merge them, or worse, even mis-merging them across divergent lines of development and accidentally breaking things.
One of the branches we have been using for a long time in the freenas repo is called "master", a semi-standard convention in git which essentially conforms to "trunk" or "head" in other Source Code Management systems, though we did not use this convention uniformly. Some of our repositories, like ports or trueos, didn't even have a master branch and we worked from other branches (if you're geeky enough to know or care, that information is in freenas/build/repos.sh). Anyway, we also built the Nightlies from this master branch, "publishing" those nightly builds using the Software Update mechanism to a special train called 9.3-Nightlies and also pushing the builds up to http://download.freenas.org/nightlies/9.3-Nightlies for the benefit of whomever might be interested. At least, that was the way things were supposed to be. Somewhere along the way, I personally derped a change and altered the train name to 9.3-CURRENT by mistake for awhile, though the builds still got published on download.freenas.org under the original name, and the Nightlies just sort of went off the rails for awhile without a lot of people really noticing since most people stick to the 9.3-STABLE train, and we in the FreeNAS project do our own personal builds to test changes, for the most part.
Once we noticed this and went to fix it, we had a discussion about what master really meant anymore since we did most of our work in personal branches until it was time to merge, the rate of change had slowed down quite a bit (believe it or not!), and the SU mechanism also meant that what was on the various branches didn't have to be *released* until we decided it was time, so maybe we should just cut down on the branch overhead and just merge to our two stable branches (one for FreeNAS, one for TrueNAS) and cut nightlies from those - the FreeNAS 10 work was already off in its own set of branches, so it didn't need "master" anymore either - it was, for all intents and purposes, a dead branch.
So, to make an already too-long story shorter, I cut the Nightlies over to the 9.3-STABLE branch (but still published under the 9.3-Nightlies TRAIN name, since the two concepts are separate) with the general idea being that they'd still kick off once a night and let people test "what was coming" in that branch without us necessarily declaring it release-worthy until doing a release on the 9.3-STABLE train. Again, trains and branches are separate. You can have a 1:1 relationship between a train and a branch, or you can decide to have one branch feed multiple trains, the only difference being a matter of timing.
The problem was, that as much as this was true on a technical level, we had made a lot of *assumptions* about a 1:1 relationship between trains and branches because, up until that point, they were 1:1 as a matter of policy. So, everything got all "broken" for at least a week while all the assumptions were found and ferreted out, and because some of those changes were reactionary, some needed to be redone. It was basically all a bit of a clown show for awhile until I managed to figure out just how to make the Release Engineering process actually conform to the New World Order we'd established by retiring the master branch and making 9.3-Nightlies and 9.3-STABLE separate again.
So, what is the new world order? It's now (finally) pretty simple:
1. 9.3-Nightlies is the *Train* name for builds done off the 9.3-STABLE *Branch* every night at 23:30 PDT. You can install builds from that train simply by pointing your Software Update selector at it. Those builds are no longer uploaded to download.freenas.org in the interest of saving space, they're available *only* via the Software Update mechanism, so http://download.freenas.org/nightlies/9.3-Nightlies is *gone* and frankly, you never really needed those builds to begin with. To jump onto the nightlies, even from scratch, just install the latest 9.3-STABLE build and then switch trains. Easy. Read on.
2. 9.3-STABLE is both the *Train* name and the location at http://download.freenas.org/9.3/STABLE for getting the latest "blessed stable bits", e.g. official Software Updates, from the FreeNAS project. These are still published as fully installable releases (http://download.freenas.org/9.3/latest always pointing at the most recent one) and if you don't like the idea of being a tester, just stay on this Train.
The following bug query is also now even more useful: https://bugs.freenas.org/projects/freenas/issues?query_id=107
This shows you which bugs have been fixed in the 9.3-STABLE branch but haven't been rolled into a SU yet, so if you jump on the 9.3-Nightlies train you'll get those fixes and only those fixes. Once those bugs go to a Resolved state, you'll also know those fixes have jumped into the 9.3-STABLE train (again, branch != train) and are going to the wider audience.
Sorry for all the kerfuffle, and thank you for your patience as we made (and recovered from) these infrastructural changes!
The FreeNAS Development Team
It probably hasn't escaped anyone's notice that the last couple of weeks have been a little weird in terms of what's been going on with the 9.3-STABLE and 9.3-Nightlies trains. Bits have been freely commingling back and forth, ChangeLogs have been inexplicably large, or missing, or duplicated, and "Just what the heck is going on with the FreeNAS project??" some have been asking.
The short answer is that as alarming as this may have seemed from the outside, the actual "problems" in terms of getting a working FreeNAS up and running (or maintained) have been very small because all of these bits have been coming from the very same branch, and for all intents and purposes, 9.3-Nightlies and 9.3-STABLE have been very close to identical for the last couple of weeks as well, so all your bits are fine (mangled ChangeLogs notwithstanding) even if you tried to update or install in the middle of all this. So, what's been up?
Well, as most of you who are familiar with Source Code Management systems know, and we use git / github to manage all the FreeNAS bits, there can be a lot of different branches in a single repository (or spread across multiple repositories, as FreeNAS is), all being worked on at the same time in parallel in order to facilitate feature, experimental, and production lines of development. It can sometimes get a little hard for even a project's own developers to keep all the changes straight, so keeping the number of such branches low reduces the cognitive overload significantly and also ensures that things don't get "lost" by us failing to merge them, or worse, even mis-merging them across divergent lines of development and accidentally breaking things.
One of the branches we have been using for a long time in the freenas repo is called "master", a semi-standard convention in git which essentially conforms to "trunk" or "head" in other Source Code Management systems, though we did not use this convention uniformly. Some of our repositories, like ports or trueos, didn't even have a master branch and we worked from other branches (if you're geeky enough to know or care, that information is in freenas/build/repos.sh). Anyway, we also built the Nightlies from this master branch, "publishing" those nightly builds using the Software Update mechanism to a special train called 9.3-Nightlies and also pushing the builds up to http://download.freenas.org/nightlies/9.3-Nightlies for the benefit of whomever might be interested. At least, that was the way things were supposed to be. Somewhere along the way, I personally derped a change and altered the train name to 9.3-CURRENT by mistake for awhile, though the builds still got published on download.freenas.org under the original name, and the Nightlies just sort of went off the rails for awhile without a lot of people really noticing since most people stick to the 9.3-STABLE train, and we in the FreeNAS project do our own personal builds to test changes, for the most part.
Once we noticed this and went to fix it, we had a discussion about what master really meant anymore since we did most of our work in personal branches until it was time to merge, the rate of change had slowed down quite a bit (believe it or not!), and the SU mechanism also meant that what was on the various branches didn't have to be *released* until we decided it was time, so maybe we should just cut down on the branch overhead and just merge to our two stable branches (one for FreeNAS, one for TrueNAS) and cut nightlies from those - the FreeNAS 10 work was already off in its own set of branches, so it didn't need "master" anymore either - it was, for all intents and purposes, a dead branch.
So, to make an already too-long story shorter, I cut the Nightlies over to the 9.3-STABLE branch (but still published under the 9.3-Nightlies TRAIN name, since the two concepts are separate) with the general idea being that they'd still kick off once a night and let people test "what was coming" in that branch without us necessarily declaring it release-worthy until doing a release on the 9.3-STABLE train. Again, trains and branches are separate. You can have a 1:1 relationship between a train and a branch, or you can decide to have one branch feed multiple trains, the only difference being a matter of timing.
The problem was, that as much as this was true on a technical level, we had made a lot of *assumptions* about a 1:1 relationship between trains and branches because, up until that point, they were 1:1 as a matter of policy. So, everything got all "broken" for at least a week while all the assumptions were found and ferreted out, and because some of those changes were reactionary, some needed to be redone. It was basically all a bit of a clown show for awhile until I managed to figure out just how to make the Release Engineering process actually conform to the New World Order we'd established by retiring the master branch and making 9.3-Nightlies and 9.3-STABLE separate again.
So, what is the new world order? It's now (finally) pretty simple:
1. 9.3-Nightlies is the *Train* name for builds done off the 9.3-STABLE *Branch* every night at 23:30 PDT. You can install builds from that train simply by pointing your Software Update selector at it. Those builds are no longer uploaded to download.freenas.org in the interest of saving space, they're available *only* via the Software Update mechanism, so http://download.freenas.org/nightlies/9.3-Nightlies is *gone* and frankly, you never really needed those builds to begin with. To jump onto the nightlies, even from scratch, just install the latest 9.3-STABLE build and then switch trains. Easy. Read on.
2. 9.3-STABLE is both the *Train* name and the location at http://download.freenas.org/9.3/STABLE for getting the latest "blessed stable bits", e.g. official Software Updates, from the FreeNAS project. These are still published as fully installable releases (http://download.freenas.org/9.3/latest always pointing at the most recent one) and if you don't like the idea of being a tester, just stay on this Train.
The following bug query is also now even more useful: https://bugs.freenas.org/projects/freenas/issues?query_id=107
This shows you which bugs have been fixed in the 9.3-STABLE branch but haven't been rolled into a SU yet, so if you jump on the 9.3-Nightlies train you'll get those fixes and only those fixes. Once those bugs go to a Resolved state, you'll also know those fixes have jumped into the 9.3-STABLE train (again, branch != train) and are going to the wider audience.
Sorry for all the kerfuffle, and thank you for your patience as we made (and recovered from) these infrastructural changes!
The FreeNAS Development Team
