6:10 p.m.
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