-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make this repo public #9
Comments
This might be achievable once RMI-PACTA/archive.pacta.data.preparation#321 is resolved. |
With RMI-PACTA/archive.pacta.data.preparation#335 and RMI-PACTA/archive.pacta.data.preparation#336 closed, and RMI-PACTA/archive.pacta.data.preparation#338 waiting on merge, it's probably time to revive this thread 🥳 |
yup! I'd appreciate thorough consideration of this from @AlexAxthelm and @jdhoffa now that (I think) we've gotten rid of any proprietary FactSet stuff. I guess a show of consensus here in this issue is adequate, after which I'll flip the switch in the settings. |
Well, given that the FacSet data will forever live in the git history, I guess "flipping the switch" isn't really an option? Unless you scrub the history? @AlexAxthelm thoughts? |
true.... sorry, I should have said that my memory of previous conversations was that we were already keeping this private out of an abundance of caution, but the possibly sensitive data from FactSet was actually very minimal and not too big of a concern, and therefore we thought just getting it off but also willing to go the "proper" route if that is what is currently preferred |
Yes, I also agree that the data LIKELY is fine to be public, and we are being very cautious. I just wanted to make it clear that if we set the setting to public, we are still exposing that dataset, so we need to ensure we are comfortable with that. Personally, I am comfortable with that 👍 |
Thanks for making it explicit in this conversation |
To be clear about the options (and summarize prior discussions about similar repos):
Of these the first is the simplest, but does leave the pesky sensitive history available to anyone who wants to inspect. The last option is potentially attractive because most of the history is still available, but would still break any commit-specific references (links, tags can be retagged) since all the SHAs would change (and any signed commits become unsigned, but we don't worry too much about that) I might be overly cautious, but I'm inclined to go with the second option, and put the current state in cc @hodie for input. |
A glorious tech review topic! |
Additional note,
So we could pick up where we left off and have a clear point of connection between the two repos (we might have done this last time, I can't recall) |
To me the history (both commit history and issues/PRs) is important and very useful. I recognize that other things are also important here, but want to make sure that the importance of the history is acknowledged here too. |
I have added a Tech Review topic (to be filled in) here I would suggest we discuss and decide there, so this doesn't just float around with no decision :-) |
@AlexAxthelm I'm more interested in getting this done than saving the commit history and issues/PRs... can you help do the "hard fork" process? |
Sure. The repo is ready? Steps I'll take:
|
great, thanks! we should also transfer all the current issues... would it be feasible to leave |
added to my list. |
In a discussion with @cjyetman we decided that this process should occur after scenario preparation is public. |
@jdhoffa I think I'm ready to pull the trigger on this. maybe we can do it together? or? I'd like to:
|
Closed by the existence of this repo |
if this lands first, that should put a fire under this https://github.com/RMI-PACTA/pacta.scenario.preparation/issues/123
this will facilitate RMI-PACTA/workflow.data.preparation#102
AB#10435
The text was updated successfully, but these errors were encountered: