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

Should source bundle / tarball be published on github? #41

Open
matthijskooijman opened this issue May 11, 2020 · 6 comments
Open

Should source bundle / tarball be published on github? #41

matthijskooijman opened this issue May 11, 2020 · 6 comments

Comments

@matthijskooijman
Copy link
Contributor

The README refers to github releases for downloading released sources, but that only allows downloading an automatically generated git snapshot.

The generated source bundle is different (includes md5sums, maybe other differences too). This is uploaded to S3 for download through openttd.org (I think), but perhaps it should be uploaded as a release asset to github too?

See OpenTTD/nml#111 and OpenTTD/nml#113 for this same issue and the fix for nml.

@LordAro
Copy link
Member

LordAro commented Mar 22, 2021

What's wrong with the OGFX-source on cdn.openttd.org ? NML doesn't exist there, so it made sense to add it to the GH release (as well as pypi), but it doesn't need duplicating in this case, IMO

@matthijskooijman
Copy link
Contributor Author

What's wrong with the OGFX-source on cdn.openttd.org ?

Nothing, I guess, when it's properly documented. Looking at the README again, it does seem it references cdn.openttd.org, so that's actually fine. Maybe I created this issue in response to "or obtain the tarball from the release page" on "4.2 Obtaining the source", but reading that again it seems that that is in the context of contributing and development, where it makes some sense to just get a tarball of the git repo rather than a preprocessed release.

There's still the argument to have everything together here in GH, which might make it easier to find by just heading over to the releases page without combing through the README for the link, but it's also fine to leave as-is (so feel free to close this).

@TrueBrain
Copy link
Member

I kinda agree with you @matthijskooijman that it is pretty common to also distribute binaries etc on GH. People look there, and it is a bit frustrating to find it if you are known to the GH way of doing things.

This is the same for all our other projects btw; I guess mostly it requires someone figuring out how to publish files nicely to GH via our workflow :)

@matthijskooijman
Copy link
Contributor Author

This is the same for all our other projects btw; I guess mostly it requires someone figuring out how to publish files nicely to GH via our workflow :)

NML already does it (see commits linked above), not sure how easy that is to apply here, though.

@LordAro
Copy link
Member

LordAro commented Mar 23, 2021

It's not especially difficult to add it (I can basically copy the NML version), it's a question of whether we should add it

@TrueBrain
Copy link
Member

TrueBrain commented Mar 23, 2021

You are right @matthijskooijman , that works for OpenGFX and friends. When I tried this for OpenTTD, I ran into issues that the default action was too limited. But that shouldn't hold us back indeed :)

It's not especially difficult to add it (I can basically copy the NML version), it's a question of whether we should add it

In my opinion: yes. It is a very small effort for us, and it does confuse people. Especially as GitHub doesn't allow a "look here for binaries". The alternative is to add it to every release, where to find it, but that sounds like a lot of work to me :D I love automation!

Additionally, it means GitHub makes the cost, instead of us :D (cheapskate!)

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

3 participants