Hello Paul,
Some of my colleague who are working for OpenStack told me that
GitReview is a very great system. It allows smooth code review and work
with great amount of contributors. Yeah, Quagga has not yet reach the
same numbers of developers as OpenStack :-D
I don't know which amount of work this change would imply, but I just
would share some experience with you about this tools.
Regards
Olivier
Le 18/09/2015 11:26, Paul Jakma a écrit :
On Thu, 17 Sep 2015, Martin Winter wrote:
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.
Then we'd need a workflow that avoided piping submissions through
email really. I.e. submission of git branches that could just be
merged in. Though that would render patchwork moot.
Or we need to find other tools that can provide the following in an
integrated way:
* Tracking of proposals
* Review
* CI tool co-ordination
* Git integration
Bugzilla can act as a back-end for at least 3 of those and integrate
nicely with the command-line in a git repo if used with "git bz".
Gerrit can do all of those, but it completely takes over (good for
consistency I guess).
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…
I could put in a date, but then you can't know given one round what
the next is.
If it's round 1, 2, 3... I think it's easy to know what the next round
will be. If it's 20150918, or 201509, won't always be quite as easy.
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)
Yeah, I'll sort those first so - but that needs rebase! :)
regards,
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
