On Sun, 08 Mar 2009 10:58:55 -0400 Michael Krufky <mkrufky@xxxxxxxxxxx> wrote: > Uri Shkolnik wrote: > > --- On Fri, 3/6/09, Michael Krufky <mkrufky@xxxxxxxxxxx> wrote: <snip/> > > I reviewed your tree , which is indicated by the email above, and compared it to a tree I built from the v4l 'trunk' repository + Siano's patches. > > I found out two things - > > 1) The trees are still *very* differ from each other > > 2) You applied *new* things that are _not_ included in the "old" Siano's patches (and some of them even break it). <snip/> > #1 The patches that you submitted break the currently supported devices > > #2 The patches that you submitted are not atomic > > #3 The patches that you submitted introduce regressions > > #4 The patches that you submitted have multiple changes in single patches. > > #5 The patches that you submitted are not safe for a git-bisection nor > hg-bisection > > #6 The "codingstyle cleanups" that are intertwined in your patches are > actually codingstyle regressions rather than cleanups. <snip/> Uri and Michael, We should try to do our best to avoid breaking the devices currently supported in kernel. That means that we shouldn't add a changeset that we know that it will break a device, except if we are committing, in the same patch series, another patch fixing it. This is probably the most important reason why a patch is not merged upstream. Also, we should warrant that a patch won't break the compilation of the kernel, otherwise, the standard procedure to identify a broken patch (bisect) will fail. This affects not only our subsystem, but the entire kernel, so this is another important rule to be followed on patch submission. That's said, I agree that we shouldn't commit the patch series as-is. One of you should rewrite the patch series to avoid breaking the existing cards. On the other hand, a patch shouldn't suffer large changes without the patch's author ack [1]. So, I ask you both to agree on some procedure, and to be sure to not forward me another patchset without both of you agree with it. [1] yet, small changes like codingstyle adjustments and merge conflict fixes are ok, if properly documented with the proper meta-tag, just before the SOB: [my@xxxxxxxxx: Codingstyle fixes and merge conflicts] Signed-off-by: My name <my@xxxxxxxxx> Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
