[Vm-dev] Should I push or request a pull?

[Frank Shearar]

On 24 June 2016 at 10:06, Eliot Miranda <eliot.miranda at gmail.com> wrote:

>
> Hi Holger,
>
>
> > On Jun 20, 2016, at 1:24 AM, Holger Freyther <holger at freyther.de> wrote:
> >
> >
> >
> >> On 20 Jun 2016, at 09:53, Norbert Hartl <norbert at hartl.name> wrote:
> >>
> >>
> >>
> >> A commit is associated with a comment. So commits should be rather
> small and describing the change. Most of the time there are some
> changes/commits that only make sense when being together. This would be the
> view from the build server or from the process of having buildable
> artifacts all the time. So you can see it as freedom to have a commit that
> breaks the software which can be build after 5 more commits. So no problem
> for the world if you push 5 commits at once.
> >
> > This approach breaks tools like git bisect. If a user has something
> easy/quick to reproduce and a "good" version and "bad" one, he/she can
> identify the first broken commit almost automatically. If commits are small
> then it is quite easy for the maintainer to identify the issue and resolve
> it.
>

That's true only for commits _on master_, right? (More accurately, IIUC git
bisect will binary search over a chain of commits. If a merged-into-master
feature branch has a commit that doesn't compile, git bisect will not even
see that commit; it will walk over the merge commit, marking it good/bad.

frank


> > Projects like Linux have the policy that each single commit needs to
> compile and for my GPRS/EDGE PCU[1] we have the same policy and I can point
> to a recent example of git bisect used by a user[2]. As a maintainer this
> reduces the work I have to do.
> >
> > In the context of spur there is a significant performance regression of
> our TCAP benchmark from one spur version to another and with git bisect I
> could do:
> >
> > git bisect start
> > git bisect good <SHA1 of better VM>
> > git bisect bad <SHA1 of first bad VM>
> >
> > and then commits from good to bad will be picked and all I need to do is:
> >
> > make
> > bench
> >
> > and then decide to mark this commit as:
> >
> > git bisect bad
> > git bisect good
> >
> > and eventually end with the first bad commit (or none if I track noise)
> >
> >
> > It is obviously up to the maintainers if they want to support git bisect
> but thanks to git it is not really a burden. One can experiment with
> temporary branches and then rebase to a final and working patchset. With
> later git versions can be easily automated as well.
>
> I think this is a very sensible policy and that we should support bisect.
> Do you have energy to work with Tim F to update CONTRIBUTING.md to include
> this policy?  Are there ways of enforcing or advising the policy when using
> git tools or is it simply something we have to tell users? This latter
> approach is terribly fragile.
>
> >
> > git rebase -i --execute "./compile_and_test_all.sh" origin/master
> > close the editor..and git starts compiling all your intermediate commits
> and stops if they fail
> >
> >
> >
> > kind regards
> >    holger
> >
> >
> >
> >
> > [1] A GSM component that converts a LLC frame to smaller pieces. Decides
> on the coding scheme (error correction bits vs. data), schedules resources
> across several handsets.
> > [2] http://lists.osmocom.org/pipermail/openbsc/2016-May/009139.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160624/c1747d61/attachment-0001.htm