This discussion comes down to two contrasting models for software development:
1) The "waterfall model":
https://en.wikipedia.org/wiki/Waterfall_model
New features are done as a unit, with sequential phases
(requirements, design, implementation, verification, maintenance).
E.g., requirements and design don't change during implementation.
Typically, development is done in a separate branch,
which is merged with master at the end.
2) The "agile model":
https://en.wikipedia.org/wiki/Agile_software_development
New features are divided into smaller self-contained pieces,
which are completed and merged with master frequently.
Requirements and design can change on the fly.
Development need not be done in a separate branch.
The role of master differs somewhat.
It changes more frequently in the agile model.
Master is unstable in both models; releases are done from stable branches.
In both models there may be periods when master doesn't work.
These periods are more frequent in the agile model.
---------------
Each model has pros and cons.
The waterfall model is generally regarded as old and ineffective.
The corporate software world has found that the agile model generally works better
for them,
and has moved to it en masse.
For distributed open-source projects like BOINC,
the agile model has some aspects - such as a daily face-to-face "scrum" meeting
-
that would be difficult to do, so it must be adapted somewhat.
Oliver prefers the waterfall model,
so strongly that he won't work with people who use agile.
I'll leave it to him to explain this preference.
I prefer the agile model for several reasons:
1) In the way I develop, requirements/design/implementation proceed iteratively and
in parallel.
I find many situations where the implementation has become difficult or awkward,
and I can fix this by changing the design or even the requirements.
2) I often work on several things at once.
If I do each one in a separate branch,
I inevitably commit code to the wrong branch,
and it's hard to untangle things later.
3) I want my code reviewed and tested by others ASAP.
I have only Win7 and Linux computers.
If my code doesn't work on other platforms, I want to know this ASAP.
I want to commit to master in small-size, frequent units.
4) It's worked extremely well so far.
BOINC has evolved rapidly and continuously over 15 years.
It's still very malleable and well-structured, making it easy to change and add.
Very few big software systems can say this.
------------
Which model should we use in BOINC?
I don't think we need to pick one or the other.
The owner of each software area (client, manager, etc.) could choose one.
Or we could leave it up to the developer.
And, as I've said repeatedly, the major problems facing BOINC -
such as the inadequacy of documentation
and the lack of volunteers for software release management -
don't involve software development,
the choice of model doesn't have much bearing on them.
Let's not get hung up on it.
Also, let's not confuse the choice of model with how we do stable branches.
Of course we need stable branches for server software and API.
The agile model doesn't preclude this.
-- David
_______________________________________________
boinc_dev mailing list
[email protected]
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
