Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
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.
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
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
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
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
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.