They can also generate a “badge” which summarizes it (excluding outdated linux distrubutions):
It could be interesting to try to understand how those packages are maintained and whether we can do anything to help update them when a new version is released (although there is also an interest in keeping the releasing process simple on our side). Also it would obviously be great to be packaged in more repositories.
Yes, he is still maintaining the package, but that does not mean he is updating it immediately as we get new releases out. We do update (and even add) dependencies often (such as the language detection package), so those need to be updated as well.
In the last contributor call, it was mentioned (by an Outreachy applicant, sorry that I do not remember who) that the installation process of OpenRefine on Windows is quite unusual and confusing.
We did not get a single response for this call - perhaps it was too intimidating, not publicized enough, not published at the right time - I don’t know! So we tried a different approach, adding bounties on issues using the IssueHunt platform. We did this for a Mac packaging issue and someone picked it up and solved it nicely.
So given that this experience was positive I would propose we do the same on some Windows packaging issues too. I would propose that we first tackle the generation of an installer wizard (#3224), which should be relatively straightforward. Then we could add another bounty on the signing issue (#3003). The other issues seem less suitable for bounties: #3057 is blocked by a change in Launch4j and #3221 seems to have a different scale (probably too much work for a bounty).
I would propose to put something like $500 on the generation of an installer wizard (#3224). I would do it when the Outreachy contribution phase ends because the activity on the repository is intense enough already, and it would perhaps be a nice opportunity for an Outreachy applicant to have a go at this if they are not selected for an internship.
We could then follow-up with $250 on the signing issue, perhaps. We would buy a signing certificate via CS&S separately (the bounty hunter would do the integration work with a self-signed one for testing purposes).
It makes sense to add bounty on those issues. I think it doesn’t hurt to open the two bounties together. We can redirect to your message here to explain how we see the sequence of actions.
The thing about those two bounties is that the work overlaps (for instance, I don’t know if we want to sign the openrefine.exe or the setup .exe). Intuitively it is more strategic to put a bounty on an issue when it is ready to be worked on immediately - otherwise we’ll have to tell people to check back later and we might lose interest in the pipeline.
@Martin would you be okay for adding a first bounty on the installer task? I would say this can be done already, since the Outreachy contribution phase is over and the repository has become quieter.
bounty posted on