[ocaml-platform] Improving the opam-repository issue tracker

Daniel Bünzli daniel.buenzli at erratique.ch
Tue Sep 27 03:08:22 BST 2016


Nowadays I consider it a lost cause when I file an issue on the opam-repository. 

I think this is an issue.

I perfectly understand that from the point of view of repo maintainers the amount of issues (136 now) doesn't entice them to go through the backlog to try to fix or close them. However I believe that if we try to limit the backlog or tag them more appropriately there may be a better chance that issues do not simply get ignored.

Going through the least recently updated issues: 


here are a few things that come to mind: 

1. Kill that `request for package` tag. Being a developer-oriented package system I don't think the opam repository is the place to ask for packaging, people should ask upstream (I don't say this didn't make sense when opam was a baby). 
2. Kill too open ended questions with the `question` tag. 
3. Go through the `bug` tag. It seems a lot of old things can be closed. 
4. There seem to be a lot of old install glitches that I'm sure are no longer relevant.
5. There are a few open issues where people say that the problem is solved, they should be closed...

I think we should walk up from the oldest issues and whenever things are are unclear tag them with `scheduled for closure` and comment that without any further feedback in 7 days, the issue will be closed. Also in general it would be nice to introduce tags to distinguish between repo organisation issues like [1] (may be long lived) and end-user repo install failures like [2] (should be short lived).


[1] https://github.com/ocaml/opam-repository/issues/6864
[2] https://github.com/ocaml/opam-repository/issues/7448

More information about the Platform mailing list