RFE: is it possible to start making github releases?🤔

[kloczek]

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)

[rgommers]

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.

[dnicolodi]

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.

[kloczek]

No each ti,e I'm opening this manually,
I'm using copy od some template (it make sense to wrote that one tome and change on;y ULR rime to time improving text).
It is a bit pity that instead thinking about own project and reaching over as much as possible channels you are focusing on me.
I've politely askes using "please" word.

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 ..

[martindurant]

https://www.howtogeek.com/devops/how-to-automatically-publish-github-releases-from-git-tags/ ?

[kloczek]

Yep 👍 that is as well valid instruction how to add propagate GH release over GH actions/workflows 😋

[eli-schwartz]

@rgommers

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:

If it was just about opening this same request to duplicate PyPI "releases artifacts" on python projects that are already:

• releasing on PyPI
• publishing git tags to make all github machinery other than "custom email notifications settings for releases specifically" work flawlessly

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 make man in order to report that "the dist tarballs don't include the doc directory so you cannot enter it and run make man", which apparently requires 250 lines to report. After being told that the project in question started splitting out prebuilt docs into a separate documentation tarball, he decided to litigate that and... apparently recommend they abort their recent switch from raw handcrafted GNU Makefiles to cmake, and go start a new complex migration to meson. While I clearly do think Meson is a great build system, I don't think we need that sort of advertisement...

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 -W flags passed to gcc are not understood by, I quote:

using CC=<static_code_analyser_or_autitin_tool> make which do not recognise many gcc warning options. If you need to have proper view of some compile time warnings please use only on CI something like "CFLAGS="-Wfoo -Wbar "./configure ` instead hardcoding all that crap straight into the code which other people may find as completely useless

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:

Why it should be doing that if on many projects which are not trying to solve famine problem on Earth using build framework ItJustWorks™️? 🤔

Totally not insulting or anything! Everyone I know calls -W compiler flags "trying to solve famine problem on Earth using build framework"! /s

...

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 -- -specs=/usr/lib/rpm/redhat/redhat-hardened-ld, we get things like mesonbuild/meson#11338 where it turns out he is running meson's maintainer targets for update-po, which on a handful of projects fail to run at all -- and he wants meson to automatically run this on meson dist just to "verify" that if a maintainer runs it, it will succeed.

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 meson dist (including updating a timestamp regardless of whether the file has meaningful changes).

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.

[eli-schwartz]

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. ;)

[kloczek]

then I'd agree with you this is borderline abusive behavior.

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.

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.
I promise that I'l try to do that BetterWay™️,

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).
Some people even wrote some small doc about how to automate more things like autogenerate changelog
jbms/sphinx-immaterial#281 (comment)
Oher thing is that MOST of the maintainers already generates gh release even without additional comments .. just empty gh release (Subject of the generated email automatically contains new release string).

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.
No one will be harmed.

[eli-schwartz]

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.
I promise that I'l try to do that BetterWay™️,

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:

• https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ a service run by Fedora which is custom designed to do this all for you and is intentionally cross platform, with APIs like the ones that Fedora's flagship automation for opening bugzilla tickets uses.
• nvchecker, a program for conveniently defining upstream projects based on sources such as GitHub or PyPI or custom urls, which can use the GitHub API or the PyPI API or git ls-remote or downloading an HTML page and regex scraping it, normalizes all data, and outputs a list of names and versions for updates that you have not yet marked as having processed
• repology.org collects information about every package in lots of Linux distros (and a few other sources like PyPI) and tells you all about which different versions are available and where. If any Linux distro has packaged the new version then it will show up here. Please mind their bulk API usage policy.

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

[kloczek]

You should not be asking projects to do this, period, end of story.

Rhetoric question: because?

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".

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

[tkloczko@pers-jacek SPECS]$ grep "VCS:.*https://github.com" *spec | wc -l; ls -1 *spec |wc -l
3007
4682

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.
This week was a two-day outage on sf.net. After that, I noticed that a few maintainers decided to move to github. So now from those 4.6k projects on sf.net VCS has only

[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%.

[tkloczko@pers-jacek SPECS]$ grep VCS: *spec -l | wc -l; ls -1 *spec |wc -l
4295
4682

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.
Because such projects are real MINORITY I've decided to start asking to add for example ONE LINE GH action modification.

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).
Some people even started adding their notes for example adding notes on how to autogenerate changelog
jbms/sphinx-immaterial#281 (comment)

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 ..
The proposition can be refused and no one will be hurt.

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.

[dnicolodi]

Rhetoric question: because?

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?

[kloczek]

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

Just short note about what Debian is using for +2 decades.
Things are changing and in meantime it is not necessary to use that methodology and/or it is possible use something waaay simpler. Sometimes it is no longer even possible to use that.
Currently more and more projects no longer publishes dist tar balls in some exact/predictable http/https/ftp locations.
All because gthub/gitlab offers signing assets on git tags so in such case autogenerated from git tag archive can be verified against maintainers public key.

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.

[eli-schwartz]

The total number of projects without any VCS is also in constant decline and it is now less than 10%.

I agree!!!

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 totally disagree! I specifically said that you should be using nvchecker, which tracks git tags, not GitHub releases.

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.

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.

[eli-schwartz]

I have no idea what you know about real distros .. I have been working on different distributions for almost two decades.

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.

[kloczek]

With rpm I've started at the time when it was written in per (RH 2.0.2).
For quite long time I've been contributing to RHCN. At the end of RHCN about 30% of all publicly submitted packages where mine. For example I wrote first rpm spec which have been producing .more than one binary package
You can firnd on the botom of the https://src.fedoraproject.org/rpms/lesstif/blob/b064920e5cc7d577bd3d6c8cf007d9c0836b5128/f/lesstif.spec that it was in 1997.
Than it was PLD.
I'm still maintaining few packages in Fedora.
Now I'm working on my own distribution which uses rpm and portable to OpenSolaris as well (rpm spec files are used to build Solaris IPS specific packages).

[rgommers]

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 invalid. On SciPy 3/4 of your issues are closed as invalid. On NumPy all your 6 issues have been closed as reject/invalid/duplicate or user error. Your contributions take too much time, and are draining without contributing much to the state of the projects - not a single issue out of the 12 you opened on these packages (which I all maintain) resulted in a PR/fix. Please reconsider your behavior and be more careful about opening issues in this repo and across other Python packages.

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.

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.

[rgommers]

I'll lock this conversation here.