There have been a couple of informal get-togethers in Cambridge, and we're happy to host more of course.
However, in this instance what the opam-repository needs is fairly simple curation and labelling. Thomas has been working on a GitHub PR library that should be open sourced soon that will help us tag issues more automatically, so we can do a sweep through opam-repository when this is done. In general, the Debian philosophy elsewhere in the thread is correct -- we do not have the resources to be a user support channel, but should keep issues open that are real breakage that can be actioned in the repository. Thoughts on where feature requests should go are welcome... regards, Anil > On 27 Sep 2016, at 15:55, Gabriel Scherer <[email protected]> wrote: > > Perhaps what is needed is a somewhat tedious day with maintainers in the same > (virtual) place, so that (brief) discussions can take place immediately, to > control the backlog? > > Maybe for another time, but have opam-repository maintainers and contributors > considered having an actual get-together event? Given the current > distribution, Cambridge or London could be good starting points. (I'm > personally stuck on the wrong side of the Atlantic before January, but in > general terms I would consider attending such an event. There would also be > interesting discussions to be had regarding opam 2.0 migration and Conex.) > > On Tue, Sep 27, 2016 at 4:48 AM, Thomas Gazagnaire <[email protected]> > wrote: > >> 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: > >> > >> https://github.com/ocaml/opam- > >> repository/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc > >> > >> 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. > > > > Agreed - I was briefly involved with Git-for-Windows. I disliked hugely the > > way the principal maintainer runs that project, but one thing which was > > very impressive was his rapid triage of issues. For standard FAQ questions, > > "we" (i.e. a maintainer) should comment with the appropriate FAQ link > > (number 1 would be advice either to contact upstream or a pointer to the > > packaging instructions; number 2 would either link to the manual or a > > general FAQ to open an issue on the appropriate docs repository; etc.) and > > immediately *close* the issue. It doesn't prevent the poster from > > commenting a little further, but it removes a "pointless" issue from the > > list as quickly as possible. Also, if an issue was woefully lacking in > > required information, the issue was closed, rather than requesting further > > information and leaving it open. The OP can always re-open the issue having > > supplied further details (or start a fresh one). > > > > If your issue survives that process, his next stage was tag it and > > determine who was going to fix it - if it a maintainer volunteers, it's > > assigned; otherwise if you don't agree to fix it, it's closed at once > > (happens with feature requests more than bugs, obviously). > > > > Finally, about once a month, he'd go through old issues and ping them for > > status - and close anything which seemed not to be making progress. > > > > It seems to me that for opam-repository a ruthless model would work well! > > Or, as we can see, you can't see the wood for them trees... > > > >> 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). > > > > Perhaps what is needed is a somewhat tedious day with maintainers in the > > same (virtual) place, so that (brief) discussions can take place > > immediately, to control the backlog? > > I agree, I rarely look at the issue tracker and its current state makes me > quite sad (these two are maybe related). Any help to triage these issues > would be greatly appreciated. I will make a quick first scan to close the > obvious ones. > > Thomas > > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform > > _______________________________________________ > Platform mailing list > [email protected] > http://lists.ocaml.org/listinfo/platform _______________________________________________ Platform mailing list [email protected] http://lists.ocaml.org/listinfo/platform
