search

BOINC / boinc

Open-source software for volunteer computing and grid computing.
https://boinc.berkeley.edu
GNU Lesser General Public License v3.0
1.99k stars 443 forks source link

gui_rpc_auth.cfg exists but can't be read. Check the file permissions. #4267

Closed endolith closed 1 month ago

endolith commented 3 years ago

Describe the bug BOINC Manager - Connection Error gui_rpc_auth.cfg exists but can't be read. Check the file permissions.

Steps To Reproduce

  1. Install Ubuntu
  2. Install BOINC
  3. Try to run BOINC Manager

Expected behavior I would expect it to work like it did on my previous install.

Screenshots BOINC error

System Information

Additional context BOINC Manager was working fine on this machine, but I reinstalled Ubuntu and on a fresh install it gives this error

AenBleidd commented 3 years ago

@endolith, please read this thread: https://boinc.berkeley.edu/dev/forum_thread.php?id=14013#101083

RichardHaselgrove commented 3 years ago

As a major contributor to that thread: oh no, not again.

This problem needs to be addressed at source.

endolith commented 3 years ago

@AenBleidd Which part of that thread should I be reading?

One person says to change permissions of a file.

One person says to add a password to the command line (but the file is empty so there is nothing to copy).

One says to do systemctl restart boinc-client which doesn't work.

One person says to add my username to boinc group.

Does everyone who installs BOINC have to read that thread and understand the inner workings of BOINC before using it?

AenBleidd commented 3 years ago

@endolith,

@AenBleidd Which part of that thread should I be reading?

The whole thread,

One person says to change permissions of a file. One person says to add a password to the command line (but the file is empty so there is nothing to copy). One says to do systemctl restart boinc-client which doesn't work. One person says to add my username to boinc group.

There are different cases when this issue can occur.

Does everyone who installs BOINC have to read that thread and understand the inner workings of BOINC before using it?

If you have such issue - it's always nice at first to try to search for existing question because it's a rare situation when you're the first who have an issue. I left you a link to a thread so you could be able to fix it on your side faster. Yes, there is such issue as @RichardHaselgrove already said. If you want - you can wait until it will be fixed somehow in the product or you can use existing suggestion from the people who solved it already and do it faster.

endolith commented 3 years ago

So which workaround is the correct one for Ubuntu 20.10?

RichardHaselgrove commented 3 years ago

For long-term, stable, continuous, use, I would recommend adding your username to the boinc user group, followed by a machine reboot.

For a quick'n'dirty hack, I add my password to the command line - that's easier to reverse for testing. In my Linux Mint distribution, BOINC Manager is automatically added to the program launch menu, from where a right-click copies it to the desktop. The desktop launcher can be edited with a right-click to display 'properties'.

endolith commented 3 years ago

I would recommend adding your username to the boinc user group

Ok, though that thread says

You could add authorised users to the boinc group as you suggested and then allow only those to read the password file. In fact that's what I do, but I'm sure that's still not how it was intended to work.

How did the BOINC developers intend for this to work? They expected that users would add themselves to boinc user group?

aravindvnair99 commented 3 years ago

So which workaround is the correct one for Ubuntu 20.10?

@endolith Were you able to resolve the issue? I am still facing the same problem.

RichardHaselgrove commented 3 years ago

How did the BOINC developers intend for this to work?

Warning - long and technical references follow.

The sequence of events that led up to this problem started with #3709: the intention is explicit, but the implementation and consequences are the subject of the first of those 'long and technical references'.

There is a second, revised, intention in #4071, but again implementation is subject to debate.

You might feel that implementation should have been considered as part of the original proposal, but I couldn't possibly comment.

aravindvnair99 commented 3 years ago

For long-term, stable, continuous, use, I would recommend adding your username to the boinc user group, followed by a machine reboot.

@RichardHaselgrove I tried doing that by sudo usermod -a -G boinc my_username_here and restarting, but it didn't work. Any suggestions?

TheAspens commented 3 years ago

