I'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
wrote:
> @Robert Butts , there is a process to create
>
If we decide to get rid of the API versioning it makes sense to me that we
would do that on a major version upgrade, probably to the ATC version. But I
think it would be too early to do it on the 2.0 API version. I like this
compromise +1. I was wondering why we were stuck on the idea that 2.0
I'll bite. I'd like to start one for TP.
On Wed, Nov 13, 2019 at 2:50 PM David Neuman
wrote:
> @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
@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
+1 on Working Groups, the IETF also works by consensus, and WGs work very
well there.
They're particularly good for letting people subscribe to things they care
about, while ignoring things they don't. It'd be ideal if Apache will let
us make arbitrary mailing lists. Not sure if that's possible?
Agreed with Jeremy I would be +1 on both ideas.
On 11/13/19, 2:07 PM, "ocket " wrote:
well, I actually like Dave's suggestion better than my own
On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell
wrote:
> I like both of those ideas. Either a working group and someone
>Yeah, after thinking about it I'll agree with having a separate branch on
the repo is probably not the best place. Then we have to worry about
keeping that in sync with master (unless we only just have experimental
code in there and has a different git history then I would be +1 on it)
That was
+1 for #1
On Wed, Nov 13, 2019 at 2:09 PM Hoppal, Michael
wrote:
> Yeah, after thinking about it I'll agree with having a separate branch on
> the repo is probably not the best place. Then we have to worry about
> keeping that in sync with master (unless we only just have experimental
> code in
Yeah, after thinking about it I'll agree with having a separate branch on the
repo is probably not the best place. Then we have to worry about keeping that
in sync with master (unless we only just have experimental code in there and
has a different git history then I would be +1 on it)
That
well, I actually like Dave's suggestion better than my own
On Wed, Nov 13, 2019 at 1:40 PM Jeremy Mitchell
wrote:
> I like both of those ideas. Either a working group and someone volunteers
> to setup/lead the working group (ideally a committer or pmc member) or an
> RM at the component level
I like both of those ideas. Either a working group and someone volunteers
to setup/lead the working group (ideally a committer or pmc member) or an
RM at the component level to help manage issues, milestones, roadmaps, etc.
Jeremy
On Wed, Nov 13, 2019 at 12:27 PM Dave Neuman wrote:
> I agree
I agree with Rob and Jonathan on this one. I don't see a reason that
committers cannot already gravitate toward a component, and I want to avoid
adding any formal designation to community members outside of the defined
Apache ones (contributor, commiter, and pmc).
I think I would rather see us
Lemme lead with: making breaking changes on a major version boundary
gets +1 from me - no reason the API needs to be fully redesigned for
any particular number.
But I just gotta bring this up again: if we want to be able to
deprecate an endpoint for a major release and remove it in the next
Well just to clarify, by "work" I don't just mean "compiles and runs
and maybe passes its tests", I also meant "work with Traffic Control".
To go back to postgrest, the dockerfile is literally just:
FROM ubuntu:15.10
MAINTAINER dev@trafficcontrol.apache.org
RUN apt-get install -y
On Wed, 2019-11-13 at 10:57 -0700, Jeremy Mitchell wrote:
> Maybe component lead is not the right term?
>> ... hold the position for a defined amount of time ...
Since most of the responsibilities seem tied to releases, maybe we just
need sub-release-managers for the components? The main RM can
+1
That reminds me, we went through this same thing with cdn.conf. It
used to be a Perl hash, but we converted it to JSON a while back. I'm
pretty sure we provided a script to do that, but I'm not sure if it's
this one or not:
traffic_ops/app/bin/config2json
Possibly relevant PR:
Agreed Rob. I didn't mean to imply that these "component leads" would have
more power. Rather that they'd facilitate and lead discussions (on
standards or roadmaps or whatever), be a point of contact for a release
manager, and keep things generally tidy and transparent in regard to that
component.
FWIW one maintenance thing I just ran into with several experimental
directories is I couldn’t run golang lint or unit testing at the base of the
project as it was breaking it (several stuff didn’t even compile).
I had to go through and fix up code that probably will never see the light of
What does this allow us to do that can't already be done today? The main gain
I can think of is helping users find knowledgeable people (which could
volunteer themselves today as part of a collaborative and inclusive community).
There's not anything presently stopping individual committers
> It is a compromise - it's an inconvenience to users, forcing them to fix
scripts to upgrade. Which isn't good for user experience either; but it
doesn't outright break people. It's a compromise I'm willing to live with.
It will literally outright break clients (*all* of them, not just
*some*).
I think this is a GREAT idea!
I would very much be +1 on it.
I would add that the open source component leads would be voted on by the
community and only hold the position on a defined period of time.
On 11/13/19, 9:58 AM, "Jeremy Mitchell" wrote:
I would like to propose the idea of
I'm converting the `/osverions` Traffic Ops endpoint [0] from Perl to Go [1].
The Perl version of this endpoint reads a configuration file
and performs an `eval` of the contents [2]. The default location for this
config file is: /var/www/files/osversions.cfg.
As part of the conversion to Go,
Alright, I know it was over the weekend, but I'm gonna take my single
"+1" and run with it. The PR will still be open for review likely for
at least the rest of the day so if anyone still has concerns there's
still time.
Well let me ask this: which of these - if any - work/still work today?
Some of them have been described as "proof-of-concept"s which leads me
to believe that they wouldn't really do anything with a modern install
of Traffic Control. "Postgrest" in particular just seems to contain a
Dockerfile that
For the endpoints, I agree in part and disagree in part.
Agree for these two:
- the endpoints are dangerous and pose a risk to the overall Traffic
Control system
- the task of rewriting the endpoints from Perl to Go represents an
unreasonable amount of work for the project
And I would add:
- the
25 matches
Mail list logo
