You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Which of those things do we really need? We've done fine without them so far. While some of the things listed here are not expensive (unlike Slack), I'm worried about the extra work required to keep all those things up-to-date (change user permission, update passwords, update Credit card information, sing-off purchases, classify items for financial reports).
So, I think we should focus on items that save us work such as hosting services or CI pipelines that are less flaky, don't time out as often, don't change their configuration that often etc.
If there are things which will make developing easier/faster, I think we should pay for them and try to figure out the admin costs/overheads. We have a team 1Password for keeping track of passwords and credit card info. And we're gonna need an admin for lots of things (see #24), so this would be something they would be responsible for.
From an ethical perspective, I'd feel most compelled to pay for readthedocs and travis (for the former, especially if it comes with not having any ads shown even for those rare few without ad blocking). I'd feel bad about paying any money to microsoft or google; I think as a free software project, we should have some preference towards similarly community spirit driven services.
Purely from a practical perspective, github itself has become quite slow, not sure if that is partially to push people to paid services, or if one can pay for spiffiness.
While I think that it is useful to pay companies for their services, I would like to throw in another argument: Astropy is one of the major players nowadays, and the influence we can have on the companies is not negleglibe.
If we just pay for a service, then we may be find, but all the smaller project still can't have it. If we try to convince companies that they should open up one or the other property for free (optimally: "free as in speech"), then others would benefit as well.
As an example, Debian is not willing to base their development on top of a non-free service, and so there were many discussions with the Gitlab people to release some formerly propertiary features to the community version.
Obviously, Astropy is in a different situation than Debian, but I would appreciate that before buying in somewhere, we should make an attemtp to free the features we want.
+1 for paying RTD as a community project they could really use the support (and I am sure astropy could use some improved build resources as well, or maybe access to the continuous documentation feature?)
-1 On paying for CI, there are so many free services I can't see how you can need to pay for any. (it would be more effective, imo, to pay someone to maintain the CI configs than pay for build time)
@bsipocz It depends. For example, for another project, I support macports. I just had a lot of mac users with install problems that all went away once I offered the package through macports. It's also not uncommon for projects to provide their own rpms etc. (e.g. blender offer two windows builds, a linux build and a Mac build, conda has plenty builds for conda, even though conda is also available through some distributions).
However, that discussion is beyond the scope of this issue. Unless there is a distribution method that we already support now or that we would like to support but that is just held up by not having AWS instances, then it goes here. If we want to support new distributions methods beyond what we do today (pypi, conda-forge), then that should go into a separate issue.
Agreed that this would not seem to be a reason for AWS - even though I'm super-happy with having most of linux covered by having .deb and .rpm made for us, I think our work should end at making sure pip install astropy works for cases where our dependencies can be installed as well (numpy, especially). Of course, we should not be in the way of anybody packaging for us, as it really helps to catch bugs!
exactly @mhvk! Others packaging for us is great, but taking up the burden of distributing it beyond the official channels doesn't seem a thing we should start doing (working closely with those packagers is another question, and in fact we already do that with Debian).
Astropy is big enough that it's part of big distros, including default anaconda, so I don't see strong case for rolling our own on AWS.
@migueldvb: What distributions are you thinking about?
My impression is that its typically quite a bit of work to set up, test, debug, and maintain the build scripts for any specific distribution. Unless we find people who are willing to do that and commit to doing it long term, it's not going to happen, even if we have ample AWS instances to run things on.
Looking at available astropy packages in Linux distributions, there are a
number of them that are not included in their respective official repositories.
In my recent experience there are good-quality Arch build scripts available for
astropy and astropy-affiliated packages in community-driven repositories that
allow to compile the packages. These packages will likely not make it to the
official project repositories any time soon so it could be useful to provide
latest versions as pre-built packages, for example for college students using
those platforms. I agree that probably I underestimated the time and effort
required for this task.
Shouldn't that be the job of the distributions? What other projects take up doing packaging themselves outside of the official support?
Mozilla builds and distributes several binary versions of firefox as a nixpkgs overlay. Some projects maintain build scripts for distribution in a free component of an enterprise product.
Looking at available astropy packages in Linux distributions, there are a
number of them that are not included in their respective official repositories.
In my recent experience there are good-quality Arch build scripts available for
astropy and astropy-affiliated packages in community-driven repositories that
allow to compile the packages. These packages will likely not make it to the
official project repositories any time soon so it could be useful to provide
latest versions as pre-built packages, for example for college students using
those platforms. I agree that probably I underestimated the time and effort
required for this task.
I can speak here only for Debian (Ubuntu+Mint+Raspbian take their package from there too): The major effort with "official" packages is their continuous maintenance. If someone volunteers to do that for an affiliated package, it is IMO worth to also include their effort into the "official" distribution. At least for Debian, I would welcome and
support that.
Mozilla builds and distributes several binary versions of firefox as a nixpkgs overlay.
Mozilla and Sublime are IMO a bit different from our case since they traditionally don't fit very well into the traditional distributions and require either quite a few patches (Mozilla), or packaging gazillions of dependencies, or are not suitable by their license (sublime).
In contrast, Astropy really cares about the needs of distributions.
for example for college students using those platforms
Astropy currently provides ways for these students, or in fact almost anyone (with the possible exception of folks using super exotic hardware, but I'm sure they then have issue with getting numpy, too) to use the library with two rather standard and generic way, via pip or conda. I still fail to see how the distro packaging is a task/responsibility for the project to maintain and provide infrastructural resources for, rather than task for the distributions.
Can I politely ask to continue the discussion "Should be support more ways of distribution" in a different issue, if any more discussion is needed?
It's not something we want to be paying for right now (as the discussion above has made clear), so it's not part of "subscriptions we want to start paying for" (the title of this issue).
A quick note here: it seems like there's pretty universal agreement we should be supporting readthedocs, so the interim finance committee will be working on that ASAP. Other stuff still needs convergence it seems like.
"is currently providing" might be a little misleading. STScI offered to do it but more things need to happen before it is possible. astropy/astropy-data#91 is still unresolved. 🤷
Amazon is a big corporation too and they are even worse than other corps when it comes to supporting OSS. Also S3 can catch your wallet off-guard if you are not careful.
yup, lost $5000 credit once and got overcharged $1500 once. No dead-man-switch
Activity
astrofrog commentedon Oct 22, 2019
I’m not sure about slack, it’s going to be pretty expensive at $8/user/month (we have 500+ users?).
We might want to consider paying for readthedocs to support them.
kelle commentedon Oct 31, 2019
kelle commentedon Oct 31, 2019
from pllim: Paying for service to host astropy data mirrors. Maybe a Linode or DigitalOcean.
astrofrog commentedon Oct 31, 2019
Something we don't have to do but just an idea: astropy.org email addresses + gmail apps
hamogu commentedon Dec 20, 2019
Which of those things do we really need? We've done fine without them so far. While some of the things listed here are not expensive (unlike Slack), I'm worried about the extra work required to keep all those things up-to-date (change user permission, update passwords, update Credit card information, sing-off purchases, classify items for financial reports).
hamogu commentedon Dec 20, 2019
So, I think we should focus on items that save us work such as hosting services or CI pipelines that are less flaky, don't time out as often, don't change their configuration that often etc.
kelle commentedon Dec 20, 2019
If there are things which will make developing easier/faster, I think we should pay for them and try to figure out the admin costs/overheads. We have a team 1Password for keeping track of passwords and credit card info. And we're gonna need an admin for lots of things (see #24), so this would be something they would be responsible for.
mhvk commentedon Mar 20, 2020
From an ethical perspective, I'd feel most compelled to pay for readthedocs and travis (for the former, especially if it comes with not having any ads shown even for those rare few without ad blocking). I'd feel bad about paying any money to microsoft or google; I think as a free software project, we should have some preference towards similarly community spirit driven services.
Purely from a practical perspective, github itself has become quite slow, not sure if that is partially to push people to paid services, or if one can pay for spiffiness.
pllim commentedon Mar 20, 2020
Is there a place where we can rank/vote these services?
kelle commentedon Mar 20, 2020
@pllim , just let us know your thoughts/votes/priorities in words! If you prefer, please feel free to email [email protected].
pllim commentedon Mar 20, 2020
I was just thinking would be nice to have the aggregated rankings public. Individual votes can be anonymous. 🤷♀
In terms of priorities, here are the ranked reasons from me:
I see the point by @mhvk about ethical reasons but if we really can use that paid feature, we can negotiate for Open Source discount/perks.
olebole commentedon Mar 22, 2020
While I think that it is useful to pay companies for their services, I would like to throw in another argument: Astropy is one of the major players nowadays, and the influence we can have on the companies is not negleglibe.
If we just pay for a service, then we may be find, but all the smaller project still can't have it. If we try to convince companies that they should open up one or the other property for free (optimally: "free as in speech"), then others would benefit as well.
As an example, Debian is not willing to base their development on top of a non-free service, and so there were many discussions with the Gitlab people to release some formerly propertiary features to the community version.
Obviously, Astropy is in a different situation than Debian, but I would appreciate that before buying in somewhere, we should make an attemtp to free the features we want.
Cadair commentedon Mar 23, 2020
+1 for paying RTD as a community project they could really use the support (and I am sure astropy could use some improved build resources as well, or maybe access to the continuous documentation feature?)
-1 On paying for CI, there are so many free services I can't see how you can need to pay for any. (it would be more effective, imo, to pay someone to maintain the CI configs than pay for build time)
14 remaining items
bsipocz commentedon Apr 15, 2020
Shouldn't that be the job of the distributions? What other projects take up doing packaging themselves outside of the official support?
hamogu commentedon Apr 15, 2020
@bsipocz It depends. For example, for another project, I support macports. I just had a lot of mac users with install problems that all went away once I offered the package through macports. It's also not uncommon for projects to provide their own rpms etc. (e.g. blender offer two windows builds, a linux build and a Mac build, conda has plenty builds for conda, even though conda is also available through some distributions).
However, that discussion is beyond the scope of this issue. Unless there is a distribution method that we already support now or that we would like to support but that is just held up by not having AWS instances, then it goes here. If we want to support new distributions methods beyond what we do today (pypi, conda-forge), then that should go into a separate issue.
mhvk commentedon Apr 16, 2020
Agreed that this would not seem to be a reason for AWS - even though I'm super-happy with having most of linux covered by having .deb and .rpm made for us, I think our work should end at making sure
pip install astropyworks for cases where our dependencies can be installed as well (numpy, especially). Of course, we should not be in the way of anybody packaging for us, as it really helps to catch bugs!bsipocz commentedon Apr 16, 2020
exactly @mhvk! Others packaging for us is great, but taking up the burden of distributing it beyond the official channels doesn't seem a thing we should start doing (working closely with those packagers is another question, and in fact we already do that with Debian).
Astropy is big enough that it's part of big distros, including default anaconda, so I don't see strong case for rolling our own on AWS.
migueldvb commentedon Apr 16, 2020
Looking at available astropy packages in Linux distributions, there are a
number of them that are not included in their respective official repositories.
In my recent experience there are good-quality Arch build scripts available for
astropy and astropy-affiliated packages in community-driven repositories that
allow to compile the packages. These packages will likely not make it to the
official project repositories any time soon so it could be useful to provide
latest versions as pre-built packages, for example for college students using
those platforms. I agree that probably I underestimated the time and effort
required for this task.
migueldvb commentedon Apr 16, 2020
Mozilla builds and distributes several binary versions of firefox as a nixpkgs overlay. Some projects maintain build scripts for distribution in a free component of an enterprise product.
olebole commentedon Apr 16, 2020
@migueldvb:
I can speak here only for Debian (Ubuntu+Mint+Raspbian take their package from there too): The major effort with "official" packages is their continuous maintenance. If someone volunteers to do that for an affiliated package, it is IMO worth to also include their effort into the "official" distribution. At least for Debian, I would welcome and
support that.
Mozilla and Sublime are IMO a bit different from our case since they traditionally don't fit very well into the traditional distributions and require either quite a few patches (Mozilla), or packaging gazillions of dependencies, or are not suitable by their license (sublime).
In contrast, Astropy really cares about the needs of distributions.
bsipocz commentedon Apr 16, 2020
Astropy currently provides ways for these students, or in fact almost anyone (with the possible exception of folks using super exotic hardware, but I'm sure they then have issue with getting numpy, too) to use the library with two rather standard and generic way, via pip or conda. I still fail to see how the distro packaging is a task/responsibility for the project to maintain and provide infrastructural resources for, rather than task for the distributions.
hamogu commentedon Apr 16, 2020
Can I politely ask to continue the discussion "Should be support more ways of distribution" in a different issue, if any more discussion is needed?
It's not something we want to be paying for right now (as the discussion above has made clear), so it's not part of "subscriptions we want to start paying for" (the title of this issue).
eteq commentedon Jun 1, 2020
A quick note here: it seems like there's pretty universal agreement we should be supporting readthedocs, so the interim finance committee will be working on that ASAP. Other stuff still needs convergence it seems like.
stscicrawford commentedon Jun 3, 2020
As a note, STScI is currently providing support for cloud storage and distribution of Astropy Data (astropy/astropy-data#91)
pllim commentedon Jun 3, 2020
"is currently providing" might be a little misleading. STScI offered to do it but more things need to happen before it is possible. astropy/astropy-data#91 is still unresolved. 🤷
kelle commentedon Jul 31, 2020
This was a very useful discussion! If there are any specific proposals/requests to buy/upgrade a subscription to something, please open a new issue.
teuben commentedon Mar 29, 2021
yup, lost $5000 credit once and got overcharged $1500 once. No dead-man-switch