There are three goals here:

  1. Automatically start the BOINC core client when Linux starts
  2. Run securely by default
  3. Allow a user to launch the BOINC manager under their account and connect to the BOINC core client started in via item 1

Due to the way apt and yum install software, I am not aware of any approach nor have I seen anyone make a proposal to make all three of the above work. The arguments have come down to whether we should favor 3 over 2.

At this time*, the BOINC installation does 1 and 2. In order to accomplish #3 you have to add your user account to the boinc group and possible change the permissions on the gui_rpc_auth.cfg file. World Community Grid's installation instructions for BOINC have documented these in our installation steps for many years (at least since 2014). See https://www.worldcommunitygrid.org/ms/viewDownloadAgain.action (and then select Debian or CentOs).

Here is WCG's full installation instructions for Ubunut/Debian. Some of these steps may not be required at this point in time but the exact installation configuration has changed over time, and these instructions make sure that everything gets set correctly.

1. In a terminal window, run the following command:

sudo apt install boinc-client boinc-manager

2. Set the BOINC client to automatically start after you restart your computer:

sudo systemctl enable boinc-client

3. Start the BOINC client:

sudo systemctl start boinc-client

4. Allow group access to client access file:

sudo chmod g+r /var/lib/boinc-client/gui_rpc_auth.cfg

5. Add your Linux user to the BOINC group to allow the BOINC Manager to communicate with the BOINC client

sudo usermod -a -G boinc $USER

6. Allow your terminal to pick up the privileges of the new group:

exec su $USER

7. In the same terminal window, start the BOINC Manager:

boincmgr -d /var/lib/boinc-client

8. When BOINC Manager opens, select World Community Grid from the list of BOINC projects then enter your World Community Grid username and password.

9. When these steps are completed, you should see a screen to confirm that you've been successfully signed up to World Community Grid.
RichardHaselgrove commented 3 years ago

Actions 1, 2, 3, 5 seem right to me. I've never needed action 4. Action 6 replaces my reboot - thanks for the tip. Linux Mint's desktop icon obviates the need for 7. 8 and 9 are project-specific.

We may need to revisit the list after #4171

endolith commented 3 years ago

So at the very least, the error message should link to those 9 7 instructions

Even better, the instructions should be included in the error message, so it's always up to date with the package

Even betterer, the postinstall script should do all this for you, prompting you for which users you want to add to the boinc group, etc.

aravindvnair99 commented 3 years ago

@TheAspens I just tried what you said at https://github.com/BOINC/boinc/issues/4267#issuecomment-801932059 and I get this:

image

Whereas normally opening via search, gives this:

image

I am on Ubuntu 20.10 with all the latest updates. I have tried reinstalling multiple times.

username@host:~$ ls -l /etc/boinc-client/gui_rpc_auth.cfg
-rw-r----- 1 root boinc 1 Aug 27  2020 /etc/boinc-client/gui_rpc_auth.cfg

username@host:~$ stat -c "%a %n" /etc/boinc-client/gui_rpc_auth.cfg
640 /etc/boinc-client/gui_rpc_auth.cfg

Anything I could do to solve the issue?

TheAspens commented 3 years ago

Even betterer, the postinstall script should do all this for you, prompting you for which users you want to add to the boinc group, etc.

As I understand it, apt and yum should not be prompting the user for questions during installation. Although some packages do this, it can create a lot of problems in a lot of patch and maintenance scenarios and as a result, it is not a standard practice. It is this that makes it so hard to implement the installation scenarios to make doing all three easy.

TheAspens commented 3 years ago

@aravindvnair99 - that is interesting. It suggests one of two things. Either A) the boinc core client wasn't started by systemd or B) you have a copy of gui_rpc_auth.cfg in your home directory.

Can you run sudo systemctl stop boinc-client and then ps -ef | grep boinc and see if the boinc core client is still running? If it is run sudo pkill boinc. Once the boinc core client is stopped, then you can restarted it with sudo systemctl start boinc-client.

