Re: [boinc_dev] [boinc_projects] keywords

2017-07-24 Thread Oliver Bock
Hi David,

On 22/07/17 10:13 , David Anderson wrote:
> On 7/21/2017 1:26 AM, David Wallom wrote:
>> the responsibility for functions to different community groups. As
>> such it will be essential that we move to a multi branch development
>> methodology in some form of public repository. I use this in a large
>> number of my current international projects and it works well.
> Interesting idea.  Do you know if Github has these sorts of features?

Can you please elaborate on what idea exactly you find interesting?
"multi branch development" is what we've been discussing all the time in
this very thread (and elsewhere on this list before). Also, what
"features" do you think Github needs to explicitly support? Forks and
branches are the basics of distributed development - Github is designed
around just that.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

Re: [boinc_dev] [boinc_projects] keywords

2017-07-22 Thread Steffen Möller


On 22.07.17 10:13, David Anderson wrote:
>
> On 7/21/2017 1:26 AM, David Wallom wrote:
>> the responsibility for functions to different community groups. As
>> such it will be essential that we move to a multi branch development
>> methodology in some form of public repository. I use this in a large
>> number of my current international projects and it works well.
> Interesting idea.  Do you know if Github has these sorts of features?
I have seen that with the Rosetta code base - you have multiple
groups/lead researchers  that offer stable "theme-master" branches from
which others then branch off and then send pull requests to their lead.

Steffen

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

Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread Christian Beer
On 21.07.2017 06:21, David Anderson wrote:
> Stable branches for server and API: yes.
> (prerequisite to this is a way of thoroughly testing these components,
> which we don't currently have.
> How about if people start discussing this?)

I don't see having thorough tests as a prerequisite to having a stable
branch. What matters is that we are working toward making a branch
stable by finding ways to test the code. Testing the code is a technical
issue to be solved. Declaring what branches there should be is a
management issue. Both are independent from each other. We can decide
what branches to use for what purpose before we implement tests. In fact
I think it would be easier to make the decision about the branching
model up front and then gradually implement tests on the stable
branches. After some time we then declare the stable branch to be
stable. It does not need to be stable from the beginning.

I already made several attempts to discuss using testing frameworks in
BOINC. There was no resonance at the time. What I want BOINC to do is to
make an informed decision what framework to use before starting to
implement actual tests are even begin to implement a custom test
framework. What I also want to prevent from the start is that I'm the
only user of this test framework. If BOINC is going to get a test
framework their must be a decision to make sure that every new feature
needs to have accompanying tests (that are derived from a reference or
are the reference themselves). When fixing bugs it should also be made
mandatory to check if an automated test would have caught this bug and
then provide such a test alongside the bugfix. These simple rules, when
enforced, make sure that at least over time the code coverage of tests
will increase.

>
> Separate branch for TBD: no.
> TBD has its own completely separate repo.
> It requires some features in BOINC (such as keywords)
> which are of general utility beyond TDB.

The features that TBD needs in BOINC should go into a feature branch and
once they are tested they are merged into master. This is to ensure that
if a project decides to update their server code while this new feature
is developed they don't get a not-production ready feature built into
the scheduler when they checkout the master branch. This is, as I see
it, the case right now and this is what sparked my initial message.
There are other developers working on BOINC at the same time and we
somehow need to coordinate our work and how to integrate it into BOINC.
With git and github we have powerful tools available that help us in
this regard and that help us automate a lot of the stuff that needs
doing we just need to embrace them and use them.

Regards
Christian
___
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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread Bernd Machenschalk

Hi David!

On 2017-07-21 00:50, David Anderson wrote:
This discussion comes down to two contrasting models for software 
development:


1) The "waterfall model":

...

2) The "agile model":
https://en.wikipedia.org/wiki/Agile_software_development
New features are divided into smaller self-contained pieces,
which are completed and merged with master frequently.
Requirements and design can change on the fly.
Development need not be done in a separate branch.


The "agile model" (as referenced by you) doesn't say anything about SCM 
or branches. However, collaborative agile development requires and 
implies doing basically all development (bugfixes, features, etc.) in 
branches (see e.g. https://www.atlassian.com/agile/branching) to isolate 
development, until a development is complete and merged back into a 
'master' branch (that may or may not be called like that).



Master is unstable in both models; releases are done from stable branches.


Where do you get that from?


2) I often work on several things at once.
If I do each one in a separate branch,
I inevitably commit code to the wrong branch,
and it's hard to untangle things later.


When working on many things in parallel, working in branches even helps 
me to stay structured and focused. There are tools to keep track of 
which branch you are currently on, and ways to move commits from one 
branch to another, if you accidentally committed to the wrong one.



3) I want my code reviewed and tested by others ASAP.
I have only Win7 and Linux computers.
If my code doesn't work on other platforms, I want to know this ASAP.
I want to commit to master in small-size, frequent units.


