Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread David Anderson
On 7/20/2017 12:37 AM, Oliver Bock wrote: Sorry, but this isn't a sustainable model. Well, it's sustained us this far. We could have a server stable branch, as you've suggested, if we could figure out how to test the server software. ___ boinc_dev

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Oliver Bock
Hi David, On 20/07/17 9:11 , David Anderson wrote: > Master is for new development. Sorry, but this isn't a sustainable model. Since only the client uses release branches *all* other components (e.g. the server!) depend on master being "usable". Therefore master should always be as stable as

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Bernd Machenschalk
On 2017-07-20 10:09, David Anderson wrote: On 7/20/2017 12:37 AM, Oliver Bock wrote: Sorry, but this isn't a sustainable model. Well, it's sustained us this far. I'm not so sure about that, at least if "us" should cover more than SETI. Most major projects that I know of use BOINC server

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Jord van der Elst
On Thu, Jul 20, 2017 at 1:12 PM, Bernd Machenschalk < bernd.machensch...@aei.mpg.de> wrote: > Rosetta's is way older (2009?) > Correction: Rosetta updated their hardware and BOINC version to 'the latest' on 23 June 2017 (http://boinc.bakerlab.org/rosetta/) (

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread David Anderson
On 7/19/2017 2:57 AM, Christian Beer wrote: understand that some exploratory implementation should be done in the meantime and I'm fine with that. But this should be happening in a separate branch NOT in the master branch which is currently used to build a 7.8 release. The 7.8 client release

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Oliver Bock
On 20/07/17 12:06 , David Anderson wrote: > As far as I can tell, none of the issues you mention have anything to do > with whether > we call master a "development branch" or an "integration branch". I know. That's why I keep trying to address that. > You seem to think that people who don't buy

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Christian Beer
Just so we are all on the same page about what issue is discussed here and how an "integration branch" can solve this. A project wants to use a version of the BOINC code that is known to be stable (because usually you choose a released version of a software to use) The BOINC server part has no

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread David Anderson
As far as I can tell, none of the issues you mention have anything to do with whether we call master a "development branch" or an "integration branch". You seem to think that people who don't buy into your world view are resistant to change. Not the case. If we had more energy going to

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Richard Haselgrove
I think this sort of discussion is exactly what I was thinking of when I asked in my initial working group paper (Christian, please copy to Bernd and Oliver, and explain the background - if you haven't already), when I asked something like: What is the current status of BOINC? Is it a computer

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread Oliver Bock
On 20/07/17 11:11 , Oliver Bock wrote: > If you don't adapt and progress it > can only get worse, in particular from the point of view of newly > interested scientists and contributors. Just in case this came across in an offending way: the "you" wasn't meant personally, it was meant as in "one"

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread David Anderson
On 7/20/2017 2:11 AM, Oliver Bock wrote: just meant to improve things - to make BOINC better. For instance, I for one just can't take over a responsible (!) role as release manager for, say, Android unless there's a codebase and a workflow I can trust. If As you know, client releases

Re: [boinc_dev] [boinc_projects] keywords

2017-07-20 Thread David Anderson
This discussion comes down to two contrasting models for software development: 1) The "waterfall model": https://en.wikipedia.org/wiki/Waterfall_model New features are done as a unit, with sequential phases (requirements, design, implementation, verification, maintenance). E.g., requirements and