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.
Bernd
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
