On Wed, 16 Sep 2015, Martin Winter wrote:
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.
We can do without rebase, but then every patch will have its own branch.
It won't be one linear tree.
To have one linear 'proposed' tree from the current master AND be able to
reject some, I need to rebase.
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 ?
The stuff in volatile/patch-tracking/2/proposed/ff that is after
volatile/patch-tracking/2/accepted either gets carried over (e.g. cause
there's further work) or dropped cause there is consensus it should be
rejected/wrong.
Better branch naming would be nice (see below).
Yeah, if further tags or changes in naming would help, let me know.
Kind of experimental at the moment, trying to find what works for
everyone, and see if we can turn it into a repeatable and mostly boring,
brainless process. :) So, yeah, if it needs changing or fine-tuning.
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
Would that perhaps be the 'accepted' branch? I.e.
volatile/patch-tracking/$ROUND/accepted. That branch we'd aim to not
rebase, and even if we did, not without waiting for the CI?
Also, the last 2 I have just emailed and said "I'll push up to commit <X>
from proposed/ff to master", and pushed the accepted tag there-after as a
marker.
So instead, we change that to
* push the volatile/patch-tracking/$ROUND/accepted head/tag, and announce
that to the list
* wait for the CI tool
* Based on that, the accepted head becomes master, or something needs
fixing
?
There's one issue, if there are contributions that clash with each other,
or that are big and tend to cause clashes, I may separate them out into
separate branches, i.e.
volatile/patch-tracking/$ROUND/proposed/<ID or label>
Though, I guess if accepted, it'll still be in that, but potentially as a
merge - not a linear fast-forward.
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.
cool. I should have them in next round (which may be a monster trying to
get everything outstanding from July onwards in - the smaller fixes
certainly).
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
No one can have a higher opinion of him than I have, and I think he's a
dirty little beast.
-- W.S. Gilbert_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
