Hi, 2013/6/22 Marc Petit-Huguenin <m...@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 <m...@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 <m...@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 >>>>>> <m...@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-requ...@wireshark.org?subject=unsubscribe
