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.
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.
Remainder either is dropped or carried to next round.
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.
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.
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.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
The world really isn't any worse. It's just that the news coverage
is so much better.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
