Hi,
1) gerrit (stay as we are),
Gerrit with improved merging procedures will be a very good tool. It preserves history of reviews and allows me to display differences between patchsets easily (and lets not forget topic branches across projects).
2) github & reviewable,
Probably ok as well, I have never used reviewable. I can currently compare and correlate patches faster using gerrit though. Also lets not forget about the ecosystem, having the same gerrit instance for all projects makes it possible to use topic branches for related patches.
3) mailing list.
Been there, done that, ran away. Mailing list makes the management hard. Especially with patch revisions and large patch sets. There is no common picture (everybody has to correlate comments on their own), no unified history or changeset differences and no per line comments in the current state of things. Also many people use emails providers that do not do a good job in preserving complicated thread hierarchies. We used to use mailing list in the Anaconda project and moved to GitHub. TLDR: pure mails are hard unless you have a tree of maintainers to filter it for you and lots of time to track information down PS:
c) freedom - It's up to us to decide how would we handle such development.
Treating VDSM as a completely separate project would be a big change to the paradigm, it is currently treated as a "dumb" host proxy (just a provider of low level commands with logic in the engine) by many teams. Martin On Wed, Dec 7, 2016 at 1:06 PM, Martin Polednik <mpolednik@redhat.com> wrote:
Hello developers,
this e-mail is mostly aimed at VDSM contributors (current and potential) and should serve as continuation of the idea started at our weekly meeting.
We've had a proposal of moving the project to github[1] and using reviewable[2] as a code review due to github's code review interface.
I would like to start a *discussion* regarding how we would like to develop VDSM in future. So far, the suggested options were (1st implied):
1) gerrit (stay as we are), 2) github & reviewable, 3) mailing list.
What would be your favorite review & development tool and why? Do you hate any of them? Let the flamewar^Wconstructive discussion begin! :)
<subjective part> My preferred tool is mailing list with the main tree mirrored to github. Why mailing list in 2016 (almost 2017)?
a) stack - We're built on top of libvirt, libvirt is built on top of qemu and qemu utilizes kvm which is a kernel module. Each of this projects uses mailing lists for development.
b) tooling - Everyone is free to use tools of choice. Any sane e-mail client can handle mailing list patches, and it's up to reviewers to choose the best way to handle the review. As for sending the patches, there is the universal fallback in the form of git-send-email.
c) freedom - It's up to us to decide how would we handle such development. As many system-level projects already use mailing lists (see a), there is enough inspiration for workflow design[3].
d) accessibility - VDSM is in unfortunate position between "cool", high level projects and "boring" low level projects. I believe that we should be more accessible to the developers from below the stack rather than to general public. Having unified workflow that doesn't require additional accounts and is compatible with their workflows makes that easier. </subjective part>
[1] https://github.com/ [2] https://reviewable.io/ [3] e.g. https://www.kernel.org/doc/Documentation/SubmittingPatches
Regards, mpolednik _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel