On Sat, Jun 22, 2013 at 12:03 PM, Bálint Réczey <bal...@balintreczey.hu> wrote: > Hi Martin, > > 2013/6/22 Martin Kaiser <li...@kaiser.cx>: >> Thus wrote Bálint Réczey (bal...@balintreczey.hu): >> >>> 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. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
