I'm really not a fan of allowing Comcast to dictate the release scope and
schedule. If cherry-picking is too messy, then we can just cut new minor
releases directly from master.
On Tue, Oct 29, 2019, 15:59 Jeremy Mitchell wrote:
> I don't think it's as easy as cherry picking (backporting) certai
Yeah, I get it. No one company should be driving release schedules/scope.
What I was really getting at is if ANY company has a recent version in a
test or prod-like enviro (meaning the version is being exercised and
thoroughly tested), then maybe we consider simply cutting a release from
that vers
In my opinion, in order to get to a cadence we are discussing we need to put a
lot more work into the CI system. It has been failing consistently, doesn’t
block PR approvals/merges and when it actually runs it does not test anything
besides build and license headers.
In the past couple of weeks
> What I was really getting at is if ANY company has a recent version in a
> test or prod-like enviro (meaning the version is being exercised and
> thoroughly tested), then maybe we consider simply cutting a release from
> that version
I think the idea s that companies should stop doing th
Ok, I'm starting to see the light. If we moved faster, 4.1, 4.2, 4.3 for
example 6 weeks apart then maybe where I work (Comcast) would get on board
with actually using those releases (rather than some arbitrary point on
master because the open source releases are moving too slow for us).
But I sti
+1 on more frequent releases
+1 on improving our CI. We need to get our CI to the point where we're
confident deploying changes to production if the CI passes.
+1 on "trunk-based" development as opposed to GitFlow
-1 on cherry-picking new features. This is risky, tedious, and
represents unnecessary
Sorry, I have taken too long to respond.
+100 on better CI and Testing, I think we all agree that needs to get
better and is a different beast than this topic.
As for the release branches, I am trying to follow a process similar to
ATS, which is usually the model we try to follow with our pro
Did we define why/how what we've been doing isnt' working? I see a consensus
that it's not, suggestions on alternatives, and an ambition for faster and more
stable; but not a definition of the thing is the reason why we must change?
Not saying we shouldn't, but I'm just asking so we try not
still -1 on on cherry-picked releases if this is what i'm hearing:
4.0 (derived from master)
4.1 (derived from 4.0 plus some cherry picks from master introduced during
the last 6 weeks)
4.2 (derived from 4.1 plus some cherry picks from master introduced during
the last 6 weeks)
4.3 (derived from 4
No, that's not correct.
You have a 4.x branch that almost everything gets cherry-picked to. Think
of this as now being the "stable" branch. Everything gets committed to
master and anything we want to release gets cherry picked into the stable
branch, 4.x. This should be everything that is comple
There are many things that are not working. First of all we do not have
any semblance of a consistent release pattern. If I get my feature merged
into Traffic Control today, I have no idea when that'll actually be in a
release. Secondly, we do not currently have any way to limit what goes
into a
Cherry picking is scary. It will always have some associated risk. I
understand that the point is to emulate pulling commits out rather than
picking ones in, so that incomplete features and risky changes can be left
out of a release that otherwise ought to be all-encompassing. However, that
means e
Thanks Brennan. I agree that cherry picking can be scary, but it doesn’t
have to be. I hear you on the risks but I think we need to start
somewhere. I feel like this won’t be as in practice as it may seem now and
we may be dealing with some FUD. I could also be absolutely wrong and
pushing a tota
I guess my concern is really about what possible reasons we might have
to not cherry-pick a specific PR that had been merged into master
already. The only reasons I can think of to not cherry-pick something
would be:
1. the PR was completely broken (e.g. breaks the build, tests don't
pass, doesn't
It sounds like you're wanting to convert from Github Flow to regular Gitflow,
but change what branches do what.
https://lucamezzalira.com/2014/03/10/git-flow-vs-github-flow/
Jonathan G
On 10/30/19, 5:35 PM, "Rawlin Peters" wrote:
I guess my concern is really about what possible reasons w
15 matches
Mail list logo
