>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 was my assumption: the `experimental` branch should only ever have things in /experimental directory(s), so it never has git conflicts. +1 on a branch, where all commits are in some /experimental directory (at the root or not). I agree, -1 on a branch with code changes in prod dirs, that cause horribly painful merge conflicts. > 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? +1 > 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. -1. As before, I think experimental code in the repo is a big win for community, collaboration, transparency, openness, and inclusiveness. On Wed, Nov 13, 2019 at 2:09 PM Hoppal, Michael <michael_hop...@comcast.com> 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, "ocket8...@gmail.com" <ocket8...@gmail.com> 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 dev@trafficcontrol.apache.org > > 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 < > > michael_hop...@comcast.com> > > 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" <r...@apache.org> 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 <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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
