On Sat, Jun 22, 2013 at 12:03 PM, Bálint Réczey <balint@xxxxxxxxxxxxxxx> wrote:
> 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. ;-)
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.
+1
---
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.
