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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