That doesn't require using a single branch ('master' or other). 
Continuous Integration (like Travis on github) can and does test 
(virtually) every branch on every configured platform. Everyone can 
check out any branch and test this, without being affected by any 
problems introduced by other development (in master) he doesn't care about.



4) It's worked extremely well so far.
BOINC has evolved rapidly and continuously over 15 years.
It's still very malleable and well-structured, making it easy to 
change and add.


Apparently it worked for you quite well. However the way BOINC has been 
developed in the past years is causing a lot of volunteer developers 
quite some headache and trouble, up to the point where they quit 
contributing. This is exactly why it needs to be improved.


Best,
Bernd

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


Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread David Wallom
Indeed we have drifted from the original keywords discussion already (

David

--
===
Professor David Wallom
Associate Professor
Oxford eResearch Centre
University of Oxford
7 Keble Road
Oxford
OX1 3QG
UK

Tel: 01865 610601
===


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


Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread Oliver Bock
On 21/07/17 10:26 , David Wallom wrote:
> Another thing I would like to introduce (at risk of a large back lash
> ;) is the type of open source license currently used for BOINC.

Please let's use a different thread and/or the workshop to discuss this.

Thanks :-)



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread David Wallom
Hi,

If we are to build a much larger community of developers from within the 
current larger users of BOINC then we are going to have to adopt best practice 
processes for collaborative software development. As such this for example is 
one of the things that the Workshop 2017 is to focus on. Unlike previous WS 
which were more generalized the first day is going to specifically have 
sessions for the discussion on how BOINC as a community moves forward, removing 
points of weakness due to the current small developer community and hopefully 
in the process distribute the responsibility for functions to different 
community groups. As such it will be essential that we move to a multi branch 
development methodology in some form of public repository. I use this in a 
large number of my current international projects and it works well.

 Another thing I would like to introduce (at risk of a large back lash ;) is 
the type of open source license currently used for BOINC. We have had 
approaches from non-academic parties who would like to use BOINC but who for 
legal reasons cannot without significant additional work due to its current 
license. Moving from LGPL would be beneficial.

David

--
===
Professor David Wallom
Associate Professor
Oxford eResearch Centre
University of Oxford
7 Keble Road
Oxford
OX1 3QG
UK

Tel: 01865 610601
===


On 21/07/2017, 08:58, "boinc_dev on behalf of Steffen Möller" 
 wrote:

Don't know how much it is worth, but as a part-time contributor to
_many_ Open Source projects (and once having worked with a computer
science degree as a software engineer for a software company that does
software environments for software development) I would like to express
my wholehearted support for Oliver's position.

Quick summary: Developments in branches that branch from master and are
merged back to master once the development has completed. Strategic
adjustments have an influence on the developments that are started but
have no direct effect on the master branch. Of course you can always
fork or name master something else. But you always have something stable
to branch your new developments from.

Steffen


