I want to propose the deployment of Haunt for openHAB repositories like openhab2-addons.
Haunt helps you keep your github issues under control. It does this by allowing you to run unit tests against github issues and pull-requests, then make contextual decisions about closing, sorting, tagging, and commenting.
Check out the one example posted here. Possible use cases:
Check issues for inactivity
post a reminder after four weeks
post another reminder after eight weeks, mention 1-2 maintainers
close the issue after 12 weeks inactivity
Assign labels based on issue/pull request description content
For openhab2-addons: automatic assignment of binding-specific labels
Check pull request to be made from feature branches
Check pull requests for a description of a minimum length (if size of commit bigger than x)
Nice, at least it would keep us from forgetting oldish pull requests.
Could the PR then checked for mergeability / being rebased against master and if necessary a reminder posted that the original author should kindly rebase his work?
I would say it depends - if itās an enhancement, then I would say it should be. If the people doing the enhancement goes away, then it should be closed. If itās a bug, then it probably should be kept open.
Sounds like a nice tool, havenāt heard of it before.
What might be interesting is automatic assignment of issues to a maintainer of a specific binding - possibly combined with adding a label for a binding.
Regarding running unit tests on PRs, I am not sure how much this overlaps with the Cloudbees-PR builds that we are doing or with what Travis offers.
@hakan oldish pull requests as well as issues. Mergability and the need for rebase is checked by GitHub. I believe you are talking about posting an appropriate notification for the developer!? Iām not sure if Haunt can check for this property but itās probably possible. If we decide to use Haunt in the openHAB organization, we are free to implement these details step by step.
@Lolodomo@chris the above was just an example and closing is not the important action there. In the example, there would be two notifications before the issue is closed. After each notifications maintainers and the issue creator would be reminded to become active by either responding to open questions, by updating the status or by closing the ticket. If nobody reacts even after the second reminder, the ticket is obviously not worth being left open or we have a serious management problem
@Kai Haunt is the most promising I found and with itās scripting capabilities seems to be the most flexible. Automatic assignment of binding specific labels and/or developers is also what I thought would be a great improvement. The bot could also help make the most out of other labels like āWaiting for Infoā or āWaiting for Reviewā.
Regarding unit tests, I think you got the wrong idea. Itās supposed to check the ticket, NOT the code e.g. āIf a pull request is bigger than 10 lines of change, check for more than one line of commit message.ā or āIf issue contains āRelated to binding: sonosā assign label āSonosā and maintainer ābobā.ā
If you believe this idea is worth pursuing, I could look into this bot some time in the future. At first it doesnāt need any special permissions as he could start by just commenting. If any of you knows of better alternatives, possibly in the form of a web-service, please let me/us know.
I have to take one step back. The last commit in the original Haunt repository was done in 2012. There are forks with commits in 2016 but Iād have to reevaluate the fitness of these. This doesnāt change the fact, that tools like this exist and might be an option for openhab.
Hm, thatās a shame. This also has the risk that it isnāt compatible with todayās Github anymore. I hope you find something that is still maintained and workingā¦
@Kai Iāll still have to look into this to find the best option for the inactivity reminder and label assigning capabilities. Thereās an unexpected absence of these kinds of solutions. Iām a bit confused.
I found one solution that may however be an instant improvement. Check out mention-bot by Facebook. Itās an available bot you can use right away without self-hosting. The bot will mention fitting developers in PRs based on the blame history of the code area the PR is doing changes to. Quite clever if you ask me You wanna give it a try?
@Kai Iāve tested the mention-bot at openhabian: https://github.com/openhab/openhabian/pull/55
Besides the fact that with only three authors in total the algorithm of mention-bot can not really show itās wonders here, he seems to work and do what heās supposed to. Also remember that you can provide a configuration file for details. How about activating the hook at openhab2-addons ?
Pretty cool! Another nice find @ThomDietrich! It looks like people taking a holiday or a break from development can put mentionbot on their ignore list which is pretty simple!
@martinvw I didnāt find the time to actually test Haunt yet. I still think it offers the right amount of flexibility for the above mentioned use cases.
Another fork was last updated in 2016 and supposedly working. However turns out that the fork is also not continued.
From here on forward we have two options. We can look for another, active project or we can test and utilize Haunt from the zopaUK fork. While at it we could continue improving Haunt.
However to be honest, I do not have the time to work on such a project right now. Would you be interested to look into this?
I have to take one step back. The last commit in the original Haunt repository was done in 2012. There are forks with commits in 2016 but Iād have to reevaluate the fitness of these. This doesnāt change the fact, that tools like this exist and might be an option for openhab.