Also check in your home directory for a copy of gui_rpc_auth.cfg and if found rename it to something like gui_rpc_auth.cfg.tmp or just remove it.

Now open a new terminal window and run boincmgr -d /var/lib/boinc-client and see if it connects.

Note that you might need to reboot (maybe just logout and login in again) in order to get your GUI session to gain access to the boinc group that you added to your profile.

Please let us what you find on each step and what happens. Thanks.

aravindvnair99 commented 3 years ago

@TheAspens Thank you for your response! I came across one of your replies (https://github.com/BOINC/boinc/pull/3709#issuecomment-631513053) which seems to have fixed the issue for me. I'm now able to normally able to open it through my GUI. I had just performed those steps and restarted.

As for your latest message (https://github.com/BOINC/boinc/issues/4267#issuecomment-802218267), I don't have a gui_rpc_auth.cfg in my home directory. Let me know if you want me to run some tests and I will be glad to help.

Thanks for your time and response once again! :)

TheAspens commented 3 years ago

@aravindvnair99 - thanks for the update and confirming that your issue is resolved.

Notes to someone in the future who has a similar problem and reads this. The changes that likely resolved this issue are the following. Please try these and then respond to this thread with the outcome (since this will confirm our understanding of the problem).

Open a terminal window and run the following commands:

sudo chmod 755 /etc/boinc-client
sudo chmod 644 /etc/boinc-client/config.properties
sudo chown -R boinc:boinc /etc/boinc-client

sudo chmod 750 /var/lib/boinc-client
sudo chmod 640 /var/lib/boinc-client/gui_rpc_auth.cfg
sudo chown boinc:boinc /var/lib/boinc-client
sudo chown boinc:boinc /var/lib/boinc-client/gui_rpc_auth.cfg

sudo usermod -a -G boinc $USER

and then reboot.

Lastly - please respond with the outcome of you trying this. Thank you.

Vulpine05 commented 3 years ago

I've been casually reading this thread, and I believe I have the same "exists but can't be read" error. I have two laptops running Ubuntu 18.04 with BOINC 7.16.16. When I have the time to re-read this thread thoroughly, I'll be sure to give this a shot and report back.

I am only slightly familiar with Linux, so I thank you in advance for what appears to be very detailed, thorough instructions.

endolith commented 3 years ago

@TheAspens

Before (fresh install on Ubuntu):

~> ls -l /etc/boinc-client
total 16
-rw-rw-r-- 1 boinc boinc 356 Aug 27  2020 cc_config.xml
-rw-rw-r-- 1 root  boinc 298 Aug 27  2020 global_prefs_override.xml
-rw-r----- 1 root  boinc   1 Aug 27  2020 gui_rpc_auth.cfg
-rw-r--r-- 1 root  boinc 296 Aug 27  2020 remote_hosts.cfg

~> ls -l /var/lib/boinc-client/
total 92
-rw-r--r-- 1 boinc boinc 53526 Mar 14 22:13 all_projects_list.xml
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx 1 root  root     31 Feb 26 17:49 cc_config.xml -> /etc/boinc-client/cc_config.xml
-rw-r--r-- 1 boinc boinc  5892 Mar 17 22:41 client_state_prev.xml
-rw-r--r-- 1 boinc boinc  5892 Mar 17 22:41 client_state.xml
-rw-r--r-- 1 boinc boinc  2979 Mar 17 22:41 coproc_info.xml
-rw-r--r-- 1 boinc boinc   195 Mar 17 22:40 daily_xfer_history.xml
lrwxrwxrwx 1 root  root     43 Feb 26 17:49 global_prefs_override.xml -> /etc/boinc-client/global_prefs_override.xml
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 gui_rpc_auth.cfg -> /etc/boinc-client/gui_rpc_auth.cfg
-rw-r--r-- 1 boinc boinc     0 Mar 17 22:41 lockfile
drwxrwx--x 2 boinc boinc  4096 Feb 26 17:49 notices/
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 remote_hosts.cfg -> /etc/boinc-client/remote_hosts.cfg
drwxr-xr-x 2 boinc boinc  4096 Feb 26 17:49 slots/
-rw-r--r-- 1 boinc boinc     0 Feb 26 17:49 stderrgpudetect.txt
-rw-r--r-- 1 boinc boinc     0 Feb 26 17:49 stdoutgpudetect.txt
-rw-r--r-- 1 boinc boinc  2815 Mar 17 22:41 time_stats_log

During:

chmod: cannot access '/etc/boinc-client/config.properties': No such file or directory

After:

~> ls -l /etc/boinc-client
total 16
-rw-rw-r-- 1 boinc boinc 356 Aug 27  2020 cc_config.xml
-rw-rw-r-- 1 boinc boinc 298 Aug 27  2020 global_prefs_override.xml
-rw-r----- 1 boinc boinc   1 Aug 27  2020 gui_rpc_auth.cfg
-rw-r--r-- 1 boinc boinc 296 Aug 27  2020 remote_hosts.cfg

ls: cannot open directory '/var/lib/boinc-client/': Permission denied

~> sudo ls -l /var/lib/boinc-client/
total 92
-rw-r--r-- 1 boinc boinc 53526 Mar 14 22:13 all_projects_list.xml
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 ca-bundle.crt -> /etc/ssl/certs/ca-certificates.crt
lrwxrwxrwx 1 root  root     31 Feb 26 17:49 cc_config.xml -> /etc/boinc-client/cc_config.xml
-rw-r--r-- 1 boinc boinc  5892 Mar 17 22:41 client_state_prev.xml
-rw-r--r-- 1 boinc boinc  5892 Mar 17 22:41 client_state.xml
-rw-r--r-- 1 boinc boinc  2979 Mar 17 22:41 coproc_info.xml
-rw-r--r-- 1 boinc boinc   195 Mar 17 22:40 daily_xfer_history.xml
lrwxrwxrwx 1 root  root     43 Feb 26 17:49 global_prefs_override.xml -> /etc/boinc-client/global_prefs_override.xml
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 gui_rpc_auth.cfg -> /etc/boinc-client/gui_rpc_auth.cfg
-rw-r--r-- 1 boinc boinc     0 Mar 17 22:41 lockfile
drwxrwx--x 2 boinc boinc  4096 Feb 26 17:49 notices
lrwxrwxrwx 1 root  root     34 Feb 26 17:49 remote_hosts.cfg -> /etc/boinc-client/remote_hosts.cfg
drwxr-xr-x 2 boinc boinc  4096 Feb 26 17:49 slots
-rw-r--r-- 1 boinc boinc     0 Feb 26 17:49 stderrgpudetect.txt
-rw-r--r-- 1 boinc boinc     0 Feb 26 17:49 stdoutgpudetect.txt
-rw-r--r-- 1 boinc boinc  2815 Mar 17 22:41 time_stats_log

After reboot, it works.

RichardHaselgrove commented 3 years ago

@TheAspens 

6. Allow your terminal to pick up the privileges of the new group:
exec su $USER

This only starts a temporary terminal session which allows for command-line testing within that session. It doesn't affect the primary graphical desktop session, for us Windows refugees who use such a thing.

RichardHaselgrove commented 3 years ago

I was using it to test I had successfully removed myself from the boinc group. I had: I got

Screenshot at 2021-03-19 10-16-30

I didn't know https://boinc.berkeley.edu/gui_rpc.php existed. Unfortunately, the link isn't clickable, and the dialog is modal and the text can't be selected and copied, which makes it less useful in this graphical world.

Vulpine05 commented 3 years ago

Lastly - please respond with the outcome of you trying this. Thank you.

I set up a new computer with Ubuntu 18.04, and was able to run BOINC (version 7.16.16) with no problems. The other week when running Software Updates, there was an update for BOINC to 7.16.17. After completing the update, I got the 'exists but can't be read' error message. @TheAspens , I went through your steps from your post on 3/18, rebooted, and BOINC is running fine again. Thank you!

Besides confirming the manual fix works, I was surprised to see that this error popped up after updating from a recent install. Was that expected?

AenBleidd commented 3 years ago

@Vulpine05, 7.16.17 is a beta version for OSX only.

RichardHaselgrove commented 3 years ago

7.16.17 is a beta version for OSX only.

It may have been built and released at this moment because of a pressing need for OS X, but it'll have been built from the shared master codebase that underpins all versions. I, too, got a v7.16.17 update for Linux, because of @LocutusOfBorg's automated PPA build. If something unexpected appears in that, then it's in the codebase and will re-appear in future targeted releases. It shouldn't be dismissed.

AenBleidd commented 3 years ago

7.16.17 is based on the way more older commit that 7.16.16 and does not include a lot of changes that were done in 7.16.16. That's why 7.16.17 might have issues that were already saved in 7.16.16

RichardHaselgrove commented 3 years ago

Well, that's completely head-over-heels or cart-before-horse, according to the development plans we worked on three years ago. If there are worthwhile improvements in the code logic in v7.16.16 - as opposed to the build tweaks necessary for VS2019 - they should be back-ported to master as a matter of urgency.

AenBleidd commented 3 years ago

7.16.16 based on master. But 7.16.17 based an more earlier version of 7.16.* branch

CharlieFenton commented 3 years ago

This is more complicated than that. The client_release/7/7.16 branch was badly polluted multiple times by people merging the entire master branch into it. Because it contains an immense amount of untested code, that would require a full alpha test cycle.

Merging GIT master into the release branch was a direct, major violation of the client release policy at https://github.com/BOINC/boinc-policy/blob/master/Development_Documents/Client_Release_Process.md which says very explicitly:

The release branch is feature frozen. This means that no new features should be added to the release once the release branch is created. Additionally, only important bug fixes should be merged into the release branch.

and:

All code merged into the release branch will be a cherry-pick based on a merge commit.

This is extremely important. It maintains a clean code base the can be used to release critical and time-sensitive bug fixes without requiring a lengthy testing and debugging cycle.

Merging master into the client_release/7/7.16 release branch has rendered that branch completely useless and invalid by effectively making it equivalent to GIT master. By definition, any releases made from GIT master (and by extension now from the damaged 7.16 branch) should be version number 7.17.x during development builds and 7.18.x for release candidates. There should be a new release branch client_release/7/7.18 created from master rather than merging master into the client_release/7/7.16 branch.

Because my releases 7.16.14 and 7.16.17 were incremental releases for MacOS only to fix building with Xcode 12, to fix BOINC bugs introduced by Mac OS 11 Big Sur, and to address the requirements of the new Apple Silicon (arm64) Macs, I created a semi-private release branch off the 7.16 branch from before GIT master had been merged into the 7.16 branch. I named this branch client_release/7.16/7.16.12_branch to distinguish it from the client_release/7.16/7.16.12 tag. I carefully cherry-picked only the most critical bug fixes for the 7.16.x series relevant to MacOS. I did not cherry-pick any new MacOS fixes into the client_release/7/7.16 branch since I no longer use it for new Mac builds.

BOINC releases 7.16.14 and 7.16.17 were critical and urgent fixes for BOINC on MacOS, so it was necessary and appropriate to release them as minimal changes to earlier 7.16.x series builds. This allowed a short testing cycle. Including the enormous number of changes merged into the client_release/7/7.16 branch from master would have necessitated an extensive testing cycle and probably a series of releases to fix new bugs introduced by those extensive changes.

I avoided using version numbers 7.16.15 and 7.16.16 because those numbers had been used by builds from the client_release/7/7.16 branch for other platforms. (I seem to recall that a Linux build was released as one of those numbers due to a typo or similar mistake.)

Any Linux release with version number 7.16.17 implies that it was built from the same source code as the Mac 7.16.17 release; in other words, from the client_release/7.16/7/16.12_branch. But I don't know if that branch has all fixes needed for Linux in the 7.16 series.

But if a Linux 7.16.17 was built from the client_release/7/7.16 branch, that is a problem because we then have clients on two platforms with the same version number built from very different code bases.

Unless there are critical, urgent bugs with current releases on Linux, Windows or Android, please create a client_release/7/7.18 branch and make new releases from that, using version numbers 7.17.x for development builds and 7.18.x for release candidates.

CharlieFenton commented 3 years ago

7.16.16 based on master. But 7.16.17 based an more earlier version of 7.16.* branch

And that is completely opposite to the way it should be done. There is no point to having a separate release branch if it is based on master. Master is the development branch. By merging master into the release branch you have turned the release branch into a development branch.

CharlieFenton commented 3 years ago

By the way, I understand that the way BOINC development uses GIT is different from what many people consider the "standard" way, which is why the Client Release Process document states it so explicitly. For better or worse, this is the development process that has evolved within the BOINC community over many years. It would create (even more) chaos to change it now.

AenBleidd commented 3 years ago

I think, this development process should be revisited, and I would like to initiate this process. Personally I like the idea of stable and releasable master: it's way more easier and important to test every feature implementation and bug fix than handle hundreds of cherry-picks. @TheAspens,may we do this? @davidpanderson, I want to release Android soon. Maybe it's also a good time to release new Desktop version too (with BOINC for Windows built with VS2019) with major version 7.18.0?

RichardHaselgrove commented 3 years ago

7.16.16 based on master. But 7.16.17 based an more earlier version of 7.16.* branch

That's not my recollection. v7.16.16 appeared - mysteriously, out of sequence, and without comment at 2020-10-27 19:45. I remember commenting on it at the time, and somebody - I think it was @AenBleidd - explained that it was only a test build for the VS2019 development platform, and that it was based on the then-current version of the v7.16.x release branch. Crucially, not on master.

AenBleidd commented 3 years ago

Initially 7.16.16 was created by mistake. But afterwards it was reused by me for Android release. And the current 7.16.16 tag is definitely based on master

RichardHaselgrove commented 3 years ago

I think, this development process should be revisited, and I would like to initiate this process. Personally I like the idea of stable and releasable master: it's way more easier and important to test every feature implementation and bug fix than handle hundreds of cherry-picks. @TheAspens,may we do this? @davidpanderson, I want to release Android soon. Maybe it's also a good time to release new Desktop version too (with BOINC for Windows built with VS2019) with major version 7.18.0?

I'd agree with all of those, subject to certain provisos.

AenBleidd commented 3 years ago

All patches in 7.16.* branch should be backporter to master

RichardHaselgrove commented 3 years ago

That's going to be difficult. Currently, the v7.16 release branch is 66 commits ahead of master, Some of them (updating version numbers, for instance) will be appropriate for the release process.

But others may be orphaned. Until and unless we can be sure that all cases have been backported, rather than 'should be', doubt remains. Does anyone know GitHub (or Git) well enough to extract those 66 commits into a single list? I don't mind helping to go through such a list, but I balk at comparing all 34,000 side-by-side on screen, as I'm doing now.

AenBleidd commented 3 years ago

@RichardHaselgrove,

git log master..client_release/7/7.16 --no-merges

RichardHaselgrove commented 3 years ago

Ta. git log origin/master..origin/client_release/7/7.16 --no-merges worked better in the end, but yours got me started.

Here's the resulting file: diffs_master_rel-7-16.txt

AenBleidd commented 3 years ago

@RichardHaselgrove, if you have these branches locally up-to-date - there should be no differences :)

