Dev #2
Dev #2
Conversation
update for drain result API change
update requirements.txt to use drain from github
|
we don't want to continue using drain from github master forever. I plan to make a v0.0.6 release for the lead model that works with the lead model and sticking to that. There is a milestone for it on github and its almost done. |
|
By the way, this is a little circuitous, I PR'ed these changes from a branch here in Is that really how we want to handle this going forward? I can just fetch your master directly after you've merged essentially making this a development fork of chicago. |
|
I couldn't figure out how to do it the "right way", but yeah this was ridiculous. I'm not sure of the best flow.
|
|
Which is the canonical repo?
_
Tom Schenk Jr.
Chief Data Officer
Department of Innovation and Technology
City of Chicago
(312) 744-2770
[email protected] | @ChicagoCDO
data.cityofchicago.org | opengrid.io | digital.cityofchicago.org | chicago.github.io | dev.cityofchicago.org
…________________________________
From: Gene Leynes <[email protected]>
Sent: Friday, November 17, 2017 4:52:45 PM
To: potash/lead-model
Cc: Schenk, Tom; Mention
Subject: Re: [potash/lead-model] Dev (#2)
I couldn't figure out how to do it the "right way", but yeah this was ridiculous. I'm not sure of the best flow.
On Nov 17, 2017, at 4:46 PM, Eric Potash <[email protected]<mailto:[email protected]>> wrote:
By the way, this is a little circuitous, I PR'ed these changes from a branch here in potash to chicago, you merged them into chicago, now you are making a PR back to potash.
Is that really how we want to handle this going forward? I can just fetch your master directly after you've merged essentially making this a development fork of chicago.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABU9xOswpPCLnyfAZKXMZV6b1pBx1KSVks5s3gyxgaJpZM4QitbT>.
________________________________
This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or copying of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#2 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ABkC0bIyMVqaT5EOTNoynisclCYKdzskks5s3g49gaJpZM4QitbT>.
________________________________
This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail (or the person responsible for delivering this document to the intended recipient), you are hereby notified that any dissemination, distribution, printing or copying of this e-mail, and any attachment thereto, is strictly prohibited. If you have received this e-mail in error, please respond to the individual sending the message, and permanently delete the original and any copy of any e-mail and printout thereof.
|
|
In my mind the Likewise, I'm not sure of the simplest workflow for adhering to our dev/master paradigm when working on a forked repo. |
|
By the way... a weird thing happened. I made these changes and committed them on Friday from the development server. On Monday the changes were not there and the runner wasn't working because the changes were not there. As soon as I did a git pull the changes were back and the runner started working again. I can't imagine how the script was reverted on the development server. @avishekrk and @potash didn't make changes, and the Unisys team said they didn't restore a backup or do anything to the server. |
Changes to be able to predict on new addresses that are in a geography combination that is new. * add outcome_where_expr argument to match drain missing outcome handling * tested and incorporated into workflows * include (block,ward,community) pieces in address dataset * use drain from github in requirements.txt * fix index * include ward * fix geographies
address-only model
fix max year
updates to
requirements.txtto pull drain from @potash's repositoryupdates to change
.result()to.resultAs we move to using @potash's version of drain officially, we should probably make sure that we have our own fork of @potash's version or at least a local copy
I'd like suggestions on how to proceed here from @avishekrk and/or @tomschenkjr