Mail Archives: geda-user/2016/01/02/02:48:30.1
On Fri, 1 Jan 2016 17:30:07 -0900
"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
<geda-user AT delorie DOT com> wrote:
> I stopped by the last sprint briefly and asked about this. It sounds like
> there's no definite policy for deciding when to merge things. I therefore
> propose that the following conditions should always be considered
> sufficient for a merge into the main devel branch:
>
> * the person who wrote it says it's ready
> * at least one other person has looked at the patch
> * devel fixed or addressed any issues raised
> * it doesn't remove any functionality
> * it doesn't do anything known to be contentious
That brings up one of the reasons for gnucap plugins.
I see a lot of projects turn into a mess due to a haphazard merge
policy.
In Gnucap ..
The "master" branch is considered stable. It is never changed
directly. The only change is for the "unstable" branch to become
master. When the "unstable" branch has been shown to be ready, and has
been stable for a month or two, it goes to "master".
The "unstable" branch is kind of like master candidate. It too is
never changed directly. The only changes are for some other branch to
be pushed to unstable.
Other branches are working branches, in various states. Each one has a
purpose. That might be somebody's hack branch, or branches for
specific changes.
For a branch to be considered for merge, it must differ from unstable
such that the only difference is that which is being proposed for
merge, so it can be "fast-forward" merged into unstable, the same as it
becomes the "unstable" branch. It is discussed on the list, for
essentially the 5 points Britton mentioned. Also, there must be test
cases that demonstrate proper operation, and code coverage.
Once merged, it is the responsibility of whoever is preparing another
branch for merge to "rebase" to the new "unstable".
Without a policy like this, the project can turn into a big mess, or
the people trying to merge can spend a lot of time resolving conflicts.
In my experience, usually when "the person who wrote it says it's
ready", it isn't. It's common for people to start on something, get it
mostly working, then move on never really finishing it. So I look at
it, run the tests, and usually make some changes, to that branch. Then
push to unstable, or not, if it really isn't ready.
The policy for plugins is different. There is another repository for
plugins not distributed with the main program but still distributed and
available. For those, "the person who wrote it says it's ready" is all
that is needed.
- Raw text -