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

Implement an action that lists forgerelease dates older than x #871

Open
zilchms opened this issue Jan 30, 2024 · 2 comments
Open

Implement an action that lists forgerelease dates older than x #871

zilchms opened this issue Jan 30, 2024 · 2 comments

Comments

@zilchms
Copy link
Contributor

zilchms commented Jan 30, 2024

I dont know if this is the right module for this.

In addition to the recent ci task printing a summary report of all modulesync versions that havent been patched into their corresponding modules yet, we could use a task that allows us to find stale modules / modules which havent had a release in a long time.

A cutoff point could possibly be something like last-released: 2 years ago.
If we have modules that havent had a release in that long time, we may have a stale module (candidate for archiving) or something else is broken/needs fixing (which would be good to know about). Thoughts on this?

@bastelfreak
Copy link
Member

Hi!
We started with https://github.com/voxpupuli/vox-pupuli-tasks?tab=readme-ov-file#vox-pupuli-tasks---the-webapp-for-community-management some time ago, a Ruby on Rails application that's a registered GitHub App. That means GitHub sends us events and we can act upon them. For example new issues, new modules, new PRs, new comments, changed CI status. Based on that we want to inform people that they need to rebase their module or configure appropriate labels to a module. I still think this is a very good approach based it's event based but I currently lack the time to develop on it. I would love it if someone else could take it over (how much do you know about rails? :D). If we don't find volunteers for it we should look for alternatives and modulesync_config could be an okay place (check the /bin/ dir). The get_all_diffs script was also the starting point for our vox-pupuli-tasks application. And modulesync_config already has manual actions that scans our modules: https://github.com/voxpupuli/modulesync_config/blob/master/.github/workflows/main.yml#L23-L49

@zilchms
Copy link
Contributor Author

zilchms commented Jan 30, 2024

Regarding Rails: I dont know much about it yet, but I am willing to learn. I dont know if I could maintain and further develop voxpupuli tasks, since I am switching company and move away from puppet in that regard. Doesnt mean I wont be a part of voxpupuli anymore, I just dont have a clear view of how everything plays out ^^ But for the next 3-4 months at least I can pour some time into tasks and see where that leads :)

Edit: Ok, just had a quick look at it and especially at https://voxpupu.li/. Big fan, will work on it :D

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