[Cluster-devel] Future developments for gfs2-utils

[Steven Whitehouse]

Hi,

With the 3.1.0 release of cluster/gfs2-utils, the release and packaging
of gfs2-utils is now independent of the rest of cluster, so we can now
follow our own release/package schedule.

I hope to have a 3.1.1 release fairly shortly whose main aim will be to
tidy up any loose ends from 3.1.0, so if you have any pending patches,
now is a good time to post them or check them in to git.

I hope that we can slim down the gfs2-utils a bit as we move forward,
and there are some plans already to do this. Currently we are hoping to
do the following:

 o Drop gfs2_tool in favour of tunegfs2
   - All the superblock editing functions will be picked up by tunegfs2,
     which as its name suggests is designed to be as close to the
     tune2fs utility in function as possible.
   - Changing filesystem options is now done entirely via the mount
     interface (or mount -o remount for already mounted filesystems)

 o Drop gfs2_quota in favour of the generic quota-tools package
  - We are currently working to ensure that all the functions of
    gfs2_quota are covered by the generic quota tools, and that
    work is almost complete

 o Drop mount.gfs2
  - For recent kernels, with a recent gfs_controld (i.e. from 3.1.0 and
    up) mount.gfs2 is optional. It will be dropped in Fedora rawhide
    first, and then removed from the source later on.

The hope is that by dropping some of the utilities, we can then spend a
greater amount of time working on those which are left.

Another development that we are working on is getting the package ready
for translation. There is already a set of extracted strings from the
utilities, and those utilities which are going away have not been
included in the list which produces the strings.

There is however a significant amount of work left to do cleaning up the
strings and ensuring that they are in a reasonable state for
translation. A number of warnings are produced when the strings are
generated which need to be fixed and some of the strings don't make
sense, even in English. Also some work reducing strings which are almost
the same to a common string will also help later translation.

Something else which I hope to introduce into gfs2-utils is a set of
tests which will help reduce the chances of buggy code being released.
I'd like to have a set of reasonably fast running tests, with few if any
dependencies outside of the gfs2-utils package which can verify some of
the basic functions of the utilities. Ideas for tests and a suitable
(simple!) framework to run them are very welcome at this stage. I would
like to be able to do "make test" and to have no requirements on the
test environment beyond some very basic common packages (e.g. a
scripting language). They need to be the kind of tests which can be run
on every build without it becoming a chore.

The above is not intended to be an exhaustive list of every development
that we have planned, but it should give a general overview of where
things are heading at the moment. Please let us know if you have any
questions,

Steve.