>
> This breaks your model of applying every commit ref by ref.
How? The rebase only affects commits after the "real" branch, so it still
cleanly fast forwards?
Merging is *hard*. Especially 2.1 -> 3.0, with many breaking API changes
(this is before 8099, which is going to make a *world* of hurt, and will
stick around for a year). It is *very* easy to break things, with even the
utmost care.
On Thu, May 7, 2015 at 3:46 PM, Jake Luciani <jak...@gmail.com> wrote:
> You then fetch and repair
> your local version and try again.
>
> This breaks your model of applying every commit ref by ref.
>
> I'm all for trying to avoid extra work/stability but we already have
> added a layer of testing every change before commit. I'm not going to
> accept we need to also add a layer of testing before every merge.
>
>
>
>
> On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith
> <belliottsm...@datastax.com> wrote:
> >>
> >> wouldn't you need to force push?
> >
> >
> > git push --force-with-lease
> >
> > This works essentially like CAS; if the remote repositories are not the
> > same as the one you have modified, it will fail. You then fetch and
> repair
> > your local version and try again.
> >
> > So what does this buy us?
> >
> >
> > This buys us a clean development process. We bought into "always
> > releasable". It's already a tall order; if we start weakening the
> > constraints before we even get started, I am unconvinced we will
> > successfully deliver. A monthly release cycle requires *strict*
> processes,
> > not *almost* strict, or strict*ish*.
> >
> > Something that could also help make a more streamlined process: if actual
> > commits were constructed on development branches ready for commit, with a
> > proper commit message and CHANGES.txt updated. Even more ideally: with
> git
> > rerere data for merging up to each of the branches. If we had that, and
> > each of the branches had been tested in CI, we would be much closer than
> we
> > are currently, as the risk-at-commit is minimized.
> >
> > On Thu, May 7, 2015 at 2:48 PM, Jake Luciani <jak...@gmail.com> wrote:
> >
> >> git rebase -i trunk_staging <ref~1>
> >> fix the problem
> >> git rebase --continue
> >>
> >> In this situation, if there was an untested follow on commit wouldn't
> >> you need to force push?
> >>
> >> On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
> >> <belliottsm...@datastax.com> wrote:
> >> >>
> >> >> If we do it, we'll end up in weird situations which will be annoying
> for
> >> >> everyone
> >> >
> >> >
> >> > Such as? I'm not disputing, but if we're to assess the relative
> >> > strengths/weaknesses, we need to have specifics to discuss.
> >> >
> >> > If we do go with this suggestion, we will most likely want to enable a
> >> > shared git rerere cache, so that rebasing is not painful when there
> are
> >> > future commits.
> >> >
> >> > If instead we go with "repairing" commits, we cannot have a "queue" of
> >> > things to merge up to. Say you have a string of commits waiting for
> >> > approval C1 to C4; you made C1, and it broke something. You introduce
> C5
> >> to
> >> > fix it, but the tests are still broken. Did you not really fix it? Or
> >> > perhaps one of C2 to C4 are to blame, but which? And have you
> >> accidentally
> >> > broken *them* with your commit? Who knows. Either way, we definitely
> >> cannot
> >> > fast forward. At the very best we can hope that the new merge did not
> >> > conflict or mess up the other people's C2 to C4 commits, and they
> have to
> >> > now merge on top. But what if another merge comes in, C6, in the
> >> meantime;
> >> > and C2 really did also break the tests in some way; how do we
> determine
> >> C2
> >> > was to blame, and not C6, or C3 or C4? What do the committers for
> each of
> >> > these do? We end up in a lengthy tussle, and aren't able to commit
> any of
> >> > these to the mainline until all of them are resolved. Really we have
> to
> >> > prevent any merges to the staging repository until the mistakes are
> >> fixed.
> >> > Since our races in these scenario are the length of time taken for
> cassci
> >> > to vet them, these problems are much more likely than current race to
> >> > commit.
> >> >
> >> > In the scheme I propose, in this scenario, the person who broke the
> build
> >> > rebases everyone's branches to his now fixed commit, and the next
> broken
> >> > commit gets blamed, and all other commits being merged in on top can
> go
> >> in
> >> > smoothly. The only pain point I can think of is the multi-branch
> rebase,
> >> > but this is solved by git rerere.
> >> >
> >> > I agree running tests is painful, but at least for the build, this
> should
> >> >> be the responsibility of the committer to build before merging
> >> >
> >> >
> >> > Why make the distinction if we're going to have staging commits? It's
> a
> >> bit
> >> > of a waste of time to run three ant real-clean && ant tasks, and
> >> increases
> >> > the race window for merging (which is painful whether or not involves
> a
> >> > rebase), and it is not a *typical* occurrence ("alarming" is
> subjective)
> >> >
> >> > On Thu, May 7, 2015 at 2:12 PM, Sylvain Lebresne <
> sylv...@datastax.com>
> >> > wrote:
> >> >
> >> >> > If one of them breaks, we go and edit the _staging branch in place
> to
> >> >> correct
> >> >> > the problem, and let CI run again.
> >> >>
> >> >> I would strongly advise against *in place* edits. If we do it, we'll
> >> end up
> >> >> in
> >> >> weird situations which will be annoying for everyone. Editing commits
> >> that
> >> >> have
> >> >> been shared is almost always a bad idea and that's especially true
> for
> >> >> branch
> >> >> that will have some amount of concurrency like those staging
> branches.
> >> >>
> >> >> Even if such problems are rare, better to avoid them in the first
> place
> >> by
> >> >> simply
> >> >> commit new "fixup" commits as we currently do. Granted this give you
> a
> >> >> slightly
> >> >> less clean history but to the best of my knowledge, this hasn't been
> a
> >> pain
> >> >> point so far.
> >> >>
> >> >> > wait for CI; all clear
> >> >> >
> >> >> > git checkout cassandra-2.0; git merge cassandra-2.0_staging
> >> >> > git checkout cassandra-2.1; git merge cassandra-2.1_staging
> >> >> > git checkout trunk; git merge trunk_staging
> >> >> >
> >> >> > This does introduce some extra steps to the merge process
> >> >>
> >> >> If we do this, we should really automate that last part (have the CI
> >> >> environment merge the staging branch to the non-staging ones on
> >> success).
> >> >>
> >> >> > It seems if we want an "always releasable" set of branches, we need
> >> >> something
> >> >> > along these lines.
> >> >>
> >> >> Agreed as far as having staging branches vetoed by CI goes. Less sure
> >> about
> >> >> the edit-commit-in-place part as said above.
> >> >>
> >> >> > I certainly break tests by mistake, or the build itself, with
> alarming
> >> >> regularity.
> >> >>
> >> >> I agree running tests is painful, but at least for the build, this
> >> should
> >> >> be
> >> >> the responsibility of the committer to build before merging. We all
> >> forget
> >> >> it from
> >> >> times to times and that's ok, but it's not ok if it's "alarmingly
> >> regular".
> >> >>
> >> >> --
> >> >> Sylvain
> >> >>
> >>
> >>
> >>
> >> --
> >> http://twitter.com/tjake
> >>
>
>
>
> --
> http://twitter.com/tjake
>
