9:21 a.m.
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(a)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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel