Agrred, though the 'bottleneck' exists in sorting out the master before release. In the Stable master model there is no bottleneck, except in the hands of the fork participants. In other words, by delegating responsibility to branches/forks (i.e. people) you reduce work, and evaporate the bottleneck. It is genius.
------------------------------------------------------------------------------------------------------ Jason Richard Groothuis bSc(compSci) ------------------------------------------------------------------------------------------------------ ________________________________ From: Richard Haselgrove <r.haselgr...@btopenworld.com> Sent: Tuesday, 8 August 2017 17:56 To: Laurence; Jason Groothuis; Oliver Bock; Laurence Field Cc: boinc_dev@ssl.berkeley.edu Subject: Re: [boinc_dev] Software development and branches, was Re: [boinc_projects] keywords My concern was to acknowledge that human error exists: someone, somewhere, is bound to make a mistake. How do we maximise the chances of noticing any mistake, and correcting it quickly? In the context of release management, I see two possible classes of mistake: * Failing to ensure that a bugfix is carried forward into the next cycle * Allowing untested code to creep into a release "bugfix in master, develop in branches" seems to address both cases, by making mistakes more visible to the whole community - many pairs of eyes increase the chances of a commit to the wrong place being noticed. "develop in master, bugfix in both branch and master" allows the more silent error of failing to make the second bugfix. On Tuesday, 8 August 2017, 9:14, Laurence <lfi...@cern.ch> wrote: On 08/08/17 10:03, Jason Groothuis wrote: > > The old way is about control. The new way is about freedom. > Do the developers work directly for the project or are they autonomous but wish to collaborate? _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu<mailto:boinc_dev@ssl.berkeley.edu> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address. _______________________________________________ boinc_dev mailing list boinc_dev@ssl.berkeley.edu https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
