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
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.
