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

Document process for servicing a package addition request #2936

Open
yuvipanda opened this issue Oct 27, 2021 · 5 comments
Open

Document process for servicing a package addition request #2936

yuvipanda opened this issue Oct 27, 2021 · 5 comments

Comments

@yuvipanda
Copy link
Contributor

We should more thoroughly document the process for how admins can service a package addition request. This will show us places where we can streamline our operations to make sure they can be done as quickly as possible.

@yuvipanda
Copy link
Contributor Author

For python packages,

Step 1: Figure out how complex it will be

(Assuming #2934 is done)

  1. Is the package available on conda-forge? If so, this should be a fairly simple addition. This is the primary advantage of doing Install most packages from conda-forge, instead of pypi #2934 - it'll make most packages, especially ones that have binary components, be a lot simpler to install.
  2. If not, is the package available on PyPI and is it a pure python package? If so, that is also a fairly simple addition.
  3. If not, this is not necessarily a simple addition, as apt packages might be needed. I expect 99% of python packages to be 'simple additions' though.

Make a quick determination of wether the package is expected to be a simple addition or not, and leave a comment acknowledging this. Communication with the requestor is important here, and something we should have an SLA for. Ideally, this would also mention how long we expect to take to service this.

Step 2: Make a PR just adding the package

Add the package to the appropriate environment.yml file, and let the PR run its course. I think for simple package additions, we can just merge and deploy them after tests pass - no need to explicitly test them in staging. I think complex package installations need more testing and tweaking.

@yuvipanda
Copy link
Contributor Author

For R packages,

Step 1: Figure out how complex it will be

(Assuming #2934 is done)

  1. Is the package available on packagemanager.rstudio.com/? You can find the list of apt packages it requires in the page for the packag - are these already installed? If so, this is a fairly simple addition.
  2. If not, is the package on GitHub? In that case it might be a simple or complex addition, unclear :)

Make a quick determination of wether the package is expected to be a simple addition or not, and leave a comment acknowledging this. Communication with the requestor is important here, and something we should have an SLA for. Ideally, this would also mention how long we expect to take to service this.

Step 2: Make a PR just adding the package

Add the package to the appropriate file in the appropriate hub image. This needs to be properly structured - currently, the file names are a bit scattered across various images.

@yuvipanda
Copy link
Contributor Author

I think another important thing to figure out is just timelines - sometimes the packages are needed in two days, sometimes in two weeks. We should prioritize and respond accordingly as well.

@yuvipanda
Copy link
Contributor Author

Some amount of normalizing the structure of our image directories will also help a lot here I think. I want it to be super clear where exactly a new package will need to be added.

@balajialg
Copy link
Contributor

balajialg commented Oct 27, 2021

@yuvipanda Thanks for breaking down the package addition complexities. This gives me a useful framework to think about some of the package requests that we get and the kind of communication that needs to be shared.

Any package addition request gets assigned to @felder and me currently. As a process, if @felder is available then I would let him respond from a package addition and SLA standpoint as he is thorough in his communication with the teaching team, Felder will escalate issues to Yuvi as and when required! If @felder is unavailable (taking a day off), I will respond to the package request, and if it looks like a simple request (as outlined by @yuvipanda) that is also time-sensitive I will create the required PR. If not I will acknowledge the package request and highlight the SLA we had defined for package requests earlier. Sharing that below for your reference,

SLA for package installation: “Acknowledgement within two working days.”

SLA for RAM increase: “Acknowledgement within two working days.”

SLA for admin access: “Request completed within two working days.”

SLA for data archival request: “Request completed within three working days.”

https://ds-modules.github.io/curriculum-guide/faq/onboarding.html?highlight=sla

@felder @yuvipanda Let me know if that works for you all.

Just to confirm, for Python, we are looking at making edits to environment.yml file and for R, we are looking at making edits to install. R? Is that right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants