[Spice-devel] [spice-gtk] usb-redir: use persistent libusb device on Windows

[Christophe Fergeau]

On Mon, Feb 25, 2019 at 04:07:03PM +0200, Yuri Benditovich wrote:
> On Fri, Feb 22, 2019 at 2:06 PM Christophe Fergeau <cfergeau at redhat.com> wrote:
> > I don't think we should have a hard limit on the number of lines in a
> > patch, however there should be a maximum of 1 logical change per commit,
> > see https://www.berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/
> > for example for a rationale about this.
> > https://gitlab.freedesktop.org/teuf/spice-gtk/tree/gudev would be a
> > rough attempt at such a split (but authorship needs to be set back to
> > you, commit logs needs to be more verbose, ...).
> >
> 
> IMO, this is excellent example of why this approach is wrong.
> For example, there is definitely wrong commit
> https://gitlab.freedesktop.org/teuf/spice-gtk/commit/0135d831bc8929e45bac065f47daa1b4470ab7b0
> But nobody notice it as the problem in it fixed toward end of chain.

When I said "rough attempt at such a split", I meant it to be read as
"this is an untested proof of concept". So yes, there are bugs ;)

> Which tests are expected after _each_ commit?

Really depends on what the commit is doing. Each commit should build,
and basic functionality should still be working. I'd usually keep
extensive testing for the final patch, if some things are broken, I'd
move the fix to the right place, and possibly do more testing for the
commit which was broken.
In an ideal world, >95% of the testing would be automated, which would
make it trivial to test each commit..

Christophe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/spice-devel/attachments/20190304/58be02cb/attachment-0001.sig>