I think a third reason would be that we are getting very close to our
release branch date, it's a large/complex feature, and we feel like the
release already has enough in it. In that case we could hold off on adding
that change to the 4.x branch until after we cut the 4.x.x branch. The
benefit i
I was trying to avoid using that term since it is different enough to not
be exactly the same, though it is very similar.
On Wed, Oct 30, 2019 at 7:34 PM Gray, Jonathan
wrote:
> It sounds like you're wanting to convert from Github Flow to regular
> Gitflow, but change what branches do what.
> ht
Thanks to all who voted!
The release has PASSED with the following PMC votes:
+1 Dave Neuman (binding)
+1 Jeremy Mitchell (binding)
+1 Rawlin Peters (binding)
I will proceed to publish the release and send ANNOUNCE.
On behalf of Apache Traffic Control, thank you!
Regards,
Derek Gelinas
dgeli..
The Apache Traffic Control team is proud to announce the release of Apache
Traffic Control 3.1.0.
More details regarding Apache Traffic Control can be found at:
http://trafficcontrol.apache.org/
The release artifacts, along with release notes, can be found here:
http://trafficcontrol.apache.o
Alright, I think that sounds fair. In general what I'm hearing is,
every 4-6 weeks:
1. fast-forward 4.x to the most recent "stable" commit of master
(maybe we automate this and fast-forward every day if some set of
tests pass, unless we explicitly know master is unstable for other
reasons)
2. cut 4
Just throwing out that the judicious use of feature flags could reduce the pain
from unstable or incomplete new features. Long lived feature branches are
something I believe should be avoided.
Geoff
On 10/31/19, 2:32 PM, "Rawlin Peters" wrote:
Alright, I think that sounds fair. In gener
I agree, but this release process wouldn't lead to long-lived feature
branches since all development would still be done on master and
merged into master. Unstable or incomplete features could potentially
delay releases from going out, but I agree that feature flags could
mitigate those problems. A
We are in violent agreement and that was sort of the point I was making. I’m
wholly in favor of release process that encourages development that tracks
master as close as possible and discourages long lived branches. Features imho
should be written in a way that is always seamlessly (as much a
Hey all,
We've been picking up momentum in the TO Perl -> Go rewrite recently,
which has gotten me thinking of ways to reduce the risk of possible
regressions in the rewritten APIs. I'd like to propose that we
implement a sort of "routing blacklist" for the TO API routes.
At a high level, this bl
Not trying to sideswipe, but could we expose that as an endpoint with a Golang
list as well to solve: https://github.com/apache/trafficcontrol/issues/2872
Jonathan G
On 10/31/19, 3:51 PM, "Rawlin Peters" wrote:
Hey all,
We've been picking up momentum in the TO Perl -> Go rewrite rece
Yeah, I think that about sums it up. Hopefully we can help the release
manager with some of those responsibilities.
On Thu, Oct 31, 2019 at 2:31 PM Rawlin Peters wrote:
> Alright, I think that sounds fair. In general what I'm hearing is,
> every 4-6 weeks:
> 1. fast-forward 4.x to the most recen
11 matches
Mail list logo
