On 15 Sep 2015, at 3:27, Paul Jakma wrote:
On Fri, 11 Sep 2015, Martin Winter wrote:
Yes, painful… Trying to figure out something easy. My struggle at
this time is that I’m not that clear what you are pushing next.
Each patch gets discussed on it’s own on the list and then you pick
a few of them for your next push.
Well, at the moment I'm just working forward through patchwork (from a
fairly arbitrary start-point of the point where Vincent published his
first patchwork review email earlier this year).
Also collecting some from bugzilla.
I see you giving some heads up but, not very clear on which ones.
There should be a git head in the overview email, of the patches that
were proposed that I've collected for that 'round'. I've given the
rounds numbers.
I saw the emails, but failed to match the list of patches with the git.
But not important (to me) if I can just work with the git tree…
So how about (if you plan to push multiples at the same time), you
would create a branch, apply it all there, then announce the branch
and if no objections show up within a week or two, then you merge it
into the mainline?
Is that not what I'm doing? What I've done is:
1. collected patches into heads under
volatile/patch-tracking/${ROUND}/
So far, I've only needed 1 'ff' (signifying it can be fast-forwarded
from the master commit it is based on) head under that, with
everything, but it's possible (likely) that sometimes some
contributions will need their own head under that due to clashes
2. Published a review mail for $ROUND, with the said patch-tracking
git
ref, and with URLs to the sources for each patch (patchwork + list
archive URLs; or bugzilla URL), with any questions I have about
status.
3. As ACKs, NACKs, clarifications come in I update and rebase the
proposed/ for the round - dropping patches, applying updated patches,
re-organising the ff head so the 0-objections/nits patches are first.
4. When things have quietened I reply to the review mail and propose
the
point in the proposed/ head(s) to pull into master.
Sounds mostly ok, except I worry the rebase part.. that may screw
with the CI system if commit id’s get randomly changed (and disappear)
Not sure if there is a simple way to do this without rebase.
Remainder either is dropped or carried to next round.
So looking at current git, the volatile/patch-tracking/2/proposed/ff
would be
carried on to next round? Which would then be round 3 - so I assume you
rename
the branch or merge this into a volatile/patch-tracking/3/proposed/ff ?
Better branch naming would be nice (see below).
It should be fairly secretarial/administrative. Hopefully when things
are running smoothly this function can be rotated around.
If you manage to give the branch a distinct name (i.e.
proposed-XXXXXX or something), then I could even trigger
automatically based on it. Could be even another git altogether if
you prefer.
Yes, it sounds like what is needed is a CI-tool specific label.
Yes. Something which starts with a specific word/prefix would make it
much easier for me to pick it
up automatically
as well. My plan for the patchwork plan was to potentially pick up
all new patchworks automatically, test the build on all the OS and do
some selected compliance runs. Currently struggling to finish this as
most of OSPF and BGP is broken (btw: your OSPF patch looks promising,
but still running the tests). So they currently all fail miserably.
Oh dear.
Both fixes exist by now… they may need more reviews, but I’m
optimistic and they at least fix my failed tests.
At least the VRF stuff was probably expected to cause some issues.
for COMMIT in $(git rev-list abc123..); do
git checkout $COMMIT && runci() || exit ...
done
Unfortunately not without rewriting the whole CI system (as fas as
I know). Atlassian Bamboo (which I use)
and Jenkins work in a way that they get triggered by git server
telling them that new commits are available
or by polling a git server for changes.
And they don't support doing something akin to 'git bisect' to find
the commit? Surely others must have run into this?
Hmm, seems so:
https://issues.jenkins-ci.org/browse/JENKINS-12972
Jenkins is more feature-rich, but after long attempts I gave up on it
for not getting it reliable to work. (Each bug I found got fixed, but
then each fixed version had new bugs.)
Oh dear.
I could probably trying to get something like this implemented with
enough time, but then I rather concentrate my work on catching the
bugs even earlier (i.e. with patchwork).
Also keep in mind that many crashes are not that clear cut and not
always failing or passing. For the larger runs (every few months) I
run each test at least 4 times to make sure I have consistent
results. And each test suite (= each protocol) usually takes approx
24hrs of runtime for a full pass. Splitting it into smaller batches
is possible, but then I miss issues because of bad state from
previous tests (i.e. like the case when the ospf router-id gets
changed)
It'd be nice to get more unit tests with contributions - easier to get
coverage and run than full protocol tests. Will always need full
tests, but it's a heavy way to catch small problems.
Anyway, just trying to find the best solution while keeping it as
simple as possible for maintainers pushing the commits and people
(like me testing it).
Ack. It seems like a CI marker label is needed. whether that is
manipulated on the Quagga git side, or whether it can just be on a
repo on your side that the CI tool looks at. If there was any way to
get the CI to run a script after a run and either an arg or run
separate scripts so a different action could be taken on success/fail,
then that could co-ordinate CI runs with labels in a git repo and get
it to stop at the first fail.
I think just a clear branch name which makes it clear that this is not
an experimental branch and is planned to go into
master soon is all that’s needed.
Right now I could have triggered on “volatile/patch-tracking/…”
branch name, but then I worry that next time if a
feature gets added, you may name it “volatile/feature/…” or
something. Maybe start with volatile/proposed/… ?
Regards,
Martin Winter
[email protected]
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
