merge usbhid-dump into usbutils repo?

merge usbhid-dump into usbutils repo?

[Greg KH]

Hi Nikolai,

As you know, usbhid-dump has been part of the usbutils repo for a long
time, as a git submodule.  And that's been fine, a bit messy at times
for when I forgot to update the submodule, but overall ok.

However, I've changed the way usbutils is being released (with the 011
release that I tagged yesterday, but did not announce anywhere).
Instead of a tarball generated on my "random desktop of the day" by
running 'make distcheck' on the tree, I wanted to rely on the kernel.org
infrastructure to do a "clean checkout" of the tree and make a tarball
just based on the git repo itself.

That way people can actually rely on what is in the tarball really is
what is in the git tree, and you don't end up running some random script
that my personal machine happened to create (not a good idea).

This is fine, except when it comes to the git submodule.  kernel.org
can't be expected to pull some random submodule from a random location
into it's tree when signing things, as that would be a total mess.

So, I came up with two possible solutions:
  1) remove usbhid-dump from usbutils.
  2) move usbhid-dump into usbutils.

The first option is a bit sad, as some users of usbhid-dump might find
it go away and now all of the distros have to go and dig and find a new
package to add to their repos.  You would also then be responsible for
doing releases and notifying everyone on your own, instead of having
that done for you like it is today.

The second option is in my opinion the best one.  You can contribute
directly to the usbutils repo by providing patches/pull requests when
changes are needed.  Given the slow-down in development of this package
over the years, I doubt much is left to do on it, so that shouldn't be a
big deal.

As a test-run, I've done a merge of the usbhid-dump repo into the
usbutils repo directly, by rewriting the directory location of the
usbhid-dump repo into usbhid-dump/ and then merging the two trees
together, such that no authorship or history is lost.  You can see the
result of that here in the branch here:
	https://github.com/gregkh/usbutils/tree/usbhid-dump-merge

That branch seems to work fine for me here, with everything building
properly.

Note, if we do go with the second option, I would like to look into
"simplifying" the usbhid-dump codebase a bit, moving away from a library
and loads of include files into something a bit simpler, as the
complexity of the build system here seems a bit of an overkill for a
"simple" binary.

So, what do you think about the two options here?

thanks,

greg k-h

Re: merge usbhid-dump into usbutils repo?

[Nikolai Kondrashov]

Hi Greg,

On 5/7/19 5:00 PM, Greg KH wrote:
> So, what do you think about the two options here?

I would absolutely be glad if you could take usbhid-dump under your wing!

I have little time for the DIGImend project these days, for which it was
developed. I have a bit of financing from Patreon and occasional tablet
manufacturer to work on the drivers, but that leaves very little time for the
tools.

I wouldn't mind submitting any patches required to usbutils repo instead.
And it's true the thing haven't needed much updates recently.
Please also feel free to adjust it to your tastes too.

Thanks for looking after it!

Nick

P.S. It's awesome to see you receive Red Hat's Kernel CI effort so
positively. Everyone's cheering for your feedback every time here :)

On 5/7/19 5:00 PM, Greg KH wrote:
> Hi Nikolai,
> 
> As you know, usbhid-dump has been part of the usbutils repo for a long
> time, as a git submodule.  And that's been fine, a bit messy at times
> for when I forgot to update the submodule, but overall ok.
> 
> However, I've changed the way usbutils is being released (with the 011
> release that I tagged yesterday, but did not announce anywhere).
> Instead of a tarball generated on my "random desktop of the day" by
> running 'make distcheck' on the tree, I wanted to rely on the kernel.org
> infrastructure to do a "clean checkout" of the tree and make a tarball
> just based on the git repo itself.
> 
> That way people can actually rely on what is in the tarball really is
> what is in the git tree, and you don't end up running some random script
> that my personal machine happened to create (not a good idea).
> 
> This is fine, except when it comes to the git submodule.  kernel.org
> can't be expected to pull some random submodule from a random location
> into it's tree when signing things, as that would be a total mess.
> 
> So, I came up with two possible solutions:
>    1) remove usbhid-dump from usbutils.
>    2) move usbhid-dump into usbutils.
> 
> The first option is a bit sad, as some users of usbhid-dump might find
> it go away and now all of the distros have to go and dig and find a new
> package to add to their repos.  You would also then be responsible for
> doing releases and notifying everyone on your own, instead of having
> that done for you like it is today.
> 
> The second option is in my opinion the best one.  You can contribute
> directly to the usbutils repo by providing patches/pull requests when
> changes are needed.  Given the slow-down in development of this package
> over the years, I doubt much is left to do on it, so that shouldn't be a
> big deal.
> 
> As a test-run, I've done a merge of the usbhid-dump repo into the
> usbutils repo directly, by rewriting the directory location of the
> usbhid-dump repo into usbhid-dump/ and then merging the two trees
> together, such that no authorship or history is lost.  You can see the
> result of that here in the branch here:
> 	https://github.com/gregkh/usbutils/tree/usbhid-dump-merge
> 
> That branch seems to work fine for me here, with everything building
> properly.
> 
> Note, if we do go with the second option, I would like to look into
> "simplifying" the usbhid-dump codebase a bit, moving away from a library
> and loads of include files into something a bit simpler, as the
> complexity of the build system here seems a bit of an overkill for a
> "simple" binary.
> 
> So, what do you think about the two options here?
> 
> thanks,
> 
> greg k-h
> 

Re: merge usbhid-dump into usbutils repo?

[Greg KH]

On Tue, May 07, 2019 at 05:23:05PM +0300, Nikolai Kondrashov wrote:
> Hi Greg,
> 
> On 5/7/19 5:00 PM, Greg KH wrote:
> > So, what do you think about the two options here?
> 
> I would absolutely be glad if you could take usbhid-dump under your wing!
> 
> I have little time for the DIGImend project these days, for which it was
> developed. I have a bit of financing from Patreon and occasional tablet
> manufacturer to work on the drivers, but that leaves very little time for the
> tools.
> 
> I wouldn't mind submitting any patches required to usbutils repo instead.
> And it's true the thing haven't needed much updates recently.
> Please also feel free to adjust it to your tastes too.
> 
> Thanks for looking after it!

Wonderful, so for now, I'll push what I have done with the merging of
the two repos together and make a public 012 release of usbutils, to fix
the issues the distros have already pointed out with usbhid-dump being
gone.

And then we can go from there forward, thanks for the quick response!

> P.S. It's awesome to see you receive Red Hat's Kernel CI effort so
> positively. Everyone's cheering for your feedback every time here :)

Hey, people testing my stable queue in a very-fast manner, why wouldn't
I like it?  :)

thanks,

greg k-h