ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13)

From: Bálint Réczey <balint@xxxxxxxxxxxxxxx>
Date: Sat, 22 Jun 2013 17:03:45 +0100
Hi Martin,

2013/6/22 Martin Kaiser <lists@xxxxxxxxx>:
> Thus wrote Bálint Réczey (balint@xxxxxxxxxxxxxxx):
>
>> 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. ;-)

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.

Cheers,
Balint