[Coco] making patches to NitrOS-9 (part II)

[Tormod Volden]

On Sat, Jan 24, 2015 at 4:45 PM, Bill Pierce via Coco wrote:
>
> Tormod,
> First I would like to thank you in acting as "moderator" to the NitrOS9 repository changes. I (and others) trust your judgement as well as your knowledge in how the system functions.

Hi Bill,
Thanks for that.

> I have one issue with all the changes being made with "commits" to the repo. If someone makes changes that are not quite finished, or maybe even has typos they haven't caught (it happens), then this makes the repo uncompilable for everyone else until the issue is fixed. Also, any "experimental" code may be thought to be "stable" by the end user and then we get the questions/accusations on the list like "why doesn't xxx work?" etc.

Has this happened at all over the last 1 1/2 year?

> My suggestion is to use separate branches, one for a "stable current release" build and a 2nd for "experimental/developmental" builds. In this way, we have a branch that will "always" build stable, usable code, and a 2nd branch that developers can work on new code and modify the old for new features and bug fixes.
> Once the "experimental" branch reaches a state of "stable", it can be merged with the current release as a new revision.

No.

First, there is not much experimental work going on. In fact there is
very little going on. There is not a herd of code monkeys working on
NitrOS-9 like we might be hoping for. With this level of activity,
there is no need for an experimental branch.

Second, we have stable releases for end users. We don't have anyone to
evaluate and pick fixes from the development branch and feeding into a
"stable" branch. At this moment, almost a year after 3.3.0, there are
not many things that would be worth picking into a stable branch while
keeping the other changes out.

> Branches could be named as:
> nitros9_3.3.0
> nitros9_3.3.1d_dev (or nitros9_3.3.1b_beta)
> or something similar and appropriate.
>
> I feel this approach would "side rail" something I see coming which is a big clash of "but I made my changes first" and "why won't the repo build?" etc.

When was the last time the repo did not build?

The clashes of the kind "but I made my changes first" arise when you
have multiple branches, and when the developers have no clue how to
work with other people. Already, if everybody follows the rules I
outlined in the above tutorial, there should be very little chance of
clashes.

The nightmare that was the NitrOS-9 repository of 2 years back was due
to having multiple branches (for no good reason) and developers not
using collaboration tools like mercurial properly, and generally
working on the code as if they were alone on it and would be forever.

If I so strongly reject this suggestion it is because I don't want
anyone to have to do what I had to do to get the repository back into
shape again. I will surely not do it again.

>
> Most other "open source" projects I have seen use this very approach and and have a "stable" current release as well as a "developer beta" release for trying new features.
> Without this being implemented, the "clash" is inevitable.

The open source projects you probably see around have lots of active
developers, and who know how to work together and use development
tools for what it is worth.

>
> In this way, those of us who don't want to play around with experimental code or maybe even crash our builds when we need the current release, would have a "stable" build branch that can be relied on.
>

If you want to be sure you have stable code, stay with the last stable release.

Crashing builds? Not in the NitrOS-9 repo, I believe.

The current release that you need? 3.3.0? Or you mean the current
development code (as in not released, by definition)?

> I have already had a couple of instances that I caught "errors" in that code was not quite ready and the build failed. These usually disappeared by the next day, but that was a day I had to wait on something I needed immediately or I wouldn't have been compiling a new set of dsks.

I can't remember this having happened at all, but please refresh my
memory. If at all, this must have been very seldom. If this becomes a
problem, the solution is to limit commit rights to people who know
what they are doing (like running a test build before uploading the
changes), and encourage people to have their stuff reviewed by another
person before committing. This is in fact how most open source
projects work.

What was this that you needed immediately? If it is a new feature, it
has not been tested much and must be considered experimental and
wouldn't belong in a stable branch. If is is a bug fix, build the repo
version that just includes this fix, and do not update continuously.

Of course when it comes to you Bill, we are dependent on people like
you testing the latest code as often as possible. If one version
fails, you can just play back to yesterday's build and wait for the
fix to happen before you fast-forward to the development "tip" again.
A know build issue is fixed in hours or a few days. What is the
problem?

I see your worries as purely hypothetical and I am afraid your talking
about "build crashes" can scare people away from running the latest
builds. It is generally very stable and safe code.

Best regards,
Tormod