Hello all,

There have been a variety of discussions regarding maintenance of stable branches, what is merged, and when qualifies a patch as suitable for a stable merge.

Out releases have been taking far too long and maintenance and support of stable branches has been troublesome. Meanwhile, the various vendors supporting enterprise products are maintaining separate repos with backported features, features that have not merged upstream, and sometimes not even submitted upstream.

With all of this in mind, I have had various discussions about the possibility of doing “rolling releases” where basically each merge is a release. Combined with this, we would change how we support stable branches. Rather than a limited upstream resource trying to maintain stable branches, we would highlight stable tags on the wiki, and welcome vendors who maintain a stable branch for their product to host that branch on the nfs-ganesha github.

Some thoughts about this:

Rather than holding features while we try and stabilize a branch, features that are ready for merging could be merged immediately.

Anyone can make a call for more extensive testing on a proposed patch that is intrusive.

Any intrusive feature should have a conditional compile option as well as a run time configuration that can disable it.

It is expected that a FSAL will be compiled against the version of Ganesha it will load into. We can explore enforcing this with something better than the “FSAL API Version”.

Any FSAL API change that requires code changes in all FSALs must be submitted with changes for all in tree FSALs such that they will compile. Such changes should be tested on all FSALs (with cooperation of stakeholders for each FSAL). Since this may not be possible for FSALs that don’t have active community members who support the FSAL, exceptions will be granted if no response is forthcoming for a given FSAL.

Such API changes will be highlighted in the wiki so those who have external FSALs can be aware that their FSAL will need changes to work post merge.

Such API changes hopefully will be rare. Any new FSAL API methods added should be added in a way that a FSAL that doesn’t supply the method but is compiled against the current Ganesha code will work without interruption. If new fields must be added to a FSAL API structure, the addition should be done in a way that a FSAL that does not reference the new field, but is compiled against the latest Ganesha will still work. These ideals will minimize the situations where all FSALs MUST be modified.

Note that functions and structures that are not declared in a header file with “fsal” in the name are nevertheless part of the FSAL API. For example, FSALs access struct gsh_export and quite a few functions.

Release numbering: One option is we simplify our release number to a single number, for example instead of the next release being V8.0, it would simply be V8. Another option is to keep the point releases, bumping the major number each time a new feature of significance is added. This would simplify documentation on the wiki as only the bug highlights since the last major release would need to be documented. On the other hand, we might see release numbers like V7.23 because there have been so many merges before a major feature was added.

In any case on release numbering, I plan to continue the V7.x numbering until we have verified that V7.x properly compiles with all desired conditional compile flag settings (i.e. with and without monitoring and QoS to name a couple troublesome ones).

The counter proposal is we follow a strict major release cadence, and then immediately open the next branch for feature submissions, but that might put the community on the hook for supporting multiple stable branches with numerous back ports and continues the problem of when something is a feature that demands being put in the next major release and when something is a bug fix needed in one or more stable branches.

The rolling release proposal may put more burden on vendors to support their own stable branches, but experience shows they need to anyway and those willing to manage upstream stable branches have been limited. There is also precedence for vendors hosting their product branch in the nfs-ganesha github with IBM having hosted its stable branches in nfs-ganesha.

I encourage as many people as possible to join the Tuesday September 30 7:00 AM Pacific Daylight Time community meeting or the September 30 4:00 PM Pacific Daylight Time secondary community meeting to continue discussion.

I hope I have captured all the important bits of the various conversations.

Thanks

Frank