My point is that there doesn't need to be a bunch of process and ceremony
about choosing what we are going to do after 7.
Just submit a PR for Rocky8 if someone wants to support something else they
are welcome to do so, they can just submit another PR.
On Tue, Feb 1, 2022 at 10:21 AM ocket w
+1, this sounds great, thanks Zach!
On Tue, Jun 9, 2020 at 9:46 AM Zach Hoffman wrote:
> Hey all,
>
> I'd like to share a pull request that should improve the ATC development
> experience for macOS users:
> https://github.com/apache/trafficcontrol/pull/4758
>
> The PR lets you build the ATC RPMs
If you cannot go from 3.x -> 4.1 (I'll concede a few gotchas) then 4.1
shouldn't be a minor release.
As others have stated though, it should work.
On Tue, Apr 21, 2020 at 1:24 PM Rawlin Peters wrote:
> We squashed the DB migrations in the 4.0 release, so you would need to
> at least run the DB m
The reason we used to have an RM for the whole life of a major release is
because we used to cut a single release branch and then build all of the
releases off of that. We would cut a 2.x or 3.x branch and then create a
tag at the 3.0 release. We would then backport whatever changes we wanted
in
'd volunteer for one on install/upgrade/lab.infra/automation/ci/cd.
>
> Jonathan G
>
>
> On 11/13/19, 3:07 PM, "Jeremy Mitchell" wrote:
>
> I'll bite. I'd like to start one for TP.
>
> On Wed, Nov 13, 2019 at 2:50 PM David Neuman
@Robert Butts , there is a process to create more
mailing lists, Phil helped me do it to create summits@
If someone is interested in starting our first working group, I will be
happy to help.
On Wed, Nov 13, 2019 at 2:23 PM Robert O Butts wrote:
> +1 on Working Groups, the IETF also works by co
; have only "interesting" features so the releases are
> > > incrementally very
> > > > > > small and much easier to test/validate, however, those
> features
> > > might
> > > > > > depend on other commits. At some point, che
gt; > > > > in master and will get picked up in 5.0?)
> > > > > >
> > > > > > In theory, it sounds great. 4.1, 4.2, 4.3 all are
> roughly 6
> > > weeks apart
> > > > > and
> > > > > > have only "interesting" features so the releases are
> > > incrementally very
I have been thinking about how we can get better with our release cadence.
I feel like we have slowed to a crawl and not been as good as we should
about how we release. Our last Major release was in March and we haven't
had a real release since. Moving forward I would like to see us get on a
mor
Hey All,
It's been long enough and I think it's time we get serious about our 4.0
release. Our last Major release was 3.0 which was released in March. We
have a 3.1 release candidate out now (GO VOTE!) but that release contains
just a few fixes on top of 3.0. There have been several big features
Individual developers and those that merge their PRs should be responsible
for developing and testing the `goose down` portion of a migration, this
does not change.
The whole argument is that relying on goose down for rollbacks is less than
ideal because you have to run it 1 time per migration that
I can talk to John about Next Hop.
Rawlin's not going to be able to make the summit (he's getting married!) so
I'll see if I can find someone to speak to dynamic cache hierarchy.
On Fri, Oct 5, 2018 at 12:18 PM Jan van Doorn wrote:
> Should we put something on the schedule about next hop and dyn
gt; > >
> > > Yes , those are all good things. But in practice, that list will be
> used
> > as
> > > a hammer to beat people over the head, and refuse to merge PRs without
> > > complete tests and docs.
> > >
> > > It's already too diffi
Looks good Jeremy. Only nit I would pick would be to add documentation to
your list of components.
Thanks,
Dave
On Mon, Aug 13, 2018 at 8:13 PM Jeremy Mitchell
wrote:
> I've created a very simple PR template based on some input from this email
> thread. The PR is found here:
> https://github.c
, Derek
wrote:
> I might want to take a shot at it.
>
> On 6/8/18, 11:43 AM, "David Neuman" wrote:
>
> Hey All,
> It looks like our next release will be 3.0. In preparation for
> planning the
> release, I would like to see who is interested in bein
Hey Justin,
I know this was sent from an automated system, but Traffic Control has
graduated! Is there anything we need to do to be removed from the
Incubator Report list?
Thanks,
Dave
On Wed, Jun 27, 2018 at 3:41 PM wrote:
> Dear podling,
>
> This email was sent by an automated system on beha
Hey All,
It looks like our next release will be 3.0. In preparation for planning the
release, I would like to see who is interested in being our next release
manager. This role includes creating the 3.0 branch, merging PRs to the
branch, creating release candidates, following open issues that affe
17 matches
Mail list logo
