+1
On Thu, Apr 6, 2017 at 7:43 AM, David Neuman <[email protected]> wrote: > Since the Cookie Jar functionality is new to 2.0 and 2.0 is not yet > released, why don't we just remove the `ResumeSession` method all together > and eliminate the dependency? Otherwise we are deprecating something that > we never formally released. > > On Tue, Apr 4, 2017 at 2:30 PM, Robert Butts <[email protected]> > wrote: > >> Regarding `TC-119: traffic_ops/client dependency license issue`: >> >> It looks like the persistent cookie jar is only needed by Traffic Ops >> Client `ResumeSession(toURL string, insecure bool) (*Session, error)`. >> Nothing in Traffic Control uses `ResumeSession`, and I doubt anyone else is >> using it. Because it returns an error, and persisted cookies have >> lifetimes, any current users already must handle errors from persisted >> cookies being expired. Thus, we can change it to always return an error >> with only degraded performance (and not much, login is cheap), without loss >> of functionality. >> >> To fix TC-119, I propose we document `ResumeSession` as deprecated, and >> change it to always return an error, which lets us remove the dependency, >> without the development cost of writing our own persistent cookie store >> that no one is using. >> >> Any objections? >> >> >> On Tue, Apr 4, 2017 at 1:35 PM, Jeremy Mitchell <[email protected]> >> wrote: >> >> > These all got fixed and backported to 2.0: >> > >> > TC-203: Mojo doesn’t set cachable headers on public files” >> > TC-190: TTL type mismatch in CrConfig >> > TC-189: ssl_multicert.config too slow >> > >> > So Jan and Dave just need to close the issues. >> > >> > On Tue, Apr 4, 2017 at 12:22 PM, Jeffrey Martin <[email protected] >> > >> > wrote: >> > >> > > Hi Eric, >> > > I was going to address the immediate Postinstall issues TC-185. I am >> way >> > > late on this. I created a fork yesterday, need to run a couple of tests >> > and >> > > then I can push to this fork. >> > > Jeff Martin >> > > >> > > >> > > On Tue, Apr 4, 2017 at 1:59 PM, Eric Friedrich (efriedri) < >> > > [email protected]> wrote: >> > > >> > > > We have some release blockers for 2.0. Specifically: >> > > > >> > > > TC-119: traffic_ops/client dependency license issue >> > > > We cannot ship with Category-X LGPL software, so I’m waiting for >> > this >> > > > to be resolved before cutting a release branch >> > > > "TC-185 post install doesn’t run due to missing perl module” >> > > > We shouldn’t ship a release in which the install process is >> broken >> > in >> > > > this way. >> > > > *There’s no assignee yet for this, any volunteers?* >> > > > >> > > > I think if we can get those two taken care of we can cut an RC0 later >> > > this >> > > > week. >> > > > >> > > > Major bugs we will ship with (unless someone objects): >> > > > TC-203: Mojo doesn’t set cachable headers on public files” >> > > > TC-190: TTL type mismatch in CrConfig >> > > > TC-189: ssl_multicert.config too slow >> > > > >> > > > —Eric >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > > On Apr 4, 2017, at 1:13 PM, Dave Neuman <[email protected]> wrote: >> > > > > >> > > > > Good question. I would also like to see us try to get some release >> > > > > candidates out for 2.0. I am pretty sure the actual install and >> > > > > postinstall need work. There are also a couple of issue that are >> > still >> > > > > assigned to 2.0 and unresolved: >> > > > > https://issues.apache.org/jira/browse/TC/fixforversion/ >> > > > 12338562/?selectedTab=com.atlassian.jira.jira-projects- >> > > > plugin:version-summary-panel >> > > > > . >> > > > > >> > > > > On Tue, Apr 4, 2017 at 11:05 AM, Jan van Doorn <[email protected]> >> > > wrote: >> > > > > >> > > > >> When are we planning to release 2.0? We at Comcast are running >> what >> > we >> > > > >> call 2.0…. So we are +1, I am pretty sure. >> > > > >> >> > > > >> Eric: are you waiting for something? Which cats need herding? >> > > > >> >> > > > >> Rgds, >> > > > >> JvD >> > > > >> >> > > > >> >> > > > >> > > > >> > > >> > >>
