> I had to go through and fix up code that probably will never see the light of day.
Hm, that's undesirable. Is there any way we can exclude experimental directory(s) from linting and similar things? >I see no issue as a developer having a side repo or a branch I'd be +1 on putting them in a Branch, too, if that helps. Not a fan of the reduced visibility, but it still lets people demo things to the community. Maybe a single "experimental" branch with everything, so it doesn't clutter the list of branches? On Wed, Nov 13, 2019 at 10:24 AM Hoppal, Michael <[email protected]> wrote: > 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 day. > > I am on the opposite side of the spectrum. This experimental stuff is just > an open door to dump whatever you want into the repo that is already > bloated, hard to manage and understand. > > I see no issue as a developer having a side repo or a branch to show off > ideas before beginning to add it to the repo (for a feature that is going > to be included in the actual project) > > Now I know others probably don’t share that opinion so if that is the case > then we should agree all experimental code should go into one directory. > > Thanks, > > Michael > > > > On 11/13/19, 10:11 AM, "Robert O Butts" <[email protected]> wrote: > > 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 <[email protected]> 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 > > > <[email protected]> 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" <[email protected]> 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 < > > > > [email protected]> 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. > > > > > > > > > > > > > > > > > > > >
