Re: git bikeshedding (Re: triggers in dpkg, and dpkg maintenance)
On Mon, Feb 25, 2008 at 12:19:33PM -0300, Otavio Salvador wrote:
> Robert Collins <robertc@robertcollins.net> writes:
>
> > On Sun, 2008-02-24 at 16:46 -0300, Henrique de Moraes Holschuh wrote:
> >> Yet, rebasing is still routinely performed in the Linux kernel
> >> development.
> >
> > What I find interesting and rather amusing here is Linus talking
> > negatively about rebase: in particular its propensity to turn tested
> > code (what you actually committed) into untested code (what you
> > committed + what someelse has done, in a version of a tree no human has
> > ever evaluated for correctness).
>
> If people doesn't test and review the patches after rebasing, it looks
> right but everyone is suppose to test the changes after a merging (as
> for rebasing).
I'll note that when I submit a branch, I prefer to do a rebase, and
*then* do extensive testing. That's because for a new feature, I
generally understand it better than the upstream maintaining, and *I*
want to be the one doing the merge and testing after the fact, as
opposed to assuming the upstream will do the appropriate merge fixups
and testing.
For big projects, this is essential, and Linus in fact does *not* test
after doing a merge. (It doesn't scale for him to test after every
single merge from his Lieutennants.)
But for smaller projects, it should really be up to the submitter; I
don't think there is any one Absolutely Right Way To Do It. If
someone wants to rebase and then test before sending a pull request, I
don't think there's anything wrong with that. Especially if the
projects have a good regression test suite. (Both git and e2fsprogs
have good regression tests, and that makes life *much* easier to test
after doing a rebase or a merge; basically, I'll run the full
regression test to make sure that anything unanticipated hasn't
broken, and then do explicit testing about the feature being merged or
rebased.)
BTW, because of the regression test suite, and my general policy for
e2fsprogs is that I want to make sure that "make check" has 0 failed
tests after every single commit, rebasing to collapse and remove
development history makes life easier to fulfill the "fully git
bisectable with 0 make check failures between every commit"
constraint.
So as long as the person submitting the patch makes it clear that they
have tested exactly what is being requested to be pulled, there's
nothing wrong with whether or not they do the rebase right before
sending the pull request. My preference is to do the rebase and test,
and from a smaller project such as dpkg, I can't think of any good
reason for the maintainer to force the submitters to follow one
approach or another.
Regards,
- Ted
Reply to: