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@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel