On Fri, Jan 1, 2016 at 6:59 PM, al davis <ad252 AT freeelectron DOT net= > wrote:

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-u= ser AT delorie DOT com> wrote:

> I stopped by the last sprint briefly and asked about this.=C2=A0 It so= unds like
> there's no definite policy for deciding when to merge things.=C2= =A0 I therefore
> propose that the following conditions should always be considered
> sufficient for a merge into the main devel branch:
>
>=C2=A0 =C2=A0* the person who wrote it says it's ready
>=C2=A0 =C2=A0* at least one other person has looked at the patch
>=C2=A0 =C2=A0* devel fixed or addressed any issues raised
>=C2=A0 =C2=A0* it doesn't remove any functionality
>=C2=A0 =C2=A0* 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.=C2=A0 It is never chang= ed
directly.=C2=A0 The only change is for the "unstable" branch to b= ecome
master.=C2=A0 When the "unstable" branch has been shown to be rea= dy, and has
been stable for a month or two, it goes to "master".

The "unstable" branch is kind of like master candidate.=C2=A0 It = too is
never changed directly.=C2=A0 The only changes are for some other branch to=
be pushed to unstable.

Other branches are working branches, in various states.=C2=A0 Each one has = a
purpose.=C2=A0 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.=C2=A0 It is discussed on the list,= for

Sounds reasonable.=C2= =A0 For me there are two things I want "merge" to mean:

* it means other devels get it when t= hey update whatever branch they normally code off of.

= =C2=A0 It's an agreement between devs and needs good will to avoid maki= ng fellow devs alpha

=C2=A0 test your code, but in gen= eral I favor inflicting code on fellow devs a bit earlier, rather than

=C2=A0 on users after a shorter period of exposure to devs=

* You can require it for ot= her new devel branches

My on= ly other concern is with rebase, which I continue to think is a questionabl= e approach for large arcs.=C2=A0 Probably everyone is aware of this already= , but rebase rewrites history.=C2=A0 If two arcs turn out to have an intera= ction the one merged last tends to get blamed because that's where bise= ct shows the bug, which can be really misleading.

essentially the 5 points Britton mentioned.=C2=A0 Also, there must be test<= br> cases that demonstrate proper operation, and code coverage.

I like tests, but for some of the interacti= ve features of pcb they look hard to arrange.=C2=A0 Perhaps as a compromise= we could try to collect files used and reports of how it got tested or som= ething.
=C2=A0
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<= br> ready", it isn't.=C2=A0 It's common for people to start on som= ething, get it
mostly working, then move on never really finishing it.=C2=A0 So I look at<= br>

We have a lot of branches li= ke this for sure, but I think for most of them the devel has not asserted t= hat it's done, in fact they explicitly say its experimental, doesn'= t quite work everywhere yet, etc.=C2=A0 If we could somehow encourage peopl= e to complete these branches it would be lovely,
and a= ctive review might tend to help with that.
=C2=A0
it, run the tests, and usually make some changes, to that branch.=C2=A0 The= n
push to unstable, or not, if it really isn't ready.

The policy for plugins is different.=C2=A0 There is another repository for<= br> plugins not distributed with the main program but still distributed and
available.=C2=A0 For those, "the person who wrote it says it's rea= dy" is all
that is needed.

This is a go= od policy for keeping the code base sane, and it's common enough that a= s long as plugins are recognizable as such users generally know to be wary = :)