On 21.07.17 09:49, Oliver Bock wrote:
> Hi David,
>
> On 21/07/17 0:50 , David Anderson wrote:
>> This discussion comes down to two contrasting models for software
>> development:
> Sorry, no, that's not the point.
>
>> 1) The "waterfall model":
>> 2) The "agile model":
> I know both models very well, professionally and scientifically.
>
>> Requirements and design can change on the fly.
>> New features are divided into smaller self-contained pieces,
>> which are completed and merged with master frequently. 
> Yes, totally right.
>
> (master serving as integration branch in this case)
>
>> Development need not be done in a separate branch.
> Where does this conclusion come from? To the contrary: agile
> development, due to its velocity, needs separate feature/topic/fix
> branches because many developers need to work on the same codebase at
> the same time, without interfering with each other. One needs
> coordination (by workflow). Also, developers need a stable base to start
> off from, not something that's broken most of the times. How do you want
> to achieve that when everyone develops (let alone tests) in the same
> branch? How do you want to do integration tests without affecting
> development or release maintenance?
>
> Please ask yourself why tools like git, global agile development and
> particular SCM workflows like GitFlow more or less arrived and spread
> massively at the same time. Mere correlation or actual causality...?
>
>> Oliver prefers the waterfall model,
> The opposite is true. I'm all for agile development like Scrum and I'm
> even evangelizing to do so wherever I go (and see fit). Why have I tried
> for years to convince BOINC to move to git and make use of Continuous
> Integration for instance? Because I prefer the waterfall model?
>
>> so strongly that he won't work with people who use agile.
> This all leaves me kind of speechless. I can't even fathom how one can
> reach a conclusion like that, based on what I've described. In
> particular since SCM (that's all we talked about in this thread) is just
> one part of implementing a process model instance, it doesn't define it.
>
> There are obviously severe misunderstandings at play here and I'm
> honestly starting to doubt they can be overcome - unless other projects
> step up and chime in as well.
>
>> I prefer the agile model for several reasons:
> All those reasons/motivations (first sentence of each given bullet) are
> absolutely fine. Unfortunately the conclusions/consequences reached are
> wrong. What I and others proposed *will help you* with what you're doing
> and trying to achieve as it's at the heart of agile development. So far
> we've just failed to show 

Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread Steffen Möller
Don't know how much it is worth, but as a part-time contributor to
_many_ Open Source projects (and once having worked with a computer
science degree as a software engineer for a software company that does
software environments for software development) I would like to express
my wholehearted support for Oliver's position.

Quick summary: Developments in branches that branch from master and are
merged back to master once the development has completed. Strategic
adjustments have an influence on the developments that are started but
have no direct effect on the master branch. Of course you can always
fork or name master something else. But you always have something stable
to branch your new developments from.

Steffen


On 21.07.17 09:49, Oliver Bock wrote:
> Hi David,
>
> On 21/07/17 0:50 , David Anderson wrote:
>> This discussion comes down to two contrasting models for software
>> development:
> Sorry, no, that's not the point.
>
>> 1) The "waterfall model":
>> 2) The "agile model":
> I know both models very well, professionally and scientifically.
>
>> Requirements and design can change on the fly.
>> New features are divided into smaller self-contained pieces,
>> which are completed and merged with master frequently. 
> Yes, totally right.
>
> (master serving as integration branch in this case)
>
>> Development need not be done in a separate branch.
> Where does this conclusion come from? To the contrary: agile
> development, due to its velocity, needs separate feature/topic/fix
> branches because many developers need to work on the same codebase at
> the same time, without interfering with each other. One needs
> coordination (by workflow). Also, developers need a stable base to start
> off from, not something that's broken most of the times. How do you want
> to achieve that when everyone develops (let alone tests) in the same
> branch? How do you want to do integration tests without affecting
> development or release maintenance?
>
> Please ask yourself why tools like git, global agile development and
> particular SCM workflows like GitFlow more or less arrived and spread
> massively at the same time. Mere correlation or actual causality...?
>
>> Oliver prefers the waterfall model,
> The opposite is true. I'm all for agile development like Scrum and I'm
> even evangelizing to do so wherever I go (and see fit). Why have I tried
> for years to convince BOINC to move to git and make use of Continuous
> Integration for instance? Because I prefer the waterfall model?
>
>> so strongly that he won't work with people who use agile.
> This all leaves me kind of speechless. I can't even fathom how one can
> reach a conclusion like that, based on what I've described. In
> particular since SCM (that's all we talked about in this thread) is just
> one part of implementing a process model instance, it doesn't define it.
>
> There are obviously severe misunderstandings at play here and I'm
> honestly starting to doubt they can be overcome - unless other projects
> step up and chime in as well.
>
>> I prefer the agile model for several reasons:
> All those reasons/motivations (first sentence of each given bullet) are
> absolutely fine. Unfortunately the conclusions/consequences reached are
> wrong. What I and others proposed *will help you* with what you're doing
> and trying to achieve as it's at the heart of agile development. So far
> we've just failed to show you how.
>
> Apart from that there are other developers, projects and contributors
> (existing and prospective) who depend on how BOINC's SCM is done. I
> think we agree that their needs need to be taken into account as well,
> even if you have the impression that their needs are at odds with yours
> - which might not even be the case.
>
>> Also, let's not confuse the choice of model with how we do stable branches.
> Precisely!
>
>
> HTH,
> 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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-21 Thread Oliver Bock
Hi David,

On 21/07/17 0:50 , David Anderson wrote:
> This discussion comes down to two contrasting models for software
> development:

Sorry, no, that's not the point.

> 1) The "waterfall model":
> 2) The "agile model":

I know both models very well, professionally and scientifically.

> Requirements and design can change on the fly.
> New features are divided into smaller self-contained pieces,
> which are completed and merged with master frequently. 

Yes, totally right.

(master serving as integration branch in this case)

> Development need not be done in a separate branch.

Where does this conclusion come from? To the contrary: agile
development, due to its velocity, needs separate feature/topic/fix
branches because many developers need to work on the same codebase at
the same time, without interfering with each other. One needs
coordination (by workflow). Also, developers need a stable base to start
off from, not something that's broken most of the times. How do you want
to achieve that when everyone develops (let alone tests) in the same
branch? How do you want to do integration tests without affecting
development or release maintenance?

Please ask yourself why tools like git, global agile development and
particular SCM workflows like GitFlow more or less arrived and spread
massively at the same time. Mere correlation or actual causality...?

> Oliver prefers the waterfall model,

The opposite is true. I'm all for agile development like Scrum and I'm
even evangelizing to do so wherever I go (and see fit). Why have I tried
for years to convince BOINC to move to git and make use of Continuous
Integration for instance? Because I prefer the waterfall model?

> so strongly that he won't work with people who use agile.

This all leaves me kind of speechless. I can't even fathom how one can
reach a conclusion like that, based on what I've described. In
particular since SCM (that's all we talked about in this thread) is just
one part of implementing a process model instance, it doesn't define it.

There are obviously severe misunderstandings at play here and I'm
honestly starting to doubt they can be overcome - unless other projects
step up and chime in as well.

> I prefer the agile model for several reasons:

All those reasons/motivations (first sentence of each given bullet) are
absolutely fine. Unfortunately the conclusions/consequences reached are
wrong. What I and others proposed *will help you* with what you're doing
and trying to achieve as it's at the heart of agile development. So far
we've just failed to show you how.

Apart from that there are other developers, projects and contributors
(existing and prospective) who depend on how BOINC's SCM is done. I
think we agree that their needs need to be taken into account as well,
even if you have the impression that their needs are at odds with yours
- which might not even be the case.

> Also, let's not confuse the choice of model with how we do stable branches.

Precisely!


HTH,
Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

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 (including Android) are build from
a stable branch like client_release/7/7.8.
Not from master.
The workflow for master isn't relevant here.
Let's not confuse things.

Adopting a particular SCM model isn't a magic wand that will somehow fix 
everything.
The issues you mention are, I think, not much related to SCM; e.g.:
- The reasons small research groups aren't creating BOINC projects is that the
  risk/reward economics are unfavorable and the documentation is sub-par.
- Some projects made changes to the server code and didn't do the 10% extra work
  of merging them into master, so it becomes progressively harder for them to 
upgrade.


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


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 design don't change during implementation.
Typically, development is done in a separate branch,
which is merged with master at the end.

2) The "agile model":
https://en.wikipedia.org/wiki/Agile_software_development
New features are divided into smaller self-contained pieces,
which are completed and merged with master frequently.
Requirements and design can change on the fly.
Development need not be done in a separate branch.

The role of master differs somewhat.
It changes more frequently in the agile model.
Master is unstable in both models; releases are done from stable branches.
In both models there may be periods when master doesn't work.
These periods are more frequent in the agile model.

---

Each model has pros and cons.
The waterfall model is generally regarded as old and ineffective.
The corporate software world has found that the agile model generally works better 
for them,

and has moved to it en masse.
For distributed open-source projects like BOINC,
the agile model has some aspects - such as a daily face-to-face "scrum" meeting 
-
that would be difficult to do, so it must be adapted somewhat.

Oliver prefers the waterfall model,
so strongly that he won't work with people who use agile.
I'll leave it to him to explain this preference.

I prefer the agile model for several reasons:

1) In the way I develop, requirements/design/implementation proceed iteratively and 
in parallel.

I find many situations where the implementation has become difficult or awkward,
and I can fix this by changing the design or even the requirements.

2) I often work on several things at once.
If I do each one in a separate branch,
I inevitably commit code to the wrong branch,
and it's hard to untangle things later.

3) I want my code reviewed and tested by others ASAP.
I have only Win7 and Linux computers.
If my code doesn't work on other platforms, I want to know this ASAP.
I want to commit to master in small-size, frequent units.

4) It's worked extremely well so far.
BOINC has evolved rapidly and continuously over 15 years.
It's still very malleable and well-structured, making it easy to change and add.
Very few big software systems can say this.


Which model should we use in BOINC?
I don't think we need to pick one or the other.
The owner of each software area (client, manager, etc.) could choose one.
Or we could leave it up to the developer.

And, as I've said repeatedly, the major problems facing BOINC -
such as the inadequacy of documentation
and the lack of volunteers for software release management -
don't involve software development,
the choice of model doesn't have much bearing on them.
Let's not get hung up on it.

Also, let's not confuse the choice of model with how we do stable branches.
Of course we need stable branches for server software and API.
The agile model doesn't preclude this.

-- David

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


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 science experiment, or is 
it mature scientific infrastructure?

To me, as a relative outsider and not a technical expert at your levels, it 
feels as if "throw everything into master and see if it floats" is the 
experimentalist's answer. I hope I'm not distorting your words too much if I 
suggest that the 'mature infrastructure' approach - if it is to survive the 
next 15 years - needs pre-release development branches for each of client, 
server, and API, all with their own distinct version control; and a separate 
branch for major direction changes like the NSF-funded TBD (which I suspect - 
though it wasn't made explicit at the time of the commit - is what really 
sparked this thread off).

On Thursday, 20 July 2017, 16:12, Oliver Bock  
wrote:
 

 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" or referring to BOINC as a
project. Sorry if I phrased this ambiguously in my non-native tongue.

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.


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" or referring to BOINC as a
project. Sorry if I phrased this ambiguously in my non-native tongue.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

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 versioning thus projects can only checkout
the branch named "master" at the moment.
The code in this branch is not guaranteed to work for the project, it is
not even guaranteed that the code in this branch compiles successfully.
So currently you could characterize "master" as a development branch.
All development is happening on this branch and it is supposed to be
buggy and broken from time to time. That is not what a project wants to
use for a public facing project.
Because using a development branch means the project needs to do tests
before deploying the code on the public project or risk a lot of cleanup
work if problems are encountered afterwards. This is usually not what
project administrators are paid for, it might even be that the project
admin does not have the skills to troubleshoot problems in the BOINC code.

Remember projects want to have the possibility to get source code that
has already been tested (to some degree) and at least is guaranteed to
compile. Having an "integration branch" would solve this issue.
Because the workflow changes a bit when new features and bugfixes are
developed and a branch is named the "integration branch".
New features are developed in so called "feature branches" that are
forked from the "integration branch".
When a feature is mature enough and tested to do what it should do it is
then merged into the "integration branch".
This way it is guaranteed that the "integration branch" has some
properties that are wanted by projects (see above).
In this scheme the "feature branches" are characterized as "development
branches" and the branch called "master" is the "integration branch".

I found a nice graphical overview how this "Integration branch" system
works too: https://backlogtool.com/git-guide/en/stepup/stepup1_5.html

In this approach the burden to test features and bugfixes is moved from
the project to the developer (where it rightfully belongs). Each
developer can also make sure that he/she is not meddling with
development going on at the same time by other developers (because they
are using different feature branches). This approach also helps
developers to make sure that they don't introduce unnecessary bugs or
typos into a branch that is used by projects because they would be
spotted in the feature branch.

This "integration branch" approach can later be augmented by automated
tests that regularly run on the "integration branch" to make sure it is
as stable as we want to have it. You can simply increase stability of
the "integration branch" by simply adding useful unit tests that test
individual features as well as an overall integration test that tests
all features (to some extend).

I hope this clears up how the "integration branch" approach can help to
fix the issue Oliver and I presented.

Regards
Christian

On 20.07.2017 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".
>
> 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 understanding code, fixing bugs,
> writing documents, etc.,
> from the people who are able to do so, rather than dogmatic posturing,
> we'd all be better off.
>
> On 7/20/2017 2:11 AM, Oliver Bock wrote:
>> On 20/07/17 10:09 , David Anderson wrote:
 Sorry, but this isn't a sustainable model.
>>> Well, it's sustained us this far.
>> Well, in that case we have a different understanding of "sustainable".
>> Yes, BOINC survived, barely, but did it strive? Is it easy (let alone
>> fun) to use for downstream projects? Did it attract a healthy number of
>> volunteer developers after the alleged transition into a community
>> driven open source software (OOS) project? Sure, source code management
>> (SCM) isn't all there's to it but it's a significant part of it. Maybe
>> you underestimate its effect? I'm also nearing a ten-year involvement in
>> BOINC and way too often it's been a pain to use it as a downstream
>> project because of the way its SCM is done. It's codebase is brittle and
>> just can't be trusted, unnecessarily. 15 years ago the tools and best
>> practices were different. But these things are moving. Why not
>> participate in the progress that's been made since then, making
>> everyone's professional life easier and BOINC more attractive? Yes, that
>> means change, but it doesn't hurt. 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.
>>
>> What I'm trying to say is: responding to constructive criticism with
>> 

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 into your world view are
> resistant to change.
> Not the case.

If you really think that this is "my" (exclusive) world view than that's
part of the problem. Sure, our opinions differ and that's ok. Please
consider that your world view is also subjective and should be reflected
upon not to get skewed. Do you honestly think that either BOINC's
software engineering significantly improved over the last 10 years or
that it's just fine as it is? Why do projects still face upgrade issues
and broken builds (see GPUGrid)? Why are client releases like 7.8 still
broken, despite having a comparatively elaborate release workflow? SCM
methodology plays a large role in this.

> If we had more energy going to understanding code, fixing bugs, writing
> documents, etc.,
> from the people who are able to do so,

You're right. But in order to do that I think two things need to happen:

1) Improve the processes (SE/SCM workflow, automation, etc) such that
energy can be used for the things you listed. Don't waste energy on bugs
and self-inflicted issues that could be avoided by improved processes.
That said, I'm proposing ways to increase efficiency which is
particularly important considering the scarce resources at hand. That
should be in BOINC's best interest.

2) Attract more energy by being an attractive OSS project. Granted, we'd
have to agree on what spurs attractiveness first.

> rather than dogmatic posturing,

Oh, that's what I do? "Dogmatic posturing"? To the contrary, I'm making
proposals that are fully open to discussion. I like to start discussions
to improve things that I (and a number of others) consider to be in need
of improving. Sadly, I'm often enough the only one (or one of very few)
who actually (still) publicly sticks his neck out and voices
constructive criticism. Do you think that calling my well-intended
attempts "dogmatic posturing" can be considered "open", helpful to a
previously factual discussion or is by any means inviting further
contributions? There's no need to make this personal.

