+1 on putting it in /experimental. IMO no one should be required to be responsible for experimental. I think we should be liberal about putting experimental things in the repo, under /experimental, which aren't necessarily complete or well-maintained. So people other than the author can see them, try them out, vote on whether they're useful, etc.
If at some point it becomes clear something in /experimental won't ever see production, we just remove it. No big deal. On Thu, Apr 11, 2019 at 10:08 AM Jeremy Mitchell <[email protected]> wrote: > If Brennan focuses TPv2 on the self-service things (delivery service, user > and tenant management), I think it would be his responsibility to ensure > that any new functionality added to TPv1 regarding those 3 things is also > added to his experimental TPv2. And once he starts adding other > functionality (cache group, server management, etc), his scope will > increase of the things he needs to keep an eye on. Then once TPv2 achieves > critical mass, we'll have to officially deprecate TPv1 and only add new > functionality to TPv2. So I don't see any double UI coding. At the rate we > are turning out TC releases, maybe TPv2 is ready for 4.x :) (or at least > the ds, user, tenant part) > > Jeremy > > On Thu, Apr 11, 2019 at 6:24 AM Eric Friedrich -X (efriedri - TRITON UK > BIDCO LIMITED c/o Alter Domus (UK) Limited -OBO at Cisco) > <[email protected]> wrote: > > > If there is a decision to keep a TPv2 in experimental state for a > somewhat > > long term (1-2 years), who will be responsible for maintaining features > > equal with the current TP? > > > > I don’t think its fair to ask contributors to write double the UI code. > > > > —Eric > > > > > > > On Apr 10, 2019, at 6:40 PM, Rawlin Peters <[email protected]> > > wrote: > > > > > > Yeah, I think this is just the nature of Javascript UI frameworks and > > > the pace at which they are advancing, but eventually we will have to > > > get off of AngularJS anyway since it will no longer be supported after > > > June 30, 2021: > > > https://blog.angular.io/stable-angularjs-and-long-term-support-7e077635ee9c > > . > > > > > > So maybe it makes the most sense to try to get ahead of that and > > > implement any significant new self-service features in TPv2 rather > > > than trying to tack self-service features onto the existing TP. At > > > least it seems like Angular 2+ (currently at 7 now) has some better > > > staying power and clear upgrade paths. > > > > > > - Rawlin > > > > > > On Wed, Apr 10, 2019 at 4:28 PM Fieck, Brennan > > > <[email protected]> wrote: > > >> > > >> They can be. There's no reason they can't. But the framework it's > built > > on is on life support, TS > JS, fragile dependencies etc. etc. > > >> > > >> But the upshot is that I believe the effort to support self service > > would be just as much work either way, but done this way we > > eliminate/mitigate those problems at the same time. > > >> ________________________________________ > > >> From: Eric Friedrich -X (efriedri - TRITON UK BIDCO LIMITED c/o Alter > > Domus (UK) Limited -OBO at Cisco) <[email protected]> > > >> Sent: Wednesday, April 10, 2019 3:55 PM > > >> To: [email protected] > > >> Subject: Re: [EXTERNAL] Traffic Portal Angular7 rewrite w/ > Self-Service > > >> > > >> Why can’t the form wizards and other self-service features be built > > into the existing AngularJS Traffic Portal code? > > >> > > >> —Eric > > >> > > >> > > >>> On Apr 10, 2019, at 5:01 PM, Jeremy Mitchell <[email protected]> > > wrote: > > >>> > > >>> I think I agree with Chris about just using the "experimental" folder > > as we > > >>> always have. Then it's pretty easy to look in there and see what's > > >>> "cooking": > > >>> > > >>> experimental > > >>> - traffic_router_golang > > >>> - traffic-portal-angular7 > > >>> - traffic_ops_ruby_on_rails (just kidding :) ) > > >>> > > >>> Now regarding TP and TPv2. At comcast, there are (or will be) 2 > > audiences > > >>> for TP: > > >>> > > >>> 1. Admin/ops type users > > >>> 2. self-service type users > > >>> > > >>> TP works well for #1 but not really for #2. The trick is to build a > UI > > that > > >>> works well for both OR have 2 distinct UIs. As developers, we don't > > like > > >>> the idea of 2 UIs as that sounds like double the UI work when > something > > >>> changes. > > >>> > > >>> So we could either: > > >>> > > >>> a. make TP (angularJS) more self-service friendly > > >>> b. create TPv2 (angular7) with self-service in mind (i.e. form > wizards > > and > > >>> such) and focus on ds, user and tenant management and then slowly > port > > the > > >>> rest of TP functionality into it > > >>> c. support 2 distinct UIs > > >>> > > >>> I think "b" makes sense and the effort can start (as many of our > > efforts > > >>> do) as "experimental" and if it gets legs maybe it does replace TP or > > maybe > > >>> it doesn't and it simply becomes a UI that you can use (or not use) > to > > >>> solve ds/user/tenant management in a simple/self-service type way. > > >>> > > >>> Jeremy > > >>> > > >>> On Wed, Apr 10, 2019 at 9:42 AM Chris Lemmons <[email protected]> > > wrote: > > >>> > > >>>>> Are we seriously considering totally re-writing another component? > > >>>> > > >>>> Depends how you count it. One of the most important parts of the > > >>>> previous re-write (still in progress) is the "separation of powers" > > >>>> that makes things like this relatively non-destructive and able to > be > > >>>> managed in parallel. I like experimental pokes into what the future > > >>>> might hold, like this one. I'm not totally sold, but the scope isn't > > >>>> crazy. It's mostly a UI on top of the existing API. > > >>>> > > >>>> Historically, experimental or alternate components have lived in the > > >>>> main branch, but the experimental folder. That lets them be part of > > >>>> the same process as the rest of the code, ensures code reviews as > they > > >>>> progress, and the CI will keep everything in license compliance. > > >>>> > > >>>> On Wed, Apr 10, 2019 at 9:26 AM Fieck, Brennan > > >>>> <[email protected]> wrote: > > >>>>> > > >>>>> Branching is fine with me, I doubt I have permission to create a > > branch > > >>>> myself, though. > > >>>>> > > >>>>> As an aside based on that: should `traffic_router_golang` also be > > moved > > >>>> to a branch? I think the branch idea is better than having an > > >>>> `experimental` directory. Or maybe that experiment is dead and > should > > just > > >>>> be removed instead? The last change was 10 months ago. > > >>>>> ________________________________________ > > >>>>> From: Gray, Jonathan <[email protected]> > > >>>>> Sent: Wednesday, April 10, 2019 9:09 AM > > >>>>> To: [email protected] > > >>>>> Subject: Re: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ > > >>>> Self-Service > > >>>>> > > >>>>> Instead of merging it into master, could we merge it to a feature > > branch > > >>>> like `experimental/TP.rewrite` if there is a desire for > collaborative > > >>>> efforts. This would allow changes to flow in without adding more > > code to > > >>>> our normal review processes and polluting the changelog with WIP > > until it's > > >>>> done and ready to be merged. As an additional bonus it provides a > > more > > >>>> stable development for the new work since you'd be choosing when to > > pay the > > >>>> merge costs of ongoing master changes. > > >>>>> > > >>>>> Jonathan G > > >>>>> > > >>>>> > > >>>>> On 4/10/19, 8:59 AM, "Fieck, Brennan" <[email protected]> > > >>>> wrote: > > >>>>> > > >>>>> I guess that depends what you mean by "we". I personally think > it's > > >>>> worthwhile, and I'll probably keep working on it until it reaches > > feature > > >>>> parity with the existing TP. > > >>>>> > > >>>>> I'm not saying development on the existing AngularJS-based TP > > should > > >>>> stop in the meantime, just that self-service be implemented > > separately in a > > >>>> more modern and flexible framework. Then - and only then - should we > > >>>> consider replacing the old TP with the new. Slowly, over time. The > > current > > >>>> TP was built for admins, so I don't think it'd actually be more work > > to > > >>>> implement a customer-facing interface this way than restructuring > the > > >>>> existing TP to support it. > > >>>>> ________________________________________ > > >>>>> From: Hank Beatty <[email protected]> > > >>>>> Sent: Wednesday, April 10, 2019 8:38 AM > > >>>>> To: [email protected] > > >>>>> Subject: [EXTERNAL] Re: Traffic Portal Angular7 rewrite w/ > > >>>> Self-Service > > >>>>> > > >>>>> Hello, > > >>>>> > > >>>>> Are we seriously considering totally re-writing another > component? > > >>>>> > > >>>>> -Hank > > >>>>> > > >>>>> On 4/5/19 12:09 PM, Fieck, Brennan wrote: > > >>>>>> Some of you may have heard, but about two and a half weeks ago I > > >>>> opened a Pull Request to add something to the `/experimental` > > directory. > > >>>> It's basically a re-implementation of Traffic Portal, which I think > is > > >>>> beneficial not only because Traffic Portal wasn't designed with > > >>>> self-service in mind, but also because it cleans up a few issues on > > the > > >>>> development side. First of all, it uses the most recent LTS version > of > > >>>> Angular, while the one on which Traffic Portal is currently based is > > now > > >>>> deprecated (this new version can also compile projects for Electron, > > which > > >>>> would make TP distributable as a standalone/mobile app). It also > uses > > >>>> Typescript which compiles more cleanly to an overall smaller > product, > > and > > >>>> is much easier to read, write and document. Remember the SCSS > compiler > > >>>> issues (compass) we keep having? Angular 7 comes with a compiler at > > project > > >>>> init, so we never need that as an externally-provided dependency > > again. > > >>>> Finally, it already has unit testing and end-to-end testing working > > in four > > >>>> different JS engines. > > >>>>>> > > >>>>>> > > >>>>>> I'm currently looking for a reviewer ( > > >>>> https://github.com/apache/trafficcontrol/pull/3419) and you can > read > > more > > >>>> about what's implemented there, but a short summary: > > >>>>>> > > >>>>>> > > >>>>>> * Login/authentication and API proxy > > >>>>>> * Delivery Service view with bandwidth charts > > >>>>>> * New Delivery Service creation targeted at self-service users > > >>>> with limited advanced editing options > > >>>>>> > > >>>>>> * User listing (read-only) > > >>>>>> > > >>>>>> * Preliminary HTTPS support (currently only listens on > 'localhost') > > >>>>>> > > >>>>>> > > >>>>>> Plus, if I do say so myself, it all looks pretty snappy on every > > >>>> screen I could test. > > >>>>>> > > >>>>>> > > >>>>>> Feedback is also appreciated, especially concerning the "New > > >>>> Delivery Service" form. > > >>>>>> > > >>>>> > > >>>>> > > >>>> > > >> > > > > >
