Hi,
I agree with release (or even collaboration branches) having the same
approach for only merging code that has run in cassci off of that branch.
Ariel
On Thu, May 7, 2015 at 1:34 PM, Aleksey Yeschenko
wrote:
> > +100 from me, but why the exception for trunk?
>
> Sorry, just my poor wording
> +100 from me, but why the exception for trunk?
Sorry, just my poor wording again. No exception for trunk. What I meant by
‘non-trunk’ patches was patches that originated in 2.0 or 2.1 branches. ‘trunk’
patches (today) would be 3.0-only features and fixes, and these need no
upstream merging, b
> In the meantime can we agree on having cassci to validate personal merged
branches before pushing either, in case of non-trunk patches?
+100 from me, but why the exception for trunk? Wouldn't it be easier to
wait for the dev branch tests to pass and then do all the merging at once
(2.0, 2.1,3.0,
> Agreed. I would like to wait and see how we do without extra branches for
> a release or two. That will give us a better idea of how much pain the
> extra steps will protect us from.
In the meantime can we agree on having cassci to validate personal merged
branches before pushing either, in c
>
> I would argue that we must *at least* do the following for now.
If we get this right, the extra staging branches can certainly wait to be
assessed until later.
IMO, any patch should have a branch in CI for each affected mainline
branch, and should have the commit completely wired up (CHANGES
Hi,
I meant in the hypothetical case that we did this. There is going to be an
interim period where we wouldn't have this. The automation comes at the
expense of something else.
Ariel
On Thu, May 7, 2015 at 11:40 AM, Josh McKenzie
wrote:
> >
> > So who and when is going to implement the automa
On Thu, May 7, 2015 at 7:13 AM, Aleksey Yeschenko
wrote:
>
> That said, perhaps it’s too much change at once. We still have missing
> pieces of infrastructure, and TE is busy with what’s already back-logged.
> So let’s revisit this proposal in a few months, closer to 3.1 or 3.2, maybe?
>
Agreed.
>
> So who and when is going to implement the automation?
I don't believe we have sufficient consensus that this is necessary to
start doling out action-items for implementation.
On Thu, May 7, 2015 at 10:16 AM, Ariel Weisberg wrote:
> Hi,
>
> If it were automated I would have no problem with
Hi,
If it were automated I would have no problem with it. That would be less
work for me because the problems detected would occur anyways and have to
be dealt with by me. I just don't want to deal with extra steps and latency
manually.
So who and when is going to implement the automation?
Ariel
I would argue that we must *at least* do the following for now.
If your patch is 2.1-based, you need to create a private git branch for that
and a merged trunk branch ( and -trunk). And you don’t push anything
until cassci validates all of those three branches, first.
An issue without a
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
>
> 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.
While I agree re:merging, I'm not convinced the propo
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
Hi,
Sorry didn't mean to blame or come off snarky. I just it is important not
to #include our release process from somewhere else. We don't have to do
anything unless it is necessary to meet some requirement of what we are
trying to do.
So the phrase "Trunk is always releasable" definitely has so
>
> 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
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
It's a bit unfair to characterize Aleksey as subscribing to a cargo cult.
*We* agreed to define the new release process as "keeping trunk always
releasable".
Your own words that catalyzed this: "If we release off trunk it is pretty
much necessary for trunk to be in a releasable state all the time"
>
> 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
"Our process is our own" <- always remember this.
> On May 7, 2015, at 9:25 AM, Ariel Weisberg
> wrote:
>
> Hi,
>
> Whoah. Our process is our own. We don't have to subscribe to any cargo cult
> book buying seminar giving process.
>
> And whatever we do we can iterate and change until it works
Hi,
Whoah. Our process is our own. We don't have to subscribe to any cargo cult
book buying seminar giving process.
And whatever we do we can iterate and change until it works for us and
solves the problems we want solved.
Ariel
On Thu, May 7, 2015 at 10:13 AM, Aleksey Yeschenko
wrote:
> Stri
I'm not sure how I feel about this, on the one hand cleaner trunk is good,
on the other, added complexity leaves more room for error. I'm +0 currently.
> We still have missing pieces of infrastructure, and TE is busy with
what’s already back-logged. So let’s revisit this proposal in a few months,
Strictly speaking, the train schedule does demand that trunk, and all other
branches, must be releasable at all times, whether you like it or not (for the
record - I *don’t* like it, but here we are).
This, and other annoying things, is what be subscribed to tick-tock vs.
supported branches exp
Hi,
I don't think this is necessary. If you merge with trunk, test, and someone
gets in a head of you just merge up and push to trunk anyways. Most of the
time the changes the other person made will be unrelated and they will
compose fine. If you actually conflict then yeah you test again but this
>
> I still think this is overly complicated. We still
> need to run CI before we release. So what does this buy us?
I second this line of questioning. This sounds like we have a solution
looking for a problem; we're not talking about people git cloning our repo
and running it in production.
On
git rebase -i trunk_staging
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
wrote:
>>
>> If we do it, we'll end up in weird situations which will be annoyin
>
> 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 re
ah missed that. I still think this is overly complicated. We still
need to run CI before we release. So what does this buy us?
On Thu, May 7, 2015 at 9:24 AM, Aleksey Yeschenko wrote:
>> The is still the problem of a commit coming into the staging dir after
>> a previous commit that is being test
> The is still the problem of a commit coming into the staging dir after
> a previous commit that is being tested.
> When the first commit is merged to the stable branch it will include
> both tested and untested version.
How so? We’ll only be merging up to the latest tested ref into the stabl
The is still the problem of a commit coming into the staging dir after
a previous commit that is being tested.
When the first commit is merged to the stable branch it will include
both tested and untested version.
Let's not take releasable branches to literally, we still need to tag
and test every
> Agreed as far as having staging branches vetoed by CI goes. Less sure about
> the edit-commit-in-place part as said above.
Right. That’s just an implementation detail (in place vs. extra fix up
commits). The latter is less annoying for the team in general, let’s do that
instead.
> If we do t
> 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
+1. I would ask that if we end up doing this that it be documented on the
wiki.
Gary.
On Thu, May 7, 2015 at 4:05 AM, Benedict Elliott Smith <
belliottsm...@datastax.com> wrote:
> A good practice as a committer applying a patch is to build and run the
> unit tests before updating the main reposi
If the goal is to have branches that are always passing all the tests (aka
‘stable’ branches), then I don’t see any workarounds,
so +1 to this.
I’d go for branch names that are less likely to be confused w/ final
cassandra-X via autocomplete though: staging-2.0, staging-2.1, staging-trunk.
--
33 matches
Mail list logo
