On 17 Sep 2015, at 3:15, Paul Jakma wrote:
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.
Yes, not nice… but rebase is usually not recommended and if git IDs
change then I have a hard time to track
back to previous test run (and compare or rerun)
But open to other suggestion if you (or someone else here) has some
ideas.
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.
Same here..
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
?
We can try this for this round and then go back and fix/change the
process based on the results.
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>
I would suggest to not use linear arbitary numbers for $ROUND. Maybe
something based on date (when branch was started)?
But if I know this all starts with “volatile/patch-tracking” then
this is workable to me…
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).
Keep in mind that my results are mostly useless unless the OSPF / BGP
(vrf) fix is in the first round of
accepted. Before they are added, I just can’t test OSPF or BGP. (And
no, that doesn’t mean that they should
be rushed in and potential reviews skipped - just stating the fact that
I need them to do any decent testing)
However if they are in your “accepted” list early, then I could do a
baseline and start testing all the
future proposed/accepted patches against this baseline.
Regards,
- Martin Winter
[email protected]
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