Oliver



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

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/) (
http://boinc.bakerlab.org/rosetta/forum_thread.php?id=6893)

-- Jord van der Elst.
___
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.


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 code that is 
as outdated as their requirements allow, and do their own development 
based on that old version. Ours (E@H) dates back to early 2012, 
Rosetta's is way older (2009?), WCG uses the first git migration (late 
2012).


Projects are worried first about stability and reliability, then about 
features they may need. You certainly don't want to build your project 
code - that should reliably manage some 100k machines of some 10k users 
that you don't want to alienate - from a branch that every intermediate 
half-baked commit of a handful of features that is worked on in parallel 
gets committed to. That's what's driving GPUgrid away, and that shows 
that - in my understanding of 'sustain' - it DOESN'T sustain.


We could have a server stable branch, as you've suggested, if we could 
figure out how to test the server software.


A system as complex as BOINC can only be trusted as a whole by building 
up trust from the ground up, i;e; by building trust to its components. 
This means that testing the "server software" means and requires testing 
its components. Testing, of course, can only mean testing the behavior 
compared to a specification (even if the specification isn't written 
down explicitly; then the test defines the specification). This, in 
turn, means you would better have a specification, at least for each 
module and interface, which first should be verified on its own for 
correctness and completeness. Then you can write a test 
case/program/whatever for this module. Then you can test this module to 
conform to your specification.


Basically there is no point in testing a module or a system as long its 
(desired) behavior isn't specified.


Best,
Bernd

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


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 understanding code, fixing bugs, writing 
documents, etc.,
from the people who are able to do so, rather than dogmatic posturing, we'd all be 
better off.


On 7/20/2017 2:11 AM, Oliver Bock wrote:

On 20/07/17 10:09 , David Anderson wrote:

Sorry, but this isn't a sustainable model.

Well, it's sustained us this far.

Well, in that case we have a different understanding of "sustainable".
Yes, BOINC survived, barely, but did it strive? Is it easy (let alone
fun) to use for downstream projects? Did it attract a healthy number of
volunteer developers after the alleged transition into a community
driven open source software (OOS) project? Sure, source code management
(SCM) isn't all there's to it but it's a significant part of it. Maybe
you underestimate its effect? I'm also nearing a ten-year involvement in
BOINC and way too often it's been a pain to use it as a downstream
project because of the way its SCM is done. It's codebase is brittle and
just can't be trusted, unnecessarily. 15 years ago the tools and best
practices were different. But these things are moving. Why not
participate in the progress that's been made since then, making
everyone's professional life easier and BOINC more attractive? Yes, that
means change, but it doesn't hurt. 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.

What I'm trying to say is: responding to constructive criticism with
"that's how we've done it for 10+ years, no need to change" isn't very
helpful if you want to see things improve. My proposal is (once again)
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
ideas, proposals or contributions aren't discussed at all or rejected
without meaningful reasoning people will stop trying. I'm sure that's
not in your interest.

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.


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


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
possible. That said, development has to happen in feature/fix branches
that are merged into master *after* they're tested. In that sense the
master branch ought to be considered as an integration branch, not a
development branch.

Please revisit what I wrote here for more details:
https://github.com/BOINC/boinc/issues/1874

Best,
Oliver




smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

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 uses the "client_release/7/7.8" branch, not master.
Master is for new development.
This is explained here:
https://boinc.berkeley.edu/trac/wiki/AdminReleaseManagement

-- David
___
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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-19 Thread Oliver Bock
On 19.07.17 12:24, Oliver Bock wrote:
> Other than that I'm fully in line with your proposal as it reflects what
> I've already proposed here:
> 
> https://github.com/BOINC/boinc/issues/1874

Given the existence of that issue all further (related) discussion would
ideally be continued over there.

Thanks,
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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-19 Thread Oliver Bock
On 19/07/17 11:57 , Christian Beer wrote:
> - if there is consensus that the feature is useful to BOINC in general
> and known to be stable enough, the developer creates a pull request to
> merge the feature into the master branch
> - if the feature involves client changes, a new client version can be
> built based on cherry-picking commits from master into the client
> release branch

If the feature branch is autonomous (as it should be) then there's no
need to cherry-pick single commits from master to the client release
branch after merging the feature into master. Just merge the feature
branch into the client release branch as well. This way you don't risk
losing commit coherence.

Other than that I'm fully in line with your proposal as it reflects what
I've already proposed here:

https://github.com/BOINC/boinc/issues/1874

Cheers,
Oliver




smime.p7s
Description: S/MIME Cryptographic Signature
___
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.

Re: [boinc_dev] [boinc_projects] keywords

2017-07-19 Thread Christian Beer
It was pointed out to me that my criticism may not be specific enough. I
am not against this proposal in general but three days over a weekend is
not enough time to read and comment on a complex design proposal. I
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.
What I want to prevent is that a half implemented new feature (that's
still in the design phase of software development) finds it way into a
released version of BOINC.

