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.
