-
Notifications
You must be signed in to change notification settings - Fork 65
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
RFE: is it possible to start making github releases?🤔 #484
Comments
You already asked this and received an answer on commit 10aec50. Please don't ask the same question twice, and especially not without cross-linking. Also, opening this same request on all Python open source projects you can find borders on abusive behavior. I know you are doing some really esoteric packaging and it's a big job, but transferring your workload on open source maintainers is inappropriate: ![]() Again, please implement PyPI monitoring instead. It's not hard. I have already pointed you at RSS feeds for this. |
I probably took more time to automate opening the same identical issue on all these project than to implement PyPI monitoring. I wonder what is the strategy for projects that are not on Github. |
No each ti,e I'm opening this manually, I can tell you that most od the maintainers of the repositories added ONE line modifications to GH workflow to generate GH release understanding that it may help with something .. |
Yep 👍 that is as well valid instruction how to add propagate GH release over GH actions/workflows 😋 |
If it was just about opening this same request to duplicate PyPI "releases artifacts" on python projects that are already:
then I'd agree with you this is borderline abusive behavior. But it's not borderline abusive behavior, simply abusive behavior, because this person tends to pick the most bizarre fights on all kinds of topics. Here's an especially bewildering one: OSGeo/gdal#5778 (comment) Quick summary: the original bug report was a 250-line error trace from running But then the thread became derailed by some other weird litigation about a massive patchset he has against the problem, which is some sort of weird grievance I don't understand. The reason for the patchset is because some
He insists on his right to use a static analyzer wrapper when building rpm packages, even though that makes no sense unless he's submitting patches to fix those issues and even then it doesn't belong in the rpm packaging, but is using a bad static analyzer that doesn't understand the compiler it's faking itself as. And this is not his problem, it's the project's problem!! Because:
Totally not insulting or anything! Everyone I know calls ... Meson has had a whole bunch of reports: https://github.com/mesonbuild/meson/issues?q=author%3Akloczek Most of them are not high quality, but are argumentative. If we ignore the repeated reports of meson's testsuite failing that cannot be reproduced, one of which is a duplicate of a binutils bug report he submitted against the sourceware bugzilla, and most/all of which seem to be usually caused by some highly questionable "hardening" wrapper -- The real issue of course has nothing to do with meson dist, but rather the fact that some projects left their translations support to bitrot and no one ever touches it and all the translations are out of date and no longer applicable. For this, meson should re-edit your git-committed *.po files every time you run I can come up with more examples of @kloczek's behavior, but I don't really feel like investing my time, energy, and mental well-being into this topic. The gdal ticket is high-quality abuse enough for a whole cottage industry of abusive behavior. |
That being said, there is precisely one interesting thing about Github Releases which meson-python could benefit from, which most PyPI projects probably cannot, and that is independently supporting release artifact types which PyPI long ago hid so well that most people didn't know it existed, and recently deleted all support for: PGP signatures. meson-python does sign the git tags, it is presumably feasible to sign the sdists and upload them to both github and PyPI. I would not bother nagging projects that don't have PGP set up to begin with, and it's not something I want to harp on, but I just want to note once, quickly, that if you did choose to do it, it would provide something that PyPI does not provide. Meson itself does this, although in our case we also upload PyInstaller built MSI installers for Windows, and a macOS *.pkg, so it is clearly well worth our time to upload various release assets there, and not much burden to also do the sdist. ;) |
If you see any other way to ask add one line patch in github action if someone already is using gh actions/workflows to spread notifications other way than doing tis one by on I'm always opened on how to do that without be accused for abusive behaviour. So far MAJORITY of the maintainers which I've asked just done that because they've been happy that they've opened yet another channel of propagation information about new reassess of they project(s). Refuse or treating such RFE as abusive so far was exception. If you don't have time/you are busy/do't car/whatever else reason just please close such ticket. |
You should not be asking projects to do this, period, end of story. Real distros run by professional distro maintainers do not do this, and in fact they can't because many projects are not on GitHub at all, not to mention the fact that getting a personal email doesn't allow operating a status page listing "all out of date projects". Your problem is not representative of Linux distros, so asking thousands of projects to do something that only one person benefits from is pretty wasteful. That doesn't mean projects can't use GitHub Releases if they want to -- but it does mean that your reason for nagging projects to care about the difference is wrong and has a detrimental effect on the time of maintainers who have to stop doing important things like fix bugs and ask features so they can tell you "no". There's no '"better way" to ask for something that you should not want and maintainers shouldn't have to do. ... If you are serious about getting notifications when packages are out of date, please use a sensible, same, reliable, extensible approach that supports many websites, not just GitHub. Use one of:
There are other methods for release monitoring, this is just a few off the top of my head. None of them need projects to change what they do. Some distros have a per package file describing what http resource to access to detect updates, see for example https://wiki.debian.org/debian/watch |
Rhetoric question: because?
I have no idea what you know about real distros .. I have been working on different distributions for almost two decades. Here is a longer context of why I've decided to start raising such RFEs
Another ~15% are maintained in different running gitlab-based locations. A little more than 1% are CVS?SVN/HG based. Everything else that is not on githib/gilabs is exposed over different cgit interfaces or other rarely used. sf.net is in constant decline. Even some projects initially maintained on https://savannah.gnu.org/ are moving away because they are not offering cross-information mentioning of some commits. [tkloczko@pers-jacek SPECS]$ grep "VCS:.*sf.net" *spec
matio.spec:VCS: https://sf.net/p/matio/matio/
netpbm.spec:VCS: https://sf.net/p/netpbm/
xmlrpc-c.spec:VCS: https://sf.net/p/xmlrpc-c/code/ The total number of projects without any VCS is also in constant decline and it is now less than 10%.
And .. amongst those projects which are maintained on github only a handful are not generating github releases (so far I've raised only about 50 RFEs like this one). I've not done that by scripting (which you can check) because every 3-5 such RFEs I'm improving template text doing each RFE MANUALLY. I think that already after ~2 weeks almost all of those RFEs have been closed with positive effects. So far feedback on those RFEs is mostly positive (most of the people didn't know that they could open yet another channel of spreading inflammation about the project's new releases). One of those projects which are not using gh releases is meson. Period .. You may not like such RFEs (that is your right) but above are RAW facts which you can only ignore or accept (I have nothing to do with those facts). And again .. I'm not demanding anything. I'm only politely (as much as I can) asking .. PS. FYI: I've collecting the above data metrics in zabbix in the last +3 years. So in my case I'm not guessing about trends .. EOT. |
How would you feel is someone would file an issue with your project asking you to implement monitoring of releases happening on PyPI instead than only using Github notifications because it makes his life as Python package maintainer easier? Why is your request to multiple projects more sensible than this request? |
Just short note about what Debian is using for +2 decades. Processing ONLY gh/gl for some exact projects releases has some advantage because some maintainers are adding VCS tags which should not be used for production. By producing gh/gl releases it is possible automatically advertise some dist assets as useable for prod. |
I agree!!!
I totally disagree! I specifically said that you should be using nvchecker, which tracks git tags, not GitHub releases.
Bogus. What tags are these that shouldn't be used for production? Presumably tags that say "rc1" or something, which... nvchecker can filter for you. Or use release-monitoring.org which has a robust suite of mechanisms for distinguishing production and not-production releases, which big companies are maintaining already, and is free for you to use and improve. |
Aside: I'm curious, which distro? You've mentioned some sort of personal rpm based distro before, IIRC, but it was really unclear whether that distro was publicly available or even what it's called. |
With rpm I've started at the time when it was written in per (RH 2.0.2). |
I propose we stop this here, since this discussion is not productive. @kloczek this is your second issue here, the first one was also closed and labeled
Thank you @eli-schwartz, that is a good point. I'll consider this for the next release, which shouldn't take too long to appear I expect, given the level of activity right now. |
I'll lock this conversation here. |
Is it possible next time on release new version make the github release to have entry on https://github.com/mesonbuild/meson-python/releases? 🤔
I'm only asking because on the creation of a new GH release a notification is spread to all those whom have set in the web UI Watch->Releases.
My automation process uses those notifications by trying to make preliminary automated upgrades of building packages, which allows saving some time on maintaining packaging procedures.
More about gh releases is possible to find on
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
https://github.com/marketplace/actions/github-release
https://pgjones.dev/blog/trusted-plublishing-2023/
ESSS/pytest-regressions@bcd06142
jbms/sphinx-immaterial#281 (comment)
The text was updated successfully, but these errors were encountered: