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

[Petter Reinholdtsen]

[Carlos Alberto Lopez Perez]
> Hi,
>
> Me and Peter have been checking the downstream patches that the Debian
> packages from the zfsonlinux.org repository carry for Debian jessie [1].
> The goal is ensuring a smooth transition/upgrade to the packages that
> hopefully Debian stretch will ship.
>
> Personally, I don't like at all the idea of merging new features still
> not upstreamed. But this can be discussed.

Thank you for the overview.  A similar one for the Ubuntu packages would
be nice.  We know they diverge from Debian by providing prebuild kernel
modules, but are there other differences?  Anything we should care
about.

> Maybe I'm overlooking something, and what I think is just a new feature
> that can wait for upstream to merge it, it is a critical feature for
> someone using it already in production.

Waiting for upstream to merge changes make sense if merging will happen.
I do not have any experience with the ZFS on Linux upstream, nor with
the OpenZFS upstream.  What is their relationship with each other?  Do
patches flow well between the various open ZFS projects?  I notice there
are no-one from ZoL speaking at the upcoming OpenZFS Developer Summit.
Is that because the ZoL group is less active, or nothing to worry about?

> So, the purpose of this mail is to ask for feedback regarding this.  I
> did a quick review of the patches and annotated those that I think we
> should try to merge and those I think we should skip until merged
> upstream. Feel free to add your comments on the pad itself or to reply
> to this e-mail.

It seem like a hard balance to find what to include and what to skip.
On one hand I believe all of us making Debian packages for ZFS should
try to join forces, ie the Debian, Ubuntu and ZFS on Linux deb packages
(only Turbo?) and try to make a great set of packages for use by all
Debian derivates.  Because we are so few, focusing on one set of
packages or at least reduce the differences between the three sets of
pacakges would be a good thing to save labour.  And because we are so
few, we should not give ourself extra work by diverting from upstream.
As far as I can tell, we do not have much manpower available to fix
stability and security issues introduced in Debian specific patches.  So
we should limit the diversion from upstream and the other deb packages
to a minimum, to be able to share the load if making fixes.

But we should also provide the features users expect and need to get ZFS
working out of the box with the boot systems, SMB, NFS etc, and in some
cases provide a test bed for upstream to test out changes in the code if
we consider it a service to our users.  But in these cases we must
actively try to get changes back upstream to avoid having to maintain
such patches in the future.

Introducing locla patches make most sense if the patches are going to
get into upstream in the future.  We need to actively work to reduce the
difference between the Debian packages and the upstream source code.
Otherwise we will fail sooner or later, when we no longer are able to
update the zfs packages in Debian in a timely fasion or expose our users
for unexpected stability or security issues we lack the man power to
rapidly respond to.  Who can spend some time trying to get the patches
from Debian, Ubuntu and ZoL debs into the official ZoL upstream source?

How can we set up a process to make it easier to push changes back
upstream.  I read from Turbo Fredrikson that this is non-trivial today.
Is there something we can do from the Debian side to make it easier?
Perhaps someone from this team should show up in San Francisco in a
month to join the OpenZFS Developer Summit?  Should we try to organize
developer gatherings for the ZFS people in ZoL, Ubuntu and Debian to
increase the chance of these people working together?  Can we set up
some test environments to make it easier for the upstream developers to
know if patches are likely to break something or not?  Are there other
ideas?

-- 
Happy hacking
Petter Reinholdtsen