Document is updated on Google Docs and attached as a PDF (sorry PDF
because of table)
to this email
Document is at
https://docs.google.com/document/d/1s_EbbXwqWPmfOg6ArgKmEMm_iv0vwGvJs-7ZG4yFKb4/edit?usp=sharing
The document has a list of personal choices at the end and I would
encourage everyone to
add their choice to it unless they don’t care at all.
The main discussion on the call was around the Issue/Bug tracking and
the Code Review
Issue/Bug Tracking:
- - - - -
Only few community members are aware, but we do actually have a bugzilla
for Quagga
for a long time (bugzilla.quagga.net)
The current bugzilla is self-hosted (by Paul), but very few people use
it.
We decided that we would like to try to use bugzilla more and see how
well this works for Quagga.
As part of this, the current bugzilla should be updated (it seems to be
out of date by some major
version) and we need to connect it to the mailing list to send
notifications about
new issues (and updates) to the list.
Code Review:
- - - - -
No clear favorite on the call, but it became obvious that whatever we
pick, it MUST have
a good connection to the mailing list. Someone not using the tool needs
to at least be
able to follow (read) the activity on the list and it would be desired
if it’s a two-way
interface to the list.
We do believe the email connection is possible with most/all of the
tools listed in the
document (direct or through an API)
We encourage anyone who favors a specific tool to set it up and give it
a try before
making a real decision. There are currently 5 choices listed in the
document (incl
the current way of patchwork/email). If you think we are still missing
another good
choice, then please add it to the list.
David Lamparter is looking into updating the patchwork to get the new
features as
mentioned in the document working (plus trying to add a link/flag for
the CI system
result in it as well)
Thanks for the ones who attended the call.
- Martin Winter
Quagga community needs a certain number of tools in order to ease
implementation of the process defined in this document Quagga Process Document.
In particular, a collection of tools or system that provide these
functionalities:
1. Manage code version (branch, merge, tag, …)
2. Tracking of Bugs and Issues
3. Allow patch submission
4. Ease review of submitted patch with the possibility to amend
(modify/suggest) the code
5. Ack/Nack a patch
6. Automated patch integration once accepted
7. Link to continuous integration system for tests
8. ...
1. Quagga situation
As of today, Quagga community currently uses these tools:
* Mailing list to communicate
* Git to manage the code version on savannah forge
* Quagga-dev mailing list to submit patch (Problems today: thread id is not
properly used, no HTML, cover letter must version patches, version marking
(N+1) of updates of patch is poorly used))
* Patchwork to manage patches
* Atlassian Bamboo (by OpenSourceRouting) for continuous integration
1. Mailing lists
The Quagga mailing lists are: [email protected], [email protected],
[email protected] and [email protected]. Quagga-users is used for
general discussion of matters arising out of the use of Quagga, from
installation, configuration, troubleshooting, OS-specific matters of relevance
to Quagga (e.g. tuning) to Quagga related network operations. Quagga-dev is
devoted for technical discussion of development of Quagga, from bug fixes to
improvements to development suggestions. Quagga-maintainers is devoted to
maintainers. See http://www.nongnu.org/quagga/lists.html and
http://www.nongnu.org/quagga/contacts.html.
1. Git and Repositories
Quagga will continue to use GIT as it’s scm tool. The main repository is
located in Savannah Forge which is now synchronize with GitHub repository. The
synchronization is both ways. Importantly, changes from GitHub are reflected
back on Savannah.
1. Code and patch submission
The code submission process is the same for all editions and follows the
submission process defined in [HACKING.md|TBD]. As mention in the Hacking.md
file, submitters must send their patch and code to the quagga-dev mailing list.
Patchwork system will automatically extract patch from the quagga-dev mailing
list and store them.
1. Testing and continuous integration
Quagga uses a continuous integration system which is run by NetDEF
(OpenSourceRouting.org) for the community. It that takes all submitted patches,
applies them, compiles the code on various OS platforms and tests the basic
protocol functionality (Just to make sure the protocol can be started and
neighbors are established.. On request, a complete protocol regression /
compliance test suite is run over a given Quagga release for protocol
conformity (this take 2 days).
Additional CI and regression systems that provide results publically are
welcomed by the community. (And NetDEF welcomes any support to expand their
tests as well. Details on the NetDEF setup can be found at
https://www.opensourcerouting.org/2016/05/whitepaper-how-opensourcerouting-tests-quagga/)
1. Summary
This covers only requirements 1, 3 and 7. Requirements 2 could be provided by
savannah forge (just need to activate the functionalities). Recently, Savannah
Git repository is mirrored to GitHub which provide a more modern system for
patch submission and integration as well as bugs and issues tracking which
cover requirements 2, 3 and 6. However, the crucial part for the code review
according to the new Quagga process is not covered. Indeed, no tools used by
Quagga community could provide any help for the requirement 4,5 and 6.
1. Missing tools
1. Code Review[a]
There is no system to discuss a submitted patch outside of the mailing list.
When a patch is submitted, it must go into a code review system tracking that
allows maintainers to review it easily, modify / amend in place the code,
interact with the submitter, and in turn for the submitter modify inline its
code without the necessity to resubmit a whole patch. As of today, the three
major web service providing such set of functionalities are: Gerrit, GitHub and
GitLab. Whatever the chosen system, all discussion and comments must be copied
to the mailing list in order to give to everybody the possibility to follow
discussion. Note that GitHub is now available with the Git synchronisation from
Savannah Forge and that an easy integration exist between GitHub and Gerrit
that allows to use Gerrit on top of GitHub ( http://gerrithub.io/ )
1. Issue & Bug Tracking
The Bug and Issue tracking system must be connected to the quagga-dev mailing
list in order to give the possibility to every body follow a bug resolution,
and not only the requester and the maintainers.
There exists a current Bugzilla (hosted by Paul), but it’s not connected to
mailing lists and mostly ignored by the community
CC list setting under Administration->Products->Quagga->Edit Components needs
to be set to [email protected] for all components.
1. Suggestions
In addition to the tools already used by Quagga community, here it is a list of
suggested tools. Note that some of them overlap to exist one e.g. Gerrit and
Patchwork.
1. Issue & Bug Tracking
* Activate Issue & Bug Tracking system on Savannah
* Pro: Simple to activate. Already integrated to Savannah
* Con: No APIs to manage them
* Use Issue & Bug Tracking on GitHub
* Pro: Simple to activate and use. APIs available
* Cons: Risk if GitHub Licence Agreement change to loose history
* Setup another tools like Bugzilla (maybe it is a 2nd class priority)
* Pro: Independant
* Cons: Need to setup and manage another tools
* NetDEF/OpenSourceRouting would be happy to host and maintain a JIRA Server
for the community if this is desired
Decision on conference call: Try to use current bugzilla and connect it to
mailing list. Ask people to use bugzilla when bugs are reported to users/dev?
1. Code Review
This section covers the tool available to track patches and for code review,
e.g., Gerrit, not the process of how the tool is used. Assume that all tools
copy comments/changes to quagga-dev.
1. Gerrit alone
* Pro: Must have for code review
* Cons: Need to setup and manage another server and change Git synchro to
Gerrit
* Cons: dynamic of threads is always is subset of the community
* Cons: 10y+ history of current mailing list missing
* Cons: Forces specific processes for the community
1. Gerrit on top of GitHub
* Pros: Combine advantage of Gerrit and GitHub. Simple to setup with the
Gerrit for GitHub plugin
* Cons: Perhaps too many tools. Need to be sure that PullRequest are
propagated to Gerrit
* Cons: dynamic of threads is always is subset of the community
* Cons: 10y+ dynamic
* Cons: Another company running gerrithub.io with risk of getting
discontinued on short notice
1. GitHub with PullRequest
* Pros: Already available
* Pros: can be done along with current e-mail submissions and process, and
keep everyone from quagga-dev@ involved
* Cons: Only original submitter of pull request can amend / modify patches
* Cons: dynamic of threads is always is subset of the community
* Cons: 10y+ dynamic
1. GitLab
* Pros: Independant alternative to GitHub with same feature
* Pros: Can be self-hosted
* Cons: Need to move the Git synchronisation from GitHub to GitLab. No
possibility to amend / modify patches
1. git.quagga.net + emails + patchwork
* Pros: same as Kernel community and it is a Keep It Simple logic
* Pros: anyone from quagga-dev@ is involved (discussion is forced to mailing
list and not just copied over)
* Pros: new patchwork, that you can try from
https://patchwork.ozlabs.org/project/ubuntu-kernel/list/ has new features to
track status (see A/R/T, S/W/F)
* Pros: REST API and commandline client
* Cons: it means some maintainers have to enforce and teach manually good
emails’ policy. For instance: http://dpdk.org/dev#send . But after using other
automatic tools, I could notice that even web tools require some manual policy
and teaching.
* No inline code review nor possibility to amend a patch
* Cons: Not supporting work in multiple branches as it is not clear to which
base commit the patches should apply to
* Cons: Difficult to correlate multi-part patches and potential partial
updates of some patches in a serie
*
1. (Temp) Voting Sheet
We’ll remove this chapter later, but to speed up the discussion, I would prefer
everyone reading this to highlight their preference in the table below. Feel
free to vote for “none” or anything else not listed above if this is your
preference.
Name
Issue Tracking choice
Code Review choice
Code Submission
Martin Winter
GitHub Issue Tracking
(no strong preference, but like it because of API)
Or bugzilla if API is useable
Gerrit on top of Github (gerrithub.io)
Github (as I don’t see the +1/+2 etc voting as part of Quagga process)
Mailing list + Github Pull Requests. Support both, but push for large
sets (1 of XX to Github)
Vincent JARDIN
bugzilla
emails
Upstream first (email patch) from the day 1, iterate. Do not send 50
patches of a feature, but iterate.
Stop using branches, it creates fragmentation.
Olivier Dugeon
GitHub or Savannah
Gerrit alone or on top of GitHub
Lou
No strong preference
No strong preference
Email patch + github pull requests
David Bond
GitHub or Jira (no strong preference)
Gerrit alone or on top of GitHub (I believe you can still use the
command line git review tool?)
Donald Sharp
Bugzilla especially if email is hooked up
No Strong Preference
Email( Make it easy for people to DO IT)
David Lamparter
No strong preference
Any, but must be possible to send E-Mail as input.
E-Mail + pull requests (not necessarily GitHub)
Jafar Al-Gharaibeh
Bugzilla
Email (+GitHub)
Email + GitHub Pull Requests
[a]I strongly suggest to stay on patchwork but it shall be better explained and
emails must be policed. For instance, ack't, v2 of a patch must be sent using
the thread id of the email. I do suggest this tool that has been developped by
6WIND: https://github.com/Qeole/PatchCmd -
https://addons.mozilla.org/fr/thunderbird/addon/generate-patch-command/
Why patchwork? it is basic, but other tools break the email dynamics, they are
not proven to systain history after 10y+ Thanks to emails archives, we can
still track old threads which are 10y olds._______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
