Mail Archives: geda-user/2016/01/02/13:50:45
--047d7b5d4976f3309605285e5c12
Content-Type: text/plain; charset=UTF-8
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-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
>
Sounds reasonable. For me there are two things I want "merge" to mean:
* it means other devels get it when they update whatever branch they
normally code off of.
It's an agreement between devs and needs good will to avoid making fellow
devs alpha
test your code, but in general I favor inflicting code on fellow devs a
bit earlier, rather than
on users after a shorter period of exposure to devs
* You can require it for other new devel branches
My only other concern is with rebase, which I continue to think is a
questionable approach for large arcs. Probably everyone is aware of this
already, but rebase rewrites history. If two arcs turn out to have an
interaction the one merged last tends to get blamed because that's where
bisect shows the bug, which can be really misleading.
essentially the 5 points Britton mentioned. Also, there must be test
> cases that demonstrate proper operation, and code coverage.
>
I like tests, but for some of the interactive features of pcb they look
hard to arrange. Perhaps as a compromise we could try to collect files
used and reports of how it got tested or something.
> 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
>
We have a lot of branches like this for sure, but I think for most of them
the devel has not asserted that it's done, in fact they explicitly say its
experimental, doesn't quite work everywhere yet, etc. If we could somehow
encourage people to complete these branches it would be lovely,
and active review might tend to help with that.
> 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.
>
This is a good policy for keeping the code base sane, and it's common
enough that as long as plugins are recognizable as such users generally
know to be wary :)
--047d7b5d4976f3309605285e5c12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jan 1, 2016 at 6:59 PM, al davis <span dir=3D"ltr"><<a href=
=3D"mailto:ad252 AT freeelectron DOT net" target=3D"_blank">ad252 AT freeelectron DOT net=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 1 Jan 2016=
17:30:07 -0900<br>
<span class=3D"">"Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail=
.com">britton DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie=
.com">geda-user AT delorie DOT com</a>]"<br>
</span><span class=3D""><<a href=3D"mailto:geda-user AT delorie DOT com">geda-u=
ser AT delorie DOT com</a>> wrote:<br>
<br>
> I stopped by the last sprint briefly and asked about this.=C2=A0 It so=
unds like<br>
> there's no definite policy for deciding when to merge things.=C2=
=A0 I therefore<br>
> propose that the following conditions should always be considered<br>
> sufficient for a merge into the main devel branch:<br>
><br>
>=C2=A0 =C2=A0* the person who wrote it says it's ready<br>
>=C2=A0 =C2=A0* at least one other person has looked at the patch<br>
>=C2=A0 =C2=A0* devel fixed or addressed any issues raised<br>
>=C2=A0 =C2=A0* it doesn't remove any functionality<br>
>=C2=A0 =C2=A0* it doesn't do anything known to be contentious<br>
<br>
</span>That brings up one of the reasons for gnucap plugins.<br>
<br>
I see a lot of projects turn into a mess due to a haphazard merge<br>
policy.<br>
<br>
In Gnucap ..<br>
<br>
The "master" branch is considered stable.=C2=A0 It is never chang=
ed<br>
directly.=C2=A0 The only change is for the "unstable" branch to b=
ecome<br>
master.=C2=A0 When the "unstable" branch has been shown to be rea=
dy, and has<br>
been stable for a month or two, it goes to "master".<br>
<br>
The "unstable" branch is kind of like master candidate.=C2=A0 It =
too is<br>
never changed directly.=C2=A0 The only changes are for some other branch to=
<br>
be pushed to unstable.<br>
<br>
Other branches are working branches, in various states.=C2=A0 Each one has =
a<br>
purpose.=C2=A0 That might be somebody's hack branch, or branches for<br=
>
specific changes.<br>
<br>
For a branch to be considered for merge, it must differ from unstable<br>
such that the only difference is that which is being proposed for<br>
merge, so it can be "fast-forward" merged into unstable, the same=
as it<br>
becomes the "unstable" branch.=C2=A0 It is discussed on the list,=
for<br></blockquote><div><br></div><div style=3D"">Sounds reasonable.=C2=
=A0 For me there are two things I want "merge" to mean:</div><div=
style=3D""><br></div><div style=3D"">* it means other devels get it when t=
hey update whatever branch they normally code off of.</div><div style=3D"">=
=C2=A0 It's an agreement between devs and needs good will to avoid maki=
ng fellow devs alpha</div><div style=3D"">=C2=A0 test your code, but in gen=
eral I favor inflicting code on fellow devs a bit earlier, rather than</div=
><div style=3D"">=C2=A0 on users after a shorter period of exposure to devs=
</div><div style=3D""><br></div><div style=3D"">* You can require it for ot=
her new devel branches</div><div style=3D""><br></div><div style=3D"">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.</div><div style=3D""><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
essentially the 5 points Britton mentioned.=C2=A0 Also, there must be test<=
br>
cases that demonstrate proper operation, and code coverage.<br></blockquote=
><div><br></div><div style=3D"">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.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Once merged, it is the responsibility of whoever is preparing another<br>
branch for merge to "rebase" to the new "unstable".<br>
<br>
Without a policy like this, the project can turn into a big mess, or<br>
the people trying to merge can spend a lot of time resolving conflicts.<br>
<br>
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<br>
mostly working, then move on never really finishing it.=C2=A0 So I look at<=
br></blockquote><div><br></div><div style=3D"">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,</div><div style=3D"">and a=
ctive review might tend to help with that.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
it, run the tests, and usually make some changes, to that branch.=C2=A0 The=
n<br>
push to unstable, or not, if it really isn't ready.<br><br>
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<br>
available.=C2=A0 For those, "the person who wrote it says it's rea=
dy" is all<br>
that is needed.<br></blockquote><div><br></div><div style=3D"">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 =
:)</div></div><br></div></div>
--047d7b5d4976f3309605285e5c12--
- Raw text -