Well, git makes one's "senses reeling", at least when one has started a
career with CVS. Linus had helped us escape, and he possibly gets more
respect from me for that than for his kernel work. For me, it was the
git repository for BOINC _packaging_ that had forced me into it, long
before BOINC transitioned to git. I am still thankful for it.

So, please find a way to stop this so very outdated discussion. When you
get together now, just vote for the individual or set of individuals who
shall be in charge of what is the new_master branch from which releases
are to be branched off.  And you can have the same or other sets of
individuals in charge of any of these 7.8.x or 7.10.x branches. And you
can have individuals in charge for various features of BOINC. Heck, the
git-creator-Linus' Linux kernel just gives a very nice model of how it
can be done once it gets any complicated, just, BOINC is comparatively
simple. No need to outsmart them.

Best,

Steffen


On 07.08.17 12:20, Jord van der Elst wrote:

> 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.
>> True.
>>
>>> 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
>> branch.
>>
>> 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.
>>
>> Best,
>> Oliver
>>
>>
>>
>> _______________________________________________
>> 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.

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

Reply via email to