Wireshark-dev: Re: [Wireshark-dev] Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13)
From: Evan Huus <[email protected]>
Date: Sat, 22 Jun 2013 12:11:45 -0400
On Sat, Jun 22, 2013 at 12:03 PM, Bálint Réczey <[email protected]> wrote:
> Hi Martin,
> 2013/6/22 Martin Kaiser <[email protected]>:
>> Thus wrote Bálint Réczey ([email protected]):
>>> I have started describing a Gerrit based workflow which IMO would fit
>>> to the project at http://wiki.wireshark.org/Development/Workflow .
>>> Please check it and share your opinion.
>> would that mean that even the most basic change needs peer review and
>> approval based on the process defined by gerrit?
>> I'm a bit worried that this doubles the time for such simple changes.  I
>> often see this in corporate environments where people don't correct
>> typos, misleading variable names, formatting etc. because they can't be
>> bothered with the administrative overhead.
> I think it depends on the people involved. In an environment similar to what
> you described I collected several small changes in short reviewable commits and
> asked for peer review for the set together.
> We can relax the rules for Core Developers to let them bypass the peer review,
> but I did not want to include this exception in the first proposal.
> Speaking of myself I would be OK with requiring peer review for all my commits,
> but it is not a surprise since I wrote the first version of the proposal. ;-)

I think to start it would be good if core could bypass peer review
(assuming the builds/tests passed of course), just so we don't change
the workflow too much at once. After people are used to that maybe we
can look at requiring peer-review again, but not for a while.

And of course if it's a big change you don't have to bypass
peer-review, you can use Gerrit it you want feedback (which will be
much nicer than trying to read the patches on Bugzilla).

> What I'm really looking forward to in the proposed Gerrit work-flow is
> the ability of having my changes
> tested on architectures I don't use _before_ applying them to the main branch.



One of the concerns Gerald raised at Sharkfest was that self-hosted
Git and Gerrit and potentially Jenkins is a *lot* more infrastructure
for him to maintain than simply a GitHub repo.