I'm a big proponent of letting in experimental stuff. It doesn't affect production, and it lets the whole community see the idea. There's no maintenance cost, they're not hurting anything.
>Well let me ask this: which of these - if any - work/still work today? AFAIK all of them, I'm not aware of any that depend on anything in master that would break them. Though I'm less familiar with the Qwilt stuff. >"Postgrest" in particular just seems to contain a Dockerfile that installs "postgrest". So it really doesn't prove much besides that postgres itself exists and runs. It proves it can work together with an API gateway that rewrites URLs. That Dockerfile isn't trivial to make. If someone were to say "We should use PostgREST, it can do these things and would look like this," someone can't actually test that and play with it, without doing that work themselves, without that Dockerfile. The alternative, is that people will have to self-host this stuff, making it more opaque and harder to show ideas to the community. >If moving all experimental things to the top-level experimental directory helps alleviate the maintenance cost by allowing us to effectively ignore that directory for all intents and purposes, then I think I can get on board with that approach to keeping experiments around. I don't object to that. I don't see the need, even within subdirectories, they still don't affect anything, and the subdirectory "experimental" is equally obvious. But I don't object. >That said, at what point should we declare an experiment too stagnated to keep in the repo? Do we still keep them around forever if they never "graduate" to production? I'd vote we periodically review them, like we're doing now. Overall, I see being lenient with merging and keeping experimental things as a way to be more open and transparent as a project. IMO we need to be more open, not less. This is one very tangible way--which doesn't cost us anything--that we as a project can be open, transparent, and inclusive of the community. On Wed, Nov 13, 2019 at 8:47 AM <ocket8...@gmail.com> wrote: > 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 installs "postgrest". So it really doesn't prove much > besides that postgres itself exists and runs. > > If someone has plans to expand on something or continue working on > something that's different, though. But if all we have is some limited > functionality that doesn't with our system in any special way and > nobody has any plans to do anything with it, then idk if I see the > point in keeping it around. > > On Tue, 2019-11-12 at 17:47 -0700, Rawlin Peters wrote: > > I'm definitely +1 on removing experimental code that has been > > superseded. I'm also +1 on removing experimental code that has > > stagnated and currently represents a maintenance cost that is not > > worth the benefit of keeping it in the repo. If it's not actively > > being worked on, there's not much benefit to keeping it in the repo, > > and like Michael said it will always be in the git history if it ever > > needs to be revived again. > > > > If moving all experimental things to the top-level experimental > > directory helps alleviate the maintenance cost by allowing us to > > effectively ignore that directory for all intents and purposes, then > > I > > think I can get on board with that approach to keeping experiments > > around. That said, at what point should we declare an experiment too > > stagnated to keep in the repo? Do we still keep them around forever > > if > > they never "graduate" to production? > > > > - Rawlin > > > > On Tue, Nov 12, 2019 at 1:09 PM Hoppal, Michael > > <michael_hop...@comcast.com> wrote: > > > Thanks for the background!!! > > > > > > I more lean towards removing code that is unmaintained / unused. > > > That and git would allow us to get it back if we ever did want to. > > > > > > The trafficcontrol repo is a MONSTER of a repo and it makes it very > > > confusing/daunting to anyone new coming in (I know first-hand). > > > > > > That being said if others agree not to remove those I would be fine > > > leaving them in there but suggest we move them to the other > > > experimental directory in the repository > > > https://github.com/apache/trafficcontrol/tree/master/experimental. > > > > > > On 11/12/19, 12:20 PM, "Robert O Butts" <r...@apache.org> wrote: > > > > > > infrastructure/test/api has been superseded by the TO API > > > Tests. > > > infrastructure/test/apitest has been superseded by the TO API > > > Tests. > > > infrastructure/test/ui/traffic_ops/traffic_ops_test.go has been > > > superseded > > > by the Portal Tests. > > > traffic_ops/client_tests has been superseded by the TO API > > > Tests, which > > > test the client (also, it's empty). > > > traffic_ops/experimental/ats_config has been superseded by the > > > atstccfg > > > Config Generator. > > > traffic_ops/experimental/server has been superseded by > > > traffic_ops_golang > > > > > > I wrote all of the above, and I'm +1 on removing them as > > > superseded. > > > (Though the fact that I wrote them shouldn't prevent someone > > > else from > > > claiming something as useful, if anyone thinks so.) > > > > > > traffic_ops/experimental/goto has been superseded by > > > traffic_ops_golang, +1 > > > to remove. > > > > > > traffic_ops/experimental/auth is an experimental auth > > > microservice for > > > TO/TC. It hasn't been superseded by anything. We probably > > > aren't going this > > > direction any time soon, but I'm still hesitant to remove it as > > > an > > > experimental PoC. > > > > > > traffic_ops/experimental/postgrest hasn't been directly > > > superseded by > > > anything. We chose to go the traffic_ops_golang route, but > > > PostgREST is > > > still a valid alternative, and maybe worth keeping the PoC > > > around. > > > > > > traffic_ops/experimental/traffic_ops_auth hasn't been > > > superseded by > > > anything in production; but it serves essentially the same > > > purpose as > > > traffic_ops/experimental/auth and it's much smaller. I'd be -0 > > > on removing > > > it. > > > > > > traffic_ops/experimental/url-rewriter-nginx hasn't been > > > superseded by > > > anything, and serves to complement > > > traffic_ops/experimental/postgrest as a > > > PoC for a particular way of doing TO. I'd kind of like to keep > > > it around, > > > for the same reason. > > > > > > traffic_ops/experimental/webfront is along the same > > > "microservices" lines > > > as traffic_ops_auth, url-rewriter-nginx, and postgrest. I'm +1 > > > on keeping > > > them around, as a PoC of a different way to do things. > > > > > > > > > On Tue, Nov 12, 2019 at 11:57 AM ocket 8888 < > > > ocket8...@gmail.com> wrote: > > > > > > > A PR was recently opened ( > > > > https://github.com/apache/trafficcontrol/pull/4095) > > > > to remove a bunch of cruft from the codebase, and it looks > > > fine to me but > > > > before merging I wanted to make sure nobody was using this > > > stuff. It mainly > > > > deals with some things under infrastructure/test, > > > traffic_ops/experimental, > > > > and some client testing cruft. Here's an abbreviated list (GH > > > will show you > > > > every file in a directory individually, I believe I've > > > collapsed it as much > > > > as I can) of everything being removed: > > > > > > > > - infrastructure/test/api/ > > > > - infrastructure/test/README.md > > > > - infrastructure/test/apitest/ > > > > - infrastructure/test/ui/ > > > > - infrastructure/test/environment.json > > > > - infrastructure/test/environment/ > > > > > > > > - traffic_ops/experimental/ > > > > > > > > - traffic_ops/client_tests/ > > > > > > > > - traffic_ops/testing/api/log/ > > > > - traffic_ops/testing/test/ > > > > > > > > note that a lot of those are directories. > > > > > > > > > > > >
