On 05/06/16 18:09, rindeal wrote: > On 5 June 2016 at 18:53, M. J. Everitt <m.j.ever...@iee.org> wrote: >> On 05/06/16 17:49, rindeal wrote: >>> On 5 June 2016 at 18:40, Kent Fredric <kentfred...@gmail.com> wrote: >>>> On 6 June 2016 at 04:31, rindeal <dev.rind...@gmail.com> wrote: >>>>> Isn't no commit approach better than having broken commit + revert >>>>> commit? >>>> Huh? >>>> >>>> Its doing "replicate to github on pass using a merge commit". >>> I'd like to see the master branch free of commits which do not pass >>> CI, instead of having broken commits and holding master back until >>> revert commits are introduced. >>> >> Which is the whole idea .... 'stable' becomes fully CI parsed good >> 'green light' whereas master is a 'holding bay' until the CI script can >> do its stuff .. >> > It is not, unless CI filters the broken commits in some miraculous > way. With the current approach, both stable and master branch will > contain the pollution of broken commits + their fixes, instead of > having good commits only. To eliminate errors completely, you also remove any form of progression. As the old proverb goes "you can't make an omelette without breaking eggs"....
This way, at least the bad commits /get/ fixed *before* they are pushed out to unsuspecting users ... ok so its not perfect, but this _is_ the real world here ......
signature.asc
Description: OpenPGP digital signature
