Skip to content
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

Look into the possibility of decoupling this tool to be universal and public #58

Open
LTrestka opened this issue Feb 6, 2024 · 0 comments
Labels
future Issues that may be worked on in the future

Comments

@LTrestka
Copy link
Collaborator

LTrestka commented Feb 6, 2024

Since swagger files have a structured format, the question was brought up whether this tool can be generalized for use with other swagger based API's. This ticket is to look into the possibility of that.

Questions to answer:

  1. Can other swagger.json files be used with this?
    • Does json structure change frequently?
    • Is json versioning custom, or structured, what is the minimum version our tool supports - if any?
    • Would a change in json structure require significant changes to the src? (applies to 6 too)
    • Which of our existing flags always work, and which ones fail - sometimes/every time?
  2. What would be required in order to make this application universal?
    • What code changes are required?
    • What configuration details would be required?
  3. Is spack and pip sufficient for packaging, or do we want to package this for other tools too?
  4. Would releasing a public universal version of this require licensing or other compliance with swagger.io?

    "The Swagger Specification and all public tools under the swagger-api GitHub account are free to use and licensed under the Apache 2.0 License."

  5. If we move forward on this, should we utilize the Office of Partnerships and Technology Transfer (OPTT)? - a few questions they might be better able to answer:
    • If this tool is published on a public fermilab repo, would subsequent maintenance on it (or lack thereof) become a legal responsibility of FNAL?
    • If users devise a way to use this tool for malicious intent, would FNAL be liable for damages?
    • If one of the packages this tool uses is found to have a security vulnerability, what actions are required on our end (if any)?
      • Do we need to make a public statement?
      • Is there a required timeline to address such vulnerabilities?
    • If we do not make this tool universal and public on fermitools, can the maintainers of this repo make the changes necessary outside of work to make a universal public version of this tool on their personal repositories, and what legal actions (if any) would that entail?
  6. Do we have the resources to maintain this tool ourselves at a public level, do we want to allow external contribution?
    • What does maintenance look like?
    • Is there a demand?
    • Is there such a thing as "too much demand" in our case?
    • Do other repo's achieve the same functionality? does our tool achieve some functionality that others don't?

      eg.. safeguards/workflows

      • Does this functionality solve a problem big enough to justify moving forward?
  7. Does our tool help the community enough to justify our effort?
  8. Is our src in line with Software Engineering and Security Best Practices (ie.. would a public release of this make us look bad)?
  9. Is there anything I missed?
@LTrestka LTrestka added the future Issues that may be worked on in the future label Feb 6, 2024
@LTrestka LTrestka changed the title Decouple tool for public general use Look into the possibility of decoupling this tool for universal usage and public release Feb 6, 2024
@LTrestka LTrestka changed the title Look into the possibility of decoupling this tool for universal usage and public release Look into the possibility of decoupling this tool to be universal and public Feb 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future Issues that may be worked on in the future
Projects
None yet
Development

No branches or pull requests

1 participant