Re: [Dazuko-devel] 7 Years of Dazuko [IMPORTANT]

[John Ogness]

On 2009-02-18, Lino Sanfilippo <address@hidden> wrote:
> I suggest not to wait for mainline acceptance. As you already stated
> the process of getting dazukofs into mainline could be very long and
> cause a lot of changes to dazuko.

Yes. In fact, based on feedback from LKML, there are now changes
planned that could have dramatic effectd on how DazukoFS is used.

> So it would make sense to have a stable version for the reasons you
> gave above.

It should be clear what I mean by the word "stable" when I talk about
releasing DazukoFS before mainline acceptance. I define "stable" to
mean that the code has been tested and probably runs reliably. I do
_not_ define "stable" to mean that the interface will remain the same
(until mainline acceptance).

It is not possible for me to implement the changes required for
mainline while at the same time maintaining a different "official"
DazukoFS. And since DazukoFS is currently in the review process with
LKML, there are a lot of changes expected over the next few
months. This is something that should be very clear to everyone.

> Avira is already working successful with release 4. This is the
> version that will be shipped with the new avguard release.

That is good to hear. As far as I know, Avira is the first to make the
switch.

> So what about setting up a stable dazukofs release based on rel 4?

As I mentioned, I cannot maintain/develop multiple releases. I _can_
do a release based on rc4 (plus the patches provided by Avira). But I
will not be providing future maintenance for that release. Patches for
the release are welcome, but my focus must remain on implementing the
changes for mainline.

Releases following may (probably will) be incompatible. I will use a
versioning scheme to help clearly show incompatibility changes.

For example:
3.0.x -> rc4-based interface
3.1.x -> interface based on current recommendations from LKML
3.2.x -> interface based on some future recommendations from LKML

> There are already several patches to support other kernel versions
> for this release as well as bug fixes.  Some more bug fixes will
> follow the next days. Maybe patches to support further kernel
> versions, too.  These will all base on rel 4, since we (Avira)
> unfortunately have no time to switch to a newer release right now.
> But since rel 5 and 6 do mainly contain cosmetic changes, I think 4
> is still a good base to start from.

Agreed. I appreciate the patches.

> Another thing to mention is that every new supported kernel version
> makes it harder to apply bug fixes, since those fixes often have to
> be applied for all versions.  So it would make things a lot easier
> to have an official dazukofs version for each supported kernel
> instead of a dazukofs for one kernel version with a bunch of patches
> to support other kernels. So what do you think about this?

I do not agree. The Dazuko project has had a lot of experience trying
to support different kernel versions. As far as maintainability is
concerned, the patch-system has shown to be much easier. By using a
patch-management tool (such as "quilt") it is very easy to do
maintenance for other patches.

For the user, it is also very simple. No multiple download
packages. No ifdef's. No auto-detection scripts. Just simple patching
and building:

$ patch -p1 < my-kernel-patch
$ make
# make dazukofs_install

This is also how other modern out-of-tree projects typically handle
support for older kernel versions.

> However, it would be good if we could somehow work together on this.

Sure. The biggest help anyone can be is to test, debug, and send
patches. (Which is what you've been doing. Thanks!)

My next big step (hopefully I will find time this weekend) is to do an
official rc4-based release and redo much of the website to concentrate
only on DazukoFS.

Once that is done, others can also help by making sure the wiki is
up-to-date. (Particularly the FAQ.)

John Ogness

-- 
Dazuko Maintainer