Wireshark mailing list archives
Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13)
From: Bálint Réczey <balint () balintreczey hu>
Date: Sun, 23 Jun 2013 19:58:54 +0100
Hi, 2013/6/22 Marc Petit-Huguenin <marc () petit-huguenin org>:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/22/2013 09:43 AM, Bálint Réczey wrote:Hi Marc, 2013/6/22 Marc Petit-Huguenin <marc () petit-huguenin org>:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/22/2013 03:47 AM, Bálint Réczey wrote:Hi All, 2013/6/21 Marc Petit-Huguenin <marc () petit-huguenin org>:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/20/2013 04:52 PM, Guy Harris wrote:On Jun 20, 2013, at 2:58 PM, Marc Petit-Huguenin <marc () petit-huguenin org> wrote:On 06/20/2013 02:17 PM, Gerald Combs wrote:Advantates: - I'm not sure that an in-house equivalent (e.g. Gerrit plus a private repository) would be better than what Github offers.Yes, Gerrit is better than github:Presumably you mean "Gerrit plus a private repository is better than github", as Gerrit, as far as I can tell, is just software that works with a Git repository.Yes, although managing repositories being what Gerrit do, Gerrit without a least one repository would be a very boring application.:-) 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."Code is building and tests are passing on all platforms. (Tests automatically start when at least one Core Developer gives +1 or +2 to prevent overloading or cracking the build servers.)" Why do not build and test all patchsets submitted? Is that a limitation of the build servers? Having Jenkins automatically verify your patchset is IMO one of the nice feature of Gerrit, and it will lower the workload of core devs if building and testing are done before they start looking at the patchset.Build can be triggered by patchset submissin, too, but it would require more build server resources. Usually not the first version of the changeset will be accepted especially from new contributors and this means more builds.My view is the opposite: New contributors patchsets will probably be rejected anyway (does not build, does not pass test, etc...), so having the system doing that lowers the burden on core developers, who they can focus on more high level problems.Note that Core Developers would not have to wait since they can give +1 for their own changesets. The other reason behind requiring a +1 from someone we trust is that otherwise it would be easy to prepare a changeset which does unspeakable things to the build servers which we don't want to happen. Without requiring +1 we would have to prepare build systems to cope with malicious commits.That is a good point (basically because of the halting problem). But builds are done in isolation (i.e a git clone is done each time), so apart using too much resources or never ending, there is no harm that can be done to the infrastructure. And there is a Jenkins plugin to abort a build if it is stuck.
I was concerned about using the buildbots for attacking other systems, too, but all of those threats can be handled and we have time for setting up build bots properly. I have updated the proposal to start tests for every change and allow Code Devs to bypass peer review. Comments are still welcome. :-) Cheers, Balint ___________________________________________________________________________ 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-request () wireshark org?subject=unsubscribe
Current thread:
- Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Martin Kaiser (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Evan Huus (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Martin Kaiser (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Marc Petit-Huguenin (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Marc Petit-Huguenin (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 23)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Graham Bloice (Jun 23)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 24)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Michael Tuexen (Jun 24)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 24)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Anders Broman (Jun 24)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Michael Tuexen (Jun 24)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 25)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 27)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Bálint Réczey (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Martin Kaiser (Jun 22)
- Re: Proposed Gerrit workflow (was: Re: Notes from Sharkfest '13) Marc Petit-Huguenin (Jun 28)