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. > > > > > > > >
