It's odd, because I honestly think this release process will be easier,
since the stricter we make it the smoother it can become. It requires well
formed commits from everyone, and lets the committers asynchronously
confirm their work, and for it to never be in question *who* needs to fix
something, nor what the effect of their fixing it will be. It means we can,
as Ariel said, perform a bisect and honestly know its result is accurate.
Small commits don't need to worry about fast-forwarding; in fact, nobody
does. It can either be automated, or we can fast forward at a time that
suits us. In which case the process is *the same* as it is currently.
I have no interest in making the commit process harder.
On Thu, May 7, 2015 at 3:59 PM, Jake Luciani <jak...@gmail.com> wrote:
> 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
>
