You simply have to explain clearly what improvements you have made, and provide the actual code you have written in a form which can be tested automatically for compatibility.

Would you ever like to take another look at published contributions?

• I hope that the acceptance can be prepared for further changes.
  
• Will any extensions become relevant for more desirable software system comparisons?
  

Would you ever like to take another look at published contributions?

If you have ever posted a link to your own published contributions, showing how they would fit into the BOINC environment, I've missed it. Please re-post.

If you have ever posted a link to your own published contributions, showing how they would fit into the BOINC environment, I've missed it.

Did anything hinder you to take known information sources better into account?

• Trac
  
• GitHub
  
• Forum
  

Can software design options be clarified also without concrete source code?

In one of your earlier posts you stated:

I occasionally adjusted some implementation details.

This indicates that you have a possible modification that may be of use to the whole community.
In the same post you stated:

It is just challenging to integrate further development ideas so that more users can benefit also from corresponding software evolution.

Yes, it can be a challenge to integrate a "small" change in the source code into the whole project. There are two ways to get the modification integrated into the project. First is the "private" approach, you work out how to compile and link the whole body of source code into a working programme, this can be very time consuming, and may be testable across a range of hardware etc. The second is to submit the modified module (as source code) to the project for formal incorporation into a test build and then be subject to a bank of test to confirm that everything works as it should, having both the "improved" functionality and no degradation in other required functions.

This indicates that you have a possible modification that may be of use to the whole community.

How much do you understand the adjustment ideas (so far) which were presented for several software components?

Yes, it can be a challenge to integrate a "small" change in the source code into the whole project.

Change reluctance can generally hinder desirable progress.

The second is to submit the modified module (as source code) to the project for formal incorporation into a test build and then be subject to a bank of test to confirm that everything works as it should, having both the "improved" functionality and no degradation in other required functions.

Do you find the currently used software test infrastructure sufficient for advanced comparisons of run time characteristics according to design alternatives?

My understanding of the changes you propose is sufficient to see what you are talking about, and see that there several possible ways to resolve and implement them. But I don't want to as they don't affect how BOINC works for the average user.
As yet you have only described the changes you want to see, you have singularly failed to present your modifications to the source code, incorporated into the source code module it resides in.

As was explained to you in (at least) one of the discussion the reason behind the reluctance for the development team spending time on these "none essential" changes - the lack of developer resources. The BOINC development team are all volunteers, and as far as I know most have full-time jobs, so little time available for working on BOINC. Now if you want to have a "none essential" change implemented the way forward is to submit it for testing.

Finally for now, the performance of BOINC is not only about speed of execution which is, in the main "fit for purpose". But also the actual functionality and compliance with the API. Thus testing with some of the advanced performance tools as you suggest is not really required.

As yet you have only described the changes you want to see, you have singularly failed to present your modifications to the source code, incorporated into the source code module it resides in.

Would any contributors become interested to measure software run time differences for a change overview like the following (for the conversion of some local variables in member functions to a member variable of the corresponding class)?

 gui_rpc_client.cpp     |   46 +++++++++++++++++++++++++++++++++----
 gui_rpc_client.h       |   27 ++++++++++++----------
 gui_rpc_client_ops.cpp |   60 +------------------------------------------------
 3 files changed, 58 insertions(+), 75 deletions(-)

Thus testing with some of the advanced performance tools as you suggest is not really required.

Which data representations would you find more appropriate so that you would become convinced for proposed adjustments?

Now get those three files submitted to the development team with a carefully worded request for them to test when they get a chance - it's no good having them sitting on your computer.
I don't know the configuration of their test bench, Richard may (indeed he may be part of the test team associated with the development team).
Do not forget they will be interested in there being no degradation in compliance with the API, and the "user experience". Any deviation in either of these will be considered to be a "test failure", and may result in the mods being thrown out, or a request to resolve the identified issues. Testing can be a very unpleasant experience for the unwary

Now get those three files submitted to the development team with a carefully worded request for them to test when they get a chance - it's no good having them sitting on your computer.

Would you like to help another bit so that a communication blockage (which was activated by Vitalii Koshura on 2023-09-30) will be reconsidered?

Do not forget they will be interested in there being no degradation in compliance with the API, and the "user experience".

Some of my proposed code adjustments are just ordinary software refactorings.

A few changes would affect source files which are stored in the development directory “lib”.
Thus I imagine that further collateral evolution can be considered also according to involved software library components.

The first test is automated, and simply checks that the code is syntactically correct and compiles cleanly on all four supported platforms. It runs immediately after the code changes are uploaded in the required format (GitHub Pull Request). This is a change from when Markus was last active on the BOINC project, 8-12 years ago.

Functional testing of the compiled binaries is delayed until the "release candidate" stage, though this is still called 'Alpha testing'. That is when the completed packages, complete with installation tools where appropriate, are tested for functionality.

