Blog-plugin: Tag stable releases

[akien-mga]

It would be nice if you could tag stable releases in git for a better overview of the release history :)

[LukeTowers]

Closing as it has been over a month since any activity on this occurred.

[akien-mga]

Without even caring to discuss the proposal? With 213 issues in 3 years, it doesn't seem to me that you(*) are so overburdened that you can't give a decent answer to such an issue. And I do maintain quite a few open source projects with tens of thousands of issues, I know what issue triage means.

() *Edit: Of course I meant this as "the project", it's by no means intended as a personal "you".

[LukeTowers]

I'm going crazy with the Abandoned tag in order to prompt some movement with these issues. As it stands right now the core team is way too busy with everything to handle every single issue ourselves.

My solution to this is to poke people into actually taking on the issues that are important to them. If an issue isn't important to them anymore, then they won't do anything and everything will continue as it would have anyways. If it is still important to them, then this will act as a reminder that it still needs to be resolved and hopefully motivate people to try and dig deeper into the issue rather than just assume that the free support of an open source project will solve it for them.

If you could go more in depth with what you need and why exactly you need it, that would be appreciated. I mostly just closed this specific issue to see if the original author still cared about it enough to want to make anything happen.

@akien-mga Just a response to your comment on the number of issues: There are 4 core base October repositories (october, library, docs, installer). There are 19 RainLab repositories for October plugins and themes. There are ~213,000 installations with ~24,000 projects through the octobercms.com marketplace. There are ~900 developers/users on Slack alone that constantly are asking for help and support with their own projects and learning paths.

Any guesses as to what is supporting all of this? Exactly 3 core team members, all volunteering their time. It's not unreasonable for us to be unable to address every single thing that gets reported and to rely on the community to solve the issues that we can't get to.

[akien-mga]

If you could go more in depth with what you need and why exactly you need it, that would be appreciated. I mostly just closed this specific issue to see if the original author still cared about it enough to want to make anything happen.

Well it's not really for me to care about tagging git releases, as I can't do it. The command to do it is:

git checkout <commit hash>
git tag <version>
git push --tags

Or alternatively:

git tag <version> <commit hash>
git push --tags

It's fine with me if you don't care about tagging releases, users who care can git log updates/version.yaml and see when releases were made, it's just a good practice when maintaining software.

But I would have appreciated it being said instead of an automatic closing message hinting that I might have not done enough for this issue to be seen as relevant, when project maintainers never answered nor asked for more info.

Mass closing issues to keep them manageable is fine, but I'd advise to quickly check the issue title / OP before copy-pasting a message that might be quite out of place, like in this case. It would also have been a oneliner to write "We don't use git tags and don't think they're relevant to our project, but thanks anyway."

Any guesses as to what is supporting all of this? Exactly 3 core team members, all volunteering their time. It's not unreasonable for us to be unable to address every single thing that gets reported and to rely on the community to solve the issues that we can't get to.

I do acknowledge your work and the burden of maintaining so many projects, but this issue is exactly the kind that cannot be solved by the community, it requires push access to the repo to push tags.

If you do want a contribution, I can make a list of git commands to issue to get all tags made for the right commits.

At any rate, I rest my case, it's not a big deal, and sorry if I was grumpy before my morning coffee.

[LukeTowers]

I apologize for the brashness of the comment, I could do a better job explaining the purpose of the closing of the issue, which is really just to clear out issues that may no longer be relevant as these repositories haven't had all their issues looked for a while. I'll edit the saved reply to be more clear in that regards.

Given that you maintain large open source projects, do you have any advice you could provide to me in regards to being a maintainer for open source projects?

Also, nice to see that https://godotengine.org/ runs October :)

[akien-mga]

If I can share a bug triage good practice from my experience with the Mageia bugzilla: To avoid rubbing issue reporters the wrong way, the best method I know when doing mass triaging with copy pasting is:

• Paste a message in all inactive issues asking people if their issue is still reproducible or still relevant. Make it clear in that message that it's an automated message. It doesn't have to acknowledge reading and understanding the issue, instead it should make it clear that it's just a "bot" bumping the issue to let reporters do a bit more help. Quite often they might close the issue as it became invalid or they don't really care.

• One month later, you can check all those issues again (GitHub search is not super convenient, but it can do the job with date filters) and you can mass close all those with no new reply with another "stock message". Such message should also cater to the reporter's feelings (I know, it sucks, but issue triage is a very relational task), saying things like "If you thing that this issue is still relevant, please comment to ask for it to be reopened." (users can't reopen issues themselves once closed).

For those issues where reporters will have answered the initial "bump", you'll have to spend some more time on them trying to understand them and see how they can be addressed. Since it's likely not doable all at once while doing mass closing of the inactive issues, you can instead add a "needs triage" label or similar and ask your contributors to help with the effort.

So in clear:

• One stock message for "is this still relevant?"
• One stock message for "closing as inactive" a reasonable amount of time after the first "is this relevant?" message

In both cases, take some time writing the stock message to make sure that it will be received positively by issue reporters - they and you are on the same side, and you should make them understand that your asking for relevance (which might be a bit out of place on issues such as this one, where the relevance can be assessed in 5 s by reading the OP) and later closing is an effort to reduce the issue backlog to help contributors to focus on the still relevant ones.

Also, nice to see that https://godotengine.org/ runs October :)

Yes, we're very happy with it :) Thanks a lot for your work!

[LukeTowers]

Thanks for the advice! I'll take it to heart.

Getting back to your original issue, it's not a bad idea, but given that we haven't tagged any releases for any of the RainLab repositories, it would involve a bit of initial work to get everything up to speed. Perhaps I'll leave this open to get done one day when I'm particularly bored and have nothing to do :)

[akien-mga]

Getting back to your original issue, it's not a bad idea, but given that we haven't tagged any releases for any of the RainLab repositories, it would involve a bit of initial work to get everything up to speed. Perhaps I'll leave this open to get done one day when I'm particularly bored and have nothing to do :)

If your version numbers are always hardcoded in updates/version.yaml, it should be possible to make a list of versions and matching commit hashes with some git log updates/version.yaml and git show updates/version.yaml + grep magic. I could have a look at it for this repo if you want, and propose a script that extracts the relevant info and makes a list of git tag commands to issue.

[LukeTowers]

Sure, that would be helpful if you're willing to do it! Thanks!

[bennothommo]

We have started tagging the RainLab plugin releases for new versions, such as for the Pages and Builder plugins:

https://github.com/rainlab/pages-plugin/tags
https://github.com/rainlab/builder-plugin/tags

We will be intended to do this for any future releases of the RainLab plugins, and will look into a way of adding in the historical version tags as well.

[LukeTowers]

@petehalverson any updates on your command line wizardry for the above?

[petehalverson]

@LukeTowers I shared that via Slack a while ago on the #octodock channel. Looks like it was lost when the history was cleared. I can share again!

[petehalverson]

@bennothommo @LukeTowers https://gist.github.com/petehalverson/fcffb67deb65a3a6030e11410b8c4bd6

[bennothommo]

Thanks for that @petehalverson. I ended up attempting to write one a couple of weeks back (https://gist.github.com/bennothommo/fc9be262c1968199266f6239f0af2754) but not sure how well it works, so I'll give yours a go as well. :)