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.

Reply via email to