On 7 Jun 2016, at 3:24, Paul Jakma wrote:
Hi,
On Mon, 6 Jun 2016, Martin Winter wrote:
Paul,
from the testing side, I would appreciate if you could submit them in
multiple patches into the next proposed branch. I worry a long git
bisect nightmare to find the bad commits. (also, not sure if you
checked if each patch was successful on it’s own on my CI system).
I did look at the CI results, where they were attached to the
patchwork issue. I also did my own 'git rebase -i --exec make' test.
Some series of patches contain commits that need later commits to
compile. When the series are marked as such in the emails (as git
send-email tries to), i.e. "[patch X/Y]", the CI system seems to test
them as a unit.
However, that gets lost once applied to git.
So, as things stand, you're going to end up with a linearised
'proposed for merging to master' tree (need to find quick terms to
distinguish between the 'proposed contribution' stage and the later
'linearised, reviewed and now proposed for merging' stage ;) ) that
will contain commits that don't compile.
If it's easy I try fix such commits. E.g., MTYPEs that are added in a
later commit I might manually move to the first one that uses it. But
that's not always possible.
In the future, we could get super-strict about each commit compiling -
you should change your CI to enforce that in that case!
So even in a set of 4 patches, I would test patch 1, patch 1+2, patch
1+2+3 and finally patch 1+2+3+4 ?
Or test each on it’s own?
My preferred way to work through this would be to submit one set
(from one committer) into a proposed branch, then wait until the CI
system gives the OK (or if not then get them fixed), then push the
next set etc.. (I assume that most/all of these patches are not
disputed from the functionality and the further review is based
mostly on the implementation)
What would be cool would to have a system that auto-applied
contributions to a git branch based off the last master, and made that
available to others. And then maybe replied to the email so it'd show
up in patchwork.
I can think of two things that'd be useful:
- a branch of just the contribution on master
- an accumulating branch, so that the latest submission to the list is
applied to the previous submission on the list
That might help automate a lot of what at present is tedious manual
work. And... it seems you already have a lot of the scripts to do it?
:)
Both should be easy. I don’t see much use for the first one in case of
patches which are just a single commit (and if there are multiple parts,
then I would argue that we should rather commit the series independent
of some proposed branch on approval directly to master (or whatever the
working branch is).
For the 2nd choice, this would only be added to the accumulating branch
on successful pass of the tests.
If you want me to try this, then suggest something (i.e. name of
accumulating branch?) and I can give it a try.
- Martin Winter
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
