On Wed, 2016-12-14 at 09:38 +0100, Daniel Pocock wrote: > > On 14/12/16 08:24, Andreas Henriksson wrote: > > On Wed, Dec 14, 2016 at 08:11:52AM +0100, Daniel Pocock wrote: > > > I agree the loss of Debian packaging history is a concern, that is one > > > reason I didn't clobber the existing repository and I wrote that we can > > > blow this away if there isn't consensus about it. > > > > Yeah, but ever more importantly now is to not get stuck on details I guess. > > > > > It will not be too hard to switch back and forth between the two > approaches, so lets leave the final decision on that for another couple > of weeks. > > The bigger issues: > > - should it live in the kernel section on alioth (where only members of > that team can commit) or collab-maint (where any DD can commit)? I would suggest a new project. That gives you mailing lists and the ability to add your own repository hooks. (Hooks are restricted in collab-maint for hopefully obvious reasons.) rpcbind probably also belongs in that project. Maybe gssproxy too. (Even though neither is strictly specific to NFS.) > - should it continue to list the kernel packaging team as the > maintainer, or is there potentially another team suitable for it? Given > the server-side stuff is partly kernel code, there is a strong reason > for the kernel team to see all the bug reports Now I remember, that was one of my reasons for wanting to move nfs- utils to kernel team maintenance. At the time, many or even most of the open bugs against 'nfs-kernel-server' were kernel bugs, not bugs in that package. However, that hasn't been a big issue and it shouldn't be hard for nfs-utils maintainers to continue reassigning obvious kernel-side bugs. > - does it actually work for more people? I only did basic tests of the > new 1.3.4 package with NFS 3 and a single client in a jessie system the > latest kernel from jessie-backports. Somebody should probably test the > package on a system running stretch or sid and also try the NFSv4 stuff. Ideally you would have some sort of automated tests that spin up different configurations of NFS servers and clients in some containers or VMs. (Containers would be way quicker but VMs would let you control the kernel version too.) > - does anybody have time to fully review major upstream changes? These > are things I noticed: > > Upstream now installs nfsdcltrack to /sbin - does the Debian kernel look > for it in that location too or does it want /usr/sbin/nfsdcltrack or was > that just a bug in the jessie package putting it in the wrong place? [...] The kernel's default has always been /sbin/nfsdcltrack. Ben. -- Ben Hutchings It is easier to change the specification to fit the program than vice versa.
Attachment:
signature.asc
Description: This is a digitally signed message part