RichardHaselgrove commented 3 years ago

'Should be' again - indeed! But git log found 46 of them...

RichardHaselgrove commented 3 years ago

OK, I've looked through all 46, and the bug-fixes which were written into the release branch do all appear to have been back-ported into master. But I'm still nervous, and I'd recommend a double-check.

CharlieFenton commented 3 years ago

All patches in 7.16.* branch should be backporter to master

I can only speak for the client_release/7.16/7.16.12_branch and anything I have done previously to the client_release/7/7.16 branch. Everything I have done in those branches was done according to the Client Release Process document. I cherry-picked it from a prior merge of a feature branch into master. The only exceptions were updating the version number and tagging each release. This can't be done in master because under the current official Client Release Process, the release branch must have lower version numbers (7.16.x) than the development master branch (7.17.x).

If everyone followed the official Client Release Process, everything in the client_release/7/7.16 branch would have been cherry-picked from master, so there should never be a reason to "back port" to master.

AenBleidd commented 3 years ago

I took a look at the list of commits and found no one that was done directly in 7.16.* branch without the corresponding commit in master. Everytime cherry-pick from master is not the case, because we have 4 platforms, and like 3 independent released:

CharlieFenton commented 3 years ago

I don't understand how we can achieve a "stable and releasable" master. When one creates a Pull Request from a new feature branch, GitHub automatically sets it up to be merged into master once the author of the PR declares it ready. At that point, only minimal testing has been done, usually by only one or two people. New feature branches are being merged into master constantly. So there is no way to "freeze" master after we built a release candidate from it for alpha testing.

