You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficcontrol.apache.org by ocket 8888 <oc...@gmail.com> on 2019/11/12 18:56:52 UTC
Removing old cruft
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.
Re: [EXTERNAL] Re: Removing old cruft
Posted by Rawlin Peters <ra...@apache.org>.
+1 on keeping all *active* experiments in the same, top-level
"experimental" directory. It sounds like we have consensus on that
much at least, and the topic of which experiments currently in the
repo should be considered "inactive" and removed will be carried on in
their own future threads.
- Rawlin
On Wed, Nov 13, 2019 at 2:16 PM Robert O Butts <ro...@apache.org> 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 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 <Mi...@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, "ocket8888@gmail.com" <oc...@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_Hoppal@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" <ro...@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 <oc...@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
> > > > > > <Mi...@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" <ro...@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 <
> > > > > > > ocket8888@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.
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> >
> >
> >
Re: [EXTERNAL] Re: Removing old cruft
Posted by Robert O Butts <ro...@apache.org>.
>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 <Mi...@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, "ocket8888@gmail.com" <oc...@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_Hoppal@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" <ro...@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 <oc...@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
> > > > > <Mi...@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" <ro...@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 <
> > > > > > ocket8888@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.
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by ocket 8888 <oc...@gmail.com>.
+1 for #1
On Wed, Nov 13, 2019 at 2:09 PM Hoppal, Michael <Mi...@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, "ocket8888@gmail.com" <oc...@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_Hoppal@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" <ro...@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 <oc...@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
> > > > > <Mi...@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" <ro...@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 <
> > > > > > ocket8888@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.
> > > > > > >
> > > > > >
> > > > > >
> > > >
> > > >
> > >
> > >
> > >
>
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
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, "ocket8888@gmail.com" <oc...@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_Hoppal@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" <ro...@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 <oc...@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
> > > > <Mi...@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" <ro...@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 <
> > > > > ocket8888@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.
> > > > > >
> > > > >
> > > > >
> > >
> > >
> >
> >
> >
Re: [EXTERNAL] Re: Removing old cruft
Posted by oc...@gmail.com.
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_Hoppal@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" <ro...@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 <oc...@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
> > > > <Mi...@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" <ro...@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 <
> > > > > ocket8888@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.
> > > > > >
> > > > >
> > > > >
> > >
> > >
> >
> >
> >
Re: [EXTERNAL] Re: Removing old cruft
Posted by Robert O Butts <ro...@apache.org>.
> 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 <Mi...@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" <ro...@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 <oc...@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
> > > <Mi...@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" <ro...@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 <
> > > > ocket8888@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.
> > > > >
> > > >
> > > >
> >
> >
>
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
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" <ro...@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 <oc...@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
> > <Mi...@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" <ro...@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 <
> > > ocket8888@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.
> > > >
> > >
> > >
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by Robert O Butts <ro...@apache.org>.
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 <oc...@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
> > <Mi...@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" <ro...@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 <
> > > ocket8888@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.
> > > >
> > >
> > >
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by oc...@gmail.com.
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
> <Mi...@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" <ro...@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 <
> > ocket8888@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.
> > >
> >
> >
Re: [EXTERNAL] Re: Removing old cruft
Posted by Rawlin Peters <ra...@apache.org>.
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
<Mi...@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" <ro...@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 <oc...@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.
> >
>
>
Re: [EXTERNAL] Re: Removing old cruft
Posted by "Hoppal, Michael" <Mi...@comcast.com>.
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" <ro...@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 <oc...@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.
>
Re: Removing old cruft
Posted by Robert O Butts <ro...@apache.org>.
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 <oc...@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.
>