Hello, On 07.08.17 21:40, David Anderson wrote: > Steffen: > I agree - git is here to serve us, not vice versa :-) ;) I just removed a story on why people introduce software like SAP in a company that has not seen proper controlling before. Too much text.
> I've proposed creating server release branches, > similar to the existing client release branches. > Hopefully this will satisfy everyone's needs. No. It won't it is very much off the problem. Offer separate repositories ( as in github.com/BOINC/client and github.com/BOINC/server, not branches, and you make people happier. Of course the two repositories have zero code redundancy. I understand that you do not want to update a server as often as you want to update a client. Separate release schemes seem like a natural consequence. Separate branches for maintenance are not a natural consequence. Releases are points in time. Releases are not branches but tags. So, the fear I have read on this thread is that your coworkers do not know from where to branch their development and that there is nothing reliable to merge that development back to. Steffen - will be in Budapest at the time of the workshop. Good luck! > > On 8/7/2017 7:21 AM, Steffen Möller wrote: >> 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. > > _______________________________________________ > 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.
