e are at 108 of 240 endpoints.
> > > > >>
> > > > >> >if we do not treat the tests as first class citizens (meaning we
> > > > implement
> > > > >> an Go endpoint and build coverage as we go), then why bother at all?
> > >
nd build coverage as we go), then why bother at all?
> > > >> It doesn't have to be all or nothing. There's a happy medium between
> > > >> requiring tests for every line of code, and having no tests.
> > > >>
> > > >> >I also thought that we were suppo
y bother at all?
> > >> It doesn't have to be all or nothing. There's a happy medium between
> > >> requiring tests for every line of code, and having no tests.
> > >>
> > >> >I also thought that we were supporting removing the Perl in
we were supporting removing the Perl in the next TC
> 3.0 major release (several emails back).
> That vote was to remove the Perl GUI, not all of Perl.
>
>
> >Removing dead Perl code can be tricky, since the interdependencies are
> not always obvious, and can lead to unforeseen m
and having no tests.
> >>
> >> >I also thought that we were supporting removing the Perl in the next TC
> >> 3.0 major release (several emails back).
> >> That vote was to remove the Perl GUI, not all of Perl.
> >>
> >>
> >> >Remov
Perl in the next TC
>> 3.0 major release (several emails back).
>> That vote was to remove the Perl GUI, not all of Perl.
>>
>>
>> >Removing dead Perl code can be tricky, since the interdependencies are
>> not always obvious, and can lead to unforeseen missin
g the Perl in the next TC
> 3.0 major release (several emails back).
> That vote was to remove the Perl GUI, not all of Perl.
>
>
> >Removing dead Perl code can be tricky, since the interdependencies are
> not always obvious, and can lead to unforeseen missing functionality.
>
erl GUI, not all of Perl.
>Removing dead Perl code can be tricky, since the interdependencies are
not always obvious, and can lead to unforeseen missing functionality.
That's a good point. But let me ask this: in the event we miss some dynamic
Perl calling a function that was removed, which is w
I'm +100 on removing dead Perl code as long as we have 100% feature
complete with the Go code (which I think we're fairly close?). Rawlin you
are correct in that there is a spider web of interdependencies in Perl, but
without feature parity removing any of that dead code is like pullin
HTTP calls (which you
> > suggest in #1). That covers the endpoint no matter how it's implemented.
> >
> > Removing dead Perl code can be tricky, since the interdependencies are
> not
> > always obvious, and can lead to unforeseen missing functionality. TO
> uses
&
est in #1). That covers the endpoint no matter how it's implemented.
>
> Removing dead Perl code can be tricky, since the interdependencies are not
> always obvious, and can lead to unforeseen missing functionality. TO uses
> dynamic addition of methods to objects. The Mojolici
I'm all for #3. In fact, the `traffic_ops/testing/api` framework that
Dewayne has developed encourages testing from the HTTP calls (which you
suggest in #1). That covers the endpoint no matter how it's implemented.
Removing dead Perl code can be tricky, since the interdependenci
+1 on removing dead code.
IMO the danger and cost of the dead code far outweighs the benefit of the
Perl tests. Especially considering AFAIK most of the tests are just
verifying the response is a 200, not actually checking the body or database
or validating anything.
We just had someone in the co
#1 is pretty hard / not feasible. I believe Dewayne already looked into that
#2 sounds hard and probably work that would just be wasted imo
#3 i like this idea. let's pretend we have 100 API tests in perl. rewrite
all 100 to Go, delete the perl tests entirely. this is also a good idea
because it pr
Hey Traffic Controllers,
In order to accelerate our progress toward using and developing
traffic_ops_golang as a community, I'd like to propose that we remove
all of the dead Perl Traffic Ops API code in the repo. Many endpoints
have been rewritten in Go at this point, and by keeping the obsolete
15 matches
Mail list logo
