Please read
in particular the definition of "stable".

I think you're laboring under a misapprehension.
Testing a feature in isolation is not the same as testing the system.
No one is advocating committing untested or buggy code into master.
However, feature testing doesn't mean that master is stable.
For that, we need to do system-level testing in a separate release branch.

This is what we've done for years with the client software.
It works well and is efficient.
We should use the same approach for server software.

-- David

On 8/6/2017 12:15 PM, Bernd Machenschalk wrote:
On 04.08.17 23:17, David Anderson wrote:

On 7/21/2017 5:47 AM, Bernd Machenschalk wrote:

This might be one of the fundamental (pun intended) misunderstandings here. It is the opposite of everything I ever heard or read, and I think I know why:

How can one (expect to) fork a 'stable' branch from an 'unstable' one? How can one grow a tree (of branches) from an unstable foundation and expect it to be stable?
It's simple:

1) fork master, e.g. to client_release_xxx.  It's not stable at this point.
2) test client_release_xxx (e.g. using Alpha testers) fix bugs, repeat. Now it's stable.
3) only backport bug fixes to client_release_xxx.  It remains stable.

This is like stabilizing a tree with an unstable trunk by supporting every branch with numerous tree props. The problem with that is not that it's impossible; it's just highly inefficient.

In the early times of CVS, where branching was a pain and merging was impossible, this once was the only feasible (yet not optimal) model. However already at that time there were people thinking of ways to stabilize the trunk, i.e. by introducing tests that should be ran locally (and pass) before committing anything into trunk.

There is one big lesson that has been learned from various small and large (software) projects: the later a problem is discovered, the more work is required to fix it. Thus a major effort in software engineering is to develop methods and tools to discover errors as early as possible. This is not for academic discussion, it is there to save everyone who develops software as much work as possible (The best work is one that you don't have to do at all). Examples of what we arrived at can be seen at github: Static code analysis and continuous integration (or continuous testing), integrated with flexible source code management systems. All of this is there to work for you so you don't have to do that work yourself.

If the trunk is completely unstable, problems pile up and even start to interact there. Disentangling these to later stabilize a branch might be difficult up to impossible, and it's certainly work that can be saved by testing each feature/development.commit separately, and only commit/push/merge it back to trunk if it works by itself.

The model of a completely unstable single development trunk may work for a small group of closely connected developers. It fails badly if there are multiple developers working on different features in parallel. One will always feel that the own development is ruined by the commits of someone else. Avoiding that requires a level of coordination that would be difficult to achieve among multiple developers spread over different timezones; at least it would slow down the actual development quite significantly.

Consequently I know of no (other) software project that still sticks to that model, in particular not in the distributed Open Source community. I may be wrong, though, corrections are welcome.

We've always used this approach for the client, and it's worked perfectly.
We can use the same approach for server if we create
a distributed testing system based on Beta projects (analogous to the client Alpha test)

The server is much more complex than the client, with all its components (that are project-specific to a large part) and options. What might have worked for the client will not work effectively for the server. Starting testing only at pre-release stage and then trying to fix the bugs that come up then is so inefficient that it wouldn't work at all for such a complex system.

Having learned and benefited from modern methods of software development I am no longer willing to waste my time on work that can be avoided altogether, and I know that quite a few BOINC developers feel the same.

I think if BOINC is willing to survive (with its currently limited resources) its software development process needs to become much more efficient by adopting modern methods. This will also help to increase the resources in terms of volunteer software developers. If that's not going to happen, BOINC will die.


boinc_dev mailing list
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to