Ok let's focus then on the idea that trunk is releasable. Releasable
to me doesn't mean it can't contain a bad merge.
It means it doesn't contain some untested and unstable feature. We
can always "release from trunk" and we still have a release process.
The idea that trunk must contain. a first time it hits the branch,
releasable code is way overboard
On Thu, May 7, 2015 at 10:50 AM, Benedict Elliott Smith
<belliottsm...@datastax.com> wrote:
>>
>> 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
>>
--
http://twitter.com/tjake
