+1 for #1 On Wed, Nov 13, 2019 at 2:09 PM Hoppal, Michael <[email protected]> wrote:
> Yeah, after thinking about it I'll agree with having a separate branch on > the repo is probably not the best place. Then we have to worry about > keeping that in sync with master (unless we only just have experimental > code in there and has a different git history then I would be +1 on it) > > That said so I propose we do one of two things: > > 1. Have all experimental code underneath one directory and on occasion we > do a sync up as a community what is still be actively worked/want to leave > in there? > 2. Say no experimental code is allowed in the repo. If you are working on > a new feature it would live on your fork until a blueprint is agreed upon > and has community buy in (people can easily view/pull down the code if > needed). At that point we could even move it into an incubator directory on > master. > > Thoughts? > > Michael > > > On 11/13/19, 11:47 AM, "[email protected]" <[email protected]> wrote: > > Well just to clarify, by "work" I don't just mean "compiles and runs > and maybe passes its tests", I also meant "work with Traffic Control". > To go back to postgrest, the dockerfile is literally just: > > FROM ubuntu:15.10 > MAINTAINER [email protected] > > RUN apt-get install -y curl tar xz-utils postgresql-client > RUN curl -LO > > https://github.com/begriffs/postgrest/releases/download/v0.3.1.1/postgrest-0.3.1.1-ubuntu.tar.xz > RUN tar xf postgrest-0.3.1.1-ubuntu.tar.xz > > EXPOSE 9001 > ENTRYPOINT > > (yes that entrypoint is blank, I swear I copy/pasted correctly). It > actually just downloads and extracts Postgrest, so idk if it's fair to > say that > > > That Dockerfile isn't trivial to make > > It isn't *broken* but it doesn't really *work* in any sense I can see. > > As someone who still regularly works on something experimental I'm > obviously in favor of keeping stuff around but I truly don't see the > benefit of something so trivial that hasn't been worked on since 2016. > > With all that said, I'm not really opposed to keeping something like > that (all under /experimental, pls) so long as it doesn't cause any > problems for as long as someone finds it useful and it doesn't need to > be maintained. Just want to be clear that there really is someone who > truly finds it useful for some purpose. > > As far as branches I just worry that since it's already kinda hard to > get experimental stuff reviewed and merged when there's so much else to > do that sticking things in their own, usually out-of-date branch is > basically a death sentence to contributions. Especially if it's stuff > like plugins to TO. > > On Wed, 2019-11-13 at 10:29 -0700, Robert O Butts wrote: > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
