-----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@xxxxxxxxxxxxxxxxxx>:
>> -----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@xxxxxxxxxxxxxxxxxx>:
>>>> -----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@xxxxxxxxxxxxxxxxxx> 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.
- --
Marc Petit-Huguenin
Email: marc@xxxxxxxxxxxxxxxxxx
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJRxdv/AAoJECnERZXWan7ET2kP/A76n/IkVVzc0E+6TXEtn9kw
k43sJPp6MzaAXv+b1bEOQum4RISk0oy0BfU1b4/G7BX4Vz9OEdug59G1XhKwn3xl
SYr+14ZvK0lGptwMqHR+txgeIaSrdC5t4qWTYWri0f04BTncTQliDgEZT8GgGv/X
3edUHBxpAizGqzK6n3StrT/Rhyph58iUgrPJjBgVKddOZtTwD8UqoZ2BQ3wiRFBG
rb2rlWiR8Gf+dQVAgFm225MvqmXZiarE/3Ar9V6lbPqZtURnmaUIKrbDt0WOku2u
0mWKxq8KWhTmwiFSYLfxqQQLiuOt8v3aYId7rluW86CFo2+c+Mb/In5RfOY3hQva
A8GcGSGAzwEYYFtRg+cU9Fzp1+wJK0rdkSwMIhC05b5swbwtqE66FXYpfE7UsmCi
LpxPlsFInFGKTa/8sliz0UkCrMQs/ucv+Wi86qxLP5fNbTDJfSw+Cq6DEiNgq1t+
Z0Z90ruBiPGzU46geLA7zVIDj9cfDz6G8NHCSzEp9YaeTPMO3WumVZi9A3NLfRXr
Oi3/ay1SZadqNifEykoR6PMNT6Mx16Yh6kEKGhUuEygW/soOZLEFewaoRRGd2iFa
nLBQIdfV1nUnswz4eeQurpwUePbuBjs6IqTtGuJShMEtAIKRIldydxrnHtstazPu
CWt06knC865bbY6iz35l
=YQf9
-----END PGP SIGNATURE-----
