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

[Brian Behlendorf]

On 08/29/2016 12:12 AM, Petter Reinholdtsen wrote:
> 
> [Brian Behlendorf]
>> I'm sure the proposed patches work well on Debian where they were
>> developed and tested.  But they can't be accepted upstream until
>> they're reviewed and verified to work properly on other major
>> distributions.  Upstream we invest a huge amount of effort making sure
>> ZoL works properly on as wide a range of Linux targets as possible.
> 
> So, how do we get in touch with people able to test in other major
> distributions?  Which are these, btw?

A good place to start would be in the proposed Github pull request.  If
a particular proposed patch is popular enough we often have users
willing to test it on their systems.

But frankly all that I'm after is for the pull request to pass the
automated testing done by buildbot with all the new share tests enabled.
 We want to keep the testing results green.  Right now that means making
sure the tests pass on Debian, Ubuntu, CentOS, and Amazon Linux.  We'd
like to add more distributions but for now these seem to provide a
reasonable cross section to help us uncover problems.

>> Despite my concerns above I'm willing to revisit merging the existing
>> sharing patches as long as they meet the same requirements of as other
>> proposed changes.
> 
> Very good.  Then we have an opening to try to reduce the difference, and
> that is good.  My first priority would be the NFS patch, as I use NFS
> (and not SMB and iSCSI) myself.  I suspect the SMB patches are important
> to more people, thought.
> 
>> * They should be rebased against the master branch, apply cleanly, and
>> introduce no new build warnings or failures as reported by the
>> automated testing.
> 
> When you say 'automated testing', do you mean something done with each
> pull request, or something that need to be run by the requester outside
> github?

Both.  We use buildbot to run a battery of tests against a PR but those
tests can also be run locally.  There's some documentation for how to
run the ZFS Test Suite on the wiki.

https://github.com/zfsonlinux/zfs/wiki/Building-ZFS

>> * They should update and enable all of the existing 'share' tests in
>> the ZFS Test Suite.  These tests will be run by the automated testing
>> infrastructure and must to pass on all the regularly tested
>> distributions.
> 
> Right.  Where can we learn how to do this?  I know nothing about ZFS
> internals myself, but know how to program.

The ZFS Test Suite is was originally developed on Solaris and it has
been adapted for Linux.  It's purpose is to provide basic functional
testing for all of ZFSs features.  You can find it in the top level
'tests' directory along with a README which describes its operation.

All of the test cases were originally written for Solaris which usually
makes the intended behavior quite clear.  However, that's not always the
right behavior for Linux so we've needed to update many of the tests.
We have about 630 of the tests updated and passing for Linux but haven't
yet tackled the 20 or so share tests.  See the tests in:

  ./zfs-tests/tests/functional/cli_root/zfs_share
  ./zfs-tests/tests/functional/cli_root/zfs_unshare

These tests need to be uncommented in linux.run file so they get run by
default.  Then they need to be updated to reflect the behavior we want
for Linux.

Once everything is passing locally you can push it the Github and let
the automated testing have a crack at it.  For something like this we
may need to add a few packages to the test images.  Just let me know
what they are and I can get them added.

>> * They must receive positive code reviews from a ZFS developers other
>> than the author and myself.
> 
> This sound like an impossible requirement to me, given that no-one among
> the ZFS reviewers cared enough about the relevant patches for several
> years to bring the patches forward?  What make it likely that anyone
> else will look at it?

That's definitely part of the problem, we really could use additional
developers performing code reviews.  But if we consider Turbo the
original author of these changes, then anyone else from the Debian
packaging team could provide that second review.

> I hope you and Aron can get in touch while you both are there. :)

Definitely!

-- 
Thanks,
Brian