Thanks for that last paragraph, Oliver. You put into words what has been
running through my mind since Friday.
-- Jord van der Elst.
On Mon, Aug 7, 2017 at 9:55 AM, Oliver Bock <oliver.b...@aei.mpg.de> wrote:
> On 06/08/17 22:40 , David Anderson wrote:
> > Testing a feature in isolation is not the same as testing the system.
> > No one is advocating committing untested or buggy code into master.
> Yet it happens most of the time, mostly because *development* happens in
> master. And even if one sees a seldom feature branch for development
> it's more often than not merged to master after incomplete feature
> testing (e.g. not even a full build on all platforms). In any case
> master is broken.
> > However, feature testing doesn't mean that master is stable.
> Right, but it should be as stable as possible which requires a
> continuous improvement effort. Why is it broken and what can you do to
> actively avoid it next time?
> > For that, we need to do system-level testing in a separate release
> You're right that system-level (a.k.a. integration) testing should take
> place in a *specific* branch. However that branch should be master in
> our opinion. As Laurence pointed out: release branches are to stabilize
> and fix releases.
> I agree with Bernd: can it be that your resistance to use master for
> integration just stems from the fact that you don't like developing in
> feature branches because you're still used to CVS or SVN, and in your
> mind branching and merging still is a pain?
> > This is what we've done for years with the client software.
> Thing is, it's probably time to reconsider your view on BOINC. That "we"
> means 2-3 developers running their "own" project. BOINC is different
> now, at least it officially wants to be. You said BOINC is now a
> community project. If you really mean it, then please listen to the
> community. From what I can tell, the community is in agreement on how
> things should be done nowadays. Why are you opposing *all* of us? Also,
> you haven't yet given any concrete arguments/reasons why the model we
> propose *really* wouldn't work. So far, you stated personal
> impressions/facts that were often misinformed or in fact unrelated to
> what we discussed. All of this could be resolved constructively, it
> would just take some open mindedness. Please consider this: when you're
> thinking "why is everyone but me headed in the wrong direction?", it's
> probably about time to reconsider you own course.
> boinc_dev mailing list
> To unsubscribe, visit the above URL and
> (near bottom of page) enter your email address.
boinc_dev mailing list
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.