-
Notifications
You must be signed in to change notification settings - Fork 439
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add project #2716
Add project #2716
Conversation
I've checked the list against the comparison chart I attached to #2696, and all seems good - including the new project, DBN Upper Bound, which has not yet been publicly welcomed. I'm still a bit concerned that our usage of HTTPS is inconsistent. Now that the <web_url> tag is active, we could and perhaps should set the web_urls for these projects to https: https://www.rnaworld.de/rnaworld/ And, for completeness, these projects cannot yet use https to access their websites. Perhaps we could nudge them gently? http://quakecatcher.net/sensor Finally, I'm still not quite sure why the plain < url > tags for http://denis.usj.es/denisathome/ have been reverted to http this time. Both projects support using https in Fetching configuration file from https://denis.usj.es/denisathome/get_project_config.php which is the primary purpose of this commit. I'm aware of the command line problem raised by @ChristianBeer in #2642, but how many users use this file as the source for command line urls? The number of users still using Version 4 or earlier BOINCs is tiny, and the only other users I can think of being affected are a) self-ports to unsupported operating systems I think both classes could be expected to do their own research and apply the master url directly where needed? |
I think http://sat.isa.ru/pdsat/ has no work for 2 years already as far as I heard they have no plans to continue but I can be wrong. I can gently push guys of these projects on Russian boinc forum : |
For me the commit message is very non-descriptive and doesn't reflect what is in the code changes. I can already hear someones head banging on his desk in the future because he/she wants to know why the changes were made and "Add project" just doesn't do that. As for the changes related to Einstein@Home they are fine if the intention of is to represent the As for the general separation of and <web_url> I think that was needed because the file is used in multiple places where the distinction was needed. I can't remember the exact details. But the |
My understanding is that the source of the all projects list is this: https://github.com/BOINC/boinc-site/blob/master/projects.inc If we want to get things updated in the original source, then we need to submit a pull request against https://github.com/BOINC/boinc-site/blob/master/projects.inc with the needed changes. @davidpanderson - is this correct? I think that things like trying to persuade projects to use things like Let's Encrypt or otherwise move to https should be handled and discussed on tickets outside of this as that discussion confuses the action needed on this pull request. Issue #1345 that @RichardHaselgrove refers to is a great place to discuss that. @RichardHaselgrove - could you create a pull request against https://github.com/BOINC/boinc-site/blob/master/projects.inc that proposes what needs to be corrected based on how things are today (not how we wish they might be in the future). |
@TheAspens: My recollection is that https://github.com/BOINC/boinc-site/blob/master/projects.inc was cited as the definitive source during our working party deliberations, too. And that file was updated 11 days ago, so we should be close to equivalence. I'll try and work up a pull request tomorrow, in time for the committers' call on Thursday. The change of format (data to code) will slow things down, as will validating the other data sources (keywords via KeywordID, plan classes). I think I feel a database coming on... "What needs to be corrected [today]" would be based on a bias towards using https wherever supported, especially for <web_url> which is used for browser access only: my feeling is (as it was during my stint as release manager) that this presents a professional image for both BOINC and the projects in this age of the promotion of browser security. The join/master url debate still needs to be resolved through #2642, but I think @ChristianBeer's direction of travel there is to resolve the command line (boinccmd) attachment problem by implementing get_project_config there too. Which leaves Account Managers... |
Both the Mac and Windows installers get the all projects list from the release branch at the following path: I programmed the Mac installer so that it writes the all_projects_list.xml file to the BOINC Data directory ** only** if there is not already one there (in the case of installing over a previously installed BOINC.) This is because an exiting all_projects_list.xml file will usually be more recent, since the client checks the server every 14 days and downloads the file if the one on the server is newer than the local copy. However, I don't think the Windows installer has this logic. |
I have confirmed that the all_projects_list.xml file added to the 7.14 branch by commit 50e4ed8 is identical to all the following:
So I will go ahead and tag 7.14.1 and build a Mac installer. |
Thanks Charlie - that saves me a tough job (though I might still build that database at leisure to facilitate future tests). I'll still make the PR for updating web urls to https where viable, but let's not regard it as a blocker for v7.14 |
I have opened BOINC/boinc-site#3 for these changes. I find I don't currently have write access to the boinc-site repo, so these changes are derived from a personal fork. |
Why hasn't this been merged? |
No description provided.