I personally feel that this is wrong: that functional, assembled package, testing should be called 'Beta testing', and there should be an alpha test phase of each PR - after submission, but before packaging - to ensure that proposed changes are compatible with project servers old and new. That can be done already, because the automated syntax and other code checks run right through to producing a compiled binary, which anyone interested can download and run.

But that probably won't help Markus. The automated builds are compiled in 'debug' mode, with the hooks to invoke the associated symbol tables for debugging. This means that their efficiency will not be a guaranteed guide to the efficiency of the final 'release' builds. But that is not considered to be a significant problem for BOINC itself: BOINC is an information and management tool, and puts vastly less stress on the volunteers' computers the the projects' "scientific research" applications. They are where efficiency considerations become important.

The automated builds are compiled in 'debug' mode, with the hooks to invoke the associated symbol tables for debugging. This means that their efficiency will not be a guaranteed guide to the efficiency of the final 'release' builds.

Thanks for such a constructive feedback.

But that is not considered to be a significant problem for BOINC itself: BOINC is an information and management tool,

I would appreciate if known programs can become also more powerful and efficient.

• boinccmd
  
• BOINC Manager
  

and puts vastly less stress on the volunteers' computers the the projects' "scientific research" applications.

I am unsure how much items can be influenced in related software areas.

They are where efficiency considerations become important.

I hope that further improvements can be achieved for involved tools.

I would appreciate if known programs can become also more powerful and efficient.
boinccmd
BOINC Manager
and puts vastly less stress on the volunteers' computers the the projects' "scientific research" applications.

It has already been said in this thread that the manager puts a negligible load on CPU compared to the science applications from the project. For instance, the eight tasks I currently have running are always using between 99.7 and 100% of a core as shown by top in a terminal. The manager does not even appear when I expand the window to full screen, it uses so little. boinccmd uses even less and nothing apart from when it is executed to give commands to the client.

With regards to making the manager more powerful, what extra functionality would you like to see? Being able to suspend individual uploads is something I would like.

I am unsure how much items can be influenced in related software areas.

Each project is responsible for its own applications, and they are the place where the biggest improvements in performance can be gained or lost.
As Dave & Richard have said, the BOINC client and manager use very little resource -currently running a CPDN task the BOINC client is using 7.2 MB and the manager 7.9 MB, and neither is reporting any CPU use to speak of. This compares with the CPDN task using 270MB, and about 1.5 cpu cores (and will hopefully run for another 6 days).

The basic function of BOINC is to provide a set of interfaces between the application, the user, and the project's servers and NOT do any of the computation for the project. So for a typical task this will mean calling for work from the project(s), scheduling the running of the tasks, then returning the results to the project servers. On top of this is the "heartbeat" activity of collecting and displaying the progress of tasks, how often this happens, depends on the application being run - again this is a trivial amount of work, reflected by the very low reported CPU use (below the threshold of the Windows 10 task manager).

So where do you think there is any substantial improvement in the BOINC manager and client that will improve the user experience and not impinge on the basic functions - while the old SETI screen saver was fun to watch it could be a drain on the resources on a low computing power device and so caused problems for the task scheduler.

So where do you think there is any substantial improvement in the BOINC manager and client

Will the development attention and resources grow also for these programs?

that will improve the user experience and not impinge on the basic functions - …

A source code review can easily point implementation details out for further considerations.
They affect software quality concerns which were described also in issue tracking systems to some degree.

It is very hard to predict the effects of this current debate on the recruitment of additional resources. Even one more person joining the team would be a large improvement in team size.

A source code review? This might satisfy the purist, but in terms of practical impact? Consider the fact that much of the code structure is about 2 decades old, and even if to then contemporary standards it would probably fall below today's. Once the code review has been completed, who is going to perform the re-write that such a review will inevitably require? But will a review actually have a positive impact on the users' perception?

Go ahead, and do the code review, perform the re-write that will be required, but don't expect anyone to notice any positive improvement. How long will tat whole process take? Certainly more than a few days, maybe a year by the time the testing has been undertaken. In my opinion it can often be a waste of time doing this type of activity on "heritage" software that is basically "functioning as required".

In the meantime the core functionality may have features added, and you will have to introduce those into your scope of work.

It is also worth bearing in mind that making the manager more powerful and letting it do things that currently can only be managed by editing XML files could very quickly lead to end users seriously messing up their BOINC configuration. Advice on modifying these files is on these fora often accompanied by warnings to make backups etc. Of course there is always going to be a debate between those who would like to be able to play with everything easily and those who don't want the fora overrun with people who have messed up.

Markus is enjoying a quiet two week vacation at a place where he can question everything repeatedly , ignoring all the answers, alone.