[Pkg-zfsonlinux-devel] About downstream patches on debian packages from zfsonlinux.org repository.

[Petter Reinholdtsen]

I believe it is very good for us to have this discussion, while the zfs
maintenance team is still young.  And for the record, I am discussing
which policy and priorities we should have when deciding which patches
to include in the Debian package.  I am not discussing individual
patches to prepare for a vote for/against including them.

 * Everyone seem to agree that we should try to only apply "killer
   feature" patches that are important for the users in Debian, or
   patches related to Debian integration (like improving or correcting
   init.d scripts and systemd configuration).  There is some
   disagreement about what a "killer feature" is of course.

 * Everyone also seem to agree that we should be more reluctant to patch
   the kernel part of zfs than the user space part.

 * And everyone seem to agree that we should try to push new features as
   patches upstream first, and only include the patches in Debian if the
   feature is a "killer feature" that is important to our users when
   upstream fail to include it in a timely manner.  This will cause
   extra work every time a new version of ZFS is released, so we should
   not do this a lot to keep the package maintainable.

Could these three points form the core of our policy for including
patches in the ZFS packages in Debian?  Are there other issues we should
also consider?

Part of the disagreement seem to be about how feasable it is to get some
of the ZoL patches included in the ZoL master code, and if the NFS, SMB
iSCSI and other fixes are killer features or not.  I do not really have
an opinion on this, as I have not studied the patches nor tried to use
SMB and iSCSI with ZFS.  I have tested NFS exporting using /etc/exports,
and this work as far as I can tell.  In general I agree that it would be
nice if the zfs documentation regarding nfs exports should work in
Debian, but I do not know if that is what the patch in question is doing
or not.

-- 
Happy hacking
Petter Reinholdtsen