During alpha testing, bugs often are discovered, so fixes need to be added to the frozen release branch. If we are releasing from master, there is no way to do this because many more changes have since been merged from newer feature branches that have nothing to do with fixing the bugs identified during alpha testing. You would be trying to hit a moving target, or to use a U.S. Football metaphor, you would be constantly moving the goal posts.

That is why the current Client Release Process makes sense to me. There is just no way for master to ever be stable or releasable. Please explain how this would work if I am missing something.

I recommend transferring the comments of the last few days to a new GitHub Issue. This discussion no longer has anything to do with gui_rpc_auth.cfg.

AenBleidd commented 3 years ago

When one creates a Pull Request from a new feature branch, GitHub automatically sets it up to be merged into master once the author of the PR declares it ready.

Usually changes we do are quite minor, so the testing of one or two people is definitely enough.

There is no way to "freeze" master after we built a release candidate from it for alpha testing.

And this is not needed. You do development, you merge everything to master. Wants to make an alpha release? Great. Merge master to release branch, built application on top of it and release for alpha. If something is found during this stage - you create a PR with fix, merge it to master and do cherry-pick to release branch. Once stable - do release. Then repeat. The main idea is to do merge from master before every new release. For example, for the next Android release I have 54 PRs merged. And it's a hell work to do cherry-pick of every PR (in correct order!) and not miss any of them, because there is nothing worse than having everything work on master and not on release.

I recommend transferring the comments of the last few days to a new GitHub Issue. This discussion no longer has anything to do with gui_rpc_auth.cfg.

Agree. Maybe boinc_dev mailing list is better for this?

AenBleidd commented 3 years ago

This is an explanation of what I suggest but with two changes:

image

CharlieFenton commented 3 years ago

@AenBleidd I believe what you describe is the current official Client Release Process. But you don't "Merge master to release branch." You copy or clone master to create a release branch. After that, everything is cherry-picked into that release branch.

I think the difference in our understanding here is what we mean by "new release". Each release has three number: like 7.16.35. 7 is the major release number. 16 is the minor release number. 35 is the revision number. A new release changes the minor release number and occasionally the major number. For those, you create a new feature branch.

A new revision includes only bug fixes to that major and minor release version. For a new revision, you cherry-pick only bug fixes from master into the release branch from master.

Do you agree?

CharlieFenton commented 3 years ago

What you illustration calls "hot fix" I have been calling "bug fix." But it shows feature branches being merged into a "develop" branch. How do we get GitHub to by default create Pull Requests to merge into the develop branch instead of into master?

CharlieFenton commented 3 years ago

Note in your diagram that nothing is ever merged (or even cherry-picked) from master into a release branch.