With limited manpower available to BOINC development, it should be the
prime objective of all BOINC developers to keep the codebase stable for
the time being and not introduce new features into the master branch
before they are tested.

To also be constructive here is a process that would ensure the above
goal of stability of the master branch:
- a new feature is written down and send around for comments
- a new feature branch (based on master) is created that is used to
implement the feature as it is discussed
- experimental clients for testers can be built using this feature
branch, test projects can be spun up using this feature branch
- if there is consensus that the feature is useful to BOINC in general
and known to be stable enough, the developer creates a pull request to
merge the feature into the master branch
- if the feature involves client changes, a new client version can be
built based on cherry-picking commits from master into the client
release branch

This makes sure that the effects of the new feature are known in advance
and don't interfere with other bugfixing activity on the master branch.

Regards
Christian

On 17.07.2017 10:04, Christian Beer wrote:
> I just want to voice my disagreement with the process in which this
> proposal was handled. There was barely time to comment and so far no one
> did but implementation into the master branch has already started for
> what seems to be a major change to Client and Server code.
>
> As a volunteer contributor and committer to BOINC and as a BOINC PMC
> member this proposal and the process in which it is done does not have
> my approval.
>
> Regards
> Christian
>
> P.S.: Although this mail is sent from my AEI email the opinion expressed
> above is my personal one.
>
> On 14.07.2017 01:04, David Anderson wrote:
>> I propose adding a mechanism for associating keyword attributes
>> (such as science area) with jobs and projects.
>> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
>> Comments welcome.
>> -- David
>> ___
>> boinc_projects mailing list
>> boinc_proje...@ssl.berkeley.edu
>> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
>> 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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-17 Thread David Anderson

Richard:
Thanks for the comments.
In the current framework, keywords have "symbols" as well as integer IDs:
https://boinc.berkeley.edu/keywords.php?header=c
https://boinc.berkeley.edu/keywords.php?header=python
This makes it easy to specify them e.g. in job-submission programs.

I think it's better not to encode hierarchy into the symbols,
because we may want to change the hierarchy over time:
e.g. to move Cosmology from Astronomy to Physics,
or create new levels.

This doesn't preclude hierarchical search;
it would be based on the actual hierarchy as encoded, e.g., in
https://boinc.berkeley.edu/keywords.php
rather than on symbols.

-- David

On 7/17/2017 3:40 AM, Richard Haselgrove wrote:

That intervention has prompted me to look more closely at the 'Job and Project 
Keywords' design document.
It reminds me very much of a project I was involved in between 1990 and about 
2005. I was the sole coder on the team, but the philosophy and design were led 
by a project leader above me.
Our project was called 'FunderFinder', and was intended to help UK community 
groups raise funds from UK charitable trusts, some of which had trust deeds 
dating back to the seventeenth century - so the terminology was arcane, to say 
the least. Our matching had to be more precise, so we did develop a 'complete 
taxonomy of charity funding' (with the help of a cataloguing expert from the 
British Library), but in general terms our solution was very similar to yours.
I would identify two differences - the first trivial, the second perhaps 
significant.
We used a three-way classification: People, Subjects, Places - that enabled us 
to distinguish between, for example, medical research into cancer (a subject), 
and the care of patients with cancer (people).
More importantly, instead of your integer to represent a keyword, we used an 
alphanumeric code: to keep the structure clear in our own minds, we used lower 
case letters for people, upper case letters for subjects, and numerals for 
places.
I can't match your examples exactly, but we had
HMedicine and HealthHM  Diseases and disordersHMWTumours 
(including cancer)HMWC  CancerHMWL  LeukaemiaHMWM  Melanoma
and for the patients,
jdgwc  Cancer
We found that seven-character codes were sufficient to cover the worst case, 
from 2 (UK) / 5 (rest of the world) down to a single historic parish council 
via the modern local government administrative structure.
The advantage of using a hierarchical coding was that I could use sub-string 
pattern matching to include and exclude higher or lower level matches. That's 
probably overkill for the current proposal, but it seems to be a shame to 
design out the possibility of a hierarchical search at this stage.

 On Monday, 17 July 2017, 9:04, Christian Beer  
wrote:
  


  I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:

I propose adding a mechanism for associating keyword attributes
(such as science area) with jobs and projects.
https://boinc.berkeley.edu/trac/wiki/DesignKeywords
Comments welcome.
-- David
___
boinc_projects mailing list
boinc_proje...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
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.


Re: [boinc_dev] [boinc_projects] keywords

2017-07-17 Thread Richard Haselgrove
Details of the project I described are no longer available on the web, but they 
can be explored here:

https://web.archive.org/web/19961221214555/http://www.funderfinder.org.uk/
 

On Monday, 17 July 2017, 11:44, Richard Haselgrove 
 wrote:
 

 That intervention has prompted me to look more closely at the 'Job and Project 
Keywords' design document.
It reminds me very much of a project I was involved in between 1990 and about 
2005. I was the sole coder on the team, but the philosophy and design were led 
by a project leader above me.
Our project was called 'FunderFinder', and was intended to help UK community 
groups raise funds from UK charitable trusts, some of which had trust deeds 
dating back to the seventeenth century - so the terminology was arcane, to say 
the least. Our matching had to be more precise, so we did develop a 'complete 
taxonomy of charity funding' (with the help of a cataloguing expert from the 
British Library), but in general terms our solution was very similar to yours.
I would identify two differences - the first trivial, the second perhaps 
significant.
We used a three-way classification: People, Subjects, Places - that enabled us 
to distinguish between, for example, medical research into cancer (a subject), 
and the care of patients with cancer (people).
More importantly, instead of your integer to represent a keyword, we used an 
alphanumeric code: to keep the structure clear in our own minds, we used lower 
case letters for people, upper case letters for subjects, and numerals for 
places.
I can't match your examples exactly, but we had
H        Medicine and HealthHM      Diseases and disordersHMW    Tumours 
(including cancer)HMWC  CancerHMWL  LeukaemiaHMWM  Melanoma
and for the patients,
jdgwc  Cancer
We found that seven-character codes were sufficient to cover the worst case, 
from 2 (UK) / 5 (rest of the world) down to a single historic parish council 
via the modern local government administrative structure.
The advantage of using a hierarchical coding was that I could use sub-string 
pattern matching to include and exclude higher or lower level matches. That's 
probably overkill for the current proposal, but it seems to be a shame to 
design out the possibility of a hierarchical search at this stage. 

    On Monday, 17 July 2017, 9:04, Christian Beer  
wrote:
 

 I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:
> I propose adding a mechanism for associating keyword attributes
> (such as science area) with jobs and projects.
> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
> Comments welcome.
> -- David
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> 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_projects mailing list
boinc_proje...@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
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.

Re: [boinc_dev] [boinc_projects] keywords

2017-07-17 Thread Richard Haselgrove
That intervention has prompted me to look more closely at the 'Job and Project 
Keywords' design document.
It reminds me very much of a project I was involved in between 1990 and about 
2005. I was the sole coder on the team, but the philosophy and design were led 
by a project leader above me.
Our project was called 'FunderFinder', and was intended to help UK community 
groups raise funds from UK charitable trusts, some of which had trust deeds 
dating back to the seventeenth century - so the terminology was arcane, to say 
the least. Our matching had to be more precise, so we did develop a 'complete 
taxonomy of charity funding' (with the help of a cataloguing expert from the 
British Library), but in general terms our solution was very similar to yours.
I would identify two differences - the first trivial, the second perhaps 
significant.
We used a three-way classification: People, Subjects, Places - that enabled us 
to distinguish between, for example, medical research into cancer (a subject), 
and the care of patients with cancer (people).
More importantly, instead of your integer to represent a keyword, we used an 
alphanumeric code: to keep the structure clear in our own minds, we used lower 
case letters for people, upper case letters for subjects, and numerals for 
places.
I can't match your examples exactly, but we had
H        Medicine and HealthHM      Diseases and disordersHMW    Tumours 
(including cancer)HMWC  CancerHMWL  LeukaemiaHMWM  Melanoma
and for the patients,
jdgwc  Cancer
We found that seven-character codes were sufficient to cover the worst case, 
from 2 (UK) / 5 (rest of the world) down to a single historic parish council 
via the modern local government administrative structure.
The advantage of using a hierarchical coding was that I could use sub-string 
pattern matching to include and exclude higher or lower level matches. That's 
probably overkill for the current proposal, but it seems to be a shame to 
design out the possibility of a hierarchical search at this stage. 

On Monday, 17 July 2017, 9:04, Christian Beer  
wrote:
 

 I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:
> I propose adding a mechanism for associating keyword attributes
> (such as science area) with jobs and projects.
> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
> Comments welcome.
> -- David
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> 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.

Re: [boinc_dev] [boinc_projects] keywords

2017-07-17 Thread Christian Beer
I just want to voice my disagreement with the process in which this
proposal was handled. There was barely time to comment and so far no one
did but implementation into the master branch has already started for
what seems to be a major change to Client and Server code.

As a volunteer contributor and committer to BOINC and as a BOINC PMC
member this proposal and the process in which it is done does not have
my approval.

Regards
Christian

P.S.: Although this mail is sent from my AEI email the opinion expressed
above is my personal one.

On 14.07.2017 01:04, David Anderson wrote:
> I propose adding a mechanism for associating keyword attributes
> (such as science area) with jobs and projects.
> https://boinc.berkeley.edu/trac/wiki/DesignKeywords
> Comments welcome.
> -- David
> ___
> boinc_projects mailing list
> boinc_proje...@ssl.berkeley.edu
> https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_projects
> 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.