Hi David!
On 2017-07-21 00:50, David Anderson wrote:
This discussion comes down to two contrasting models for software
development:
1) The "waterfall model":
...
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 "agile model" (as referenced by you) doesn't say anything about SCM
or branches. However, collaborative agile development requires and
implies doing basically all development (bugfixes, features, etc.) in
branches (see e.g. https://www.atlassian.com/agile/branching) to isolate
development, until a development is complete and merged back into a
'master' branch (that may or may not be called like that).
Master is unstable in both models; releases are done from stable branches.
Where do you get that from?
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.
When working on many things in parallel, working in branches even helps
me to stay structured and focused. There are tools to keep track of
which branch you are currently on, and ways to move commits from one
branch to another, if you accidentally committed to the wrong one.
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.
That doesn't require using a single branch ('master' or other).
Continuous Integration (like Travis on github) can and does test
(virtually) every branch on every configured platform. Everyone can
check out any branch and test this, without being affected by any
problems introduced by other development (in master) he doesn't care about.
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.
Apparently it worked for you quite well. However the way BOINC has been
developed in the past years is causing a lot of volunteer developers
quite some headache and trouble, up to the point where they quit
contributing. This is exactly why it needs to be improved.
Best,
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.
