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

[Fabrice Le Fessant]

Maybe it would make sense for some heavy industrial users of OCaml to
devote one engineer part-time (one or two days a week, for example) to the
maintenance of the opam-repository ? There are already people from
different organizations contributing, but mostly on their spare time, so
they cannot really spend a lot of time understanding, for every broken
package, how to fix the problem. Having engineers, officially dedicated to
that task by their organizations, would help a lot. Do you think it would
be possible ? I think that the Haskell community as such an engineer
working full-time at maintaining the stability of one of their repositories
(Hackage ? Stackage ?).

On Thu, Sep 29, 2016 at 4:59 PM Anil Madhavapeddy <anil at recoil.org> wrote:

> 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 <gabriel.scherer at gmail.com>
> 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 <
> thomas at gazagnaire.org> 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
> > Platform at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/platform
> >
> > _______________________________________________
> > Platform mailing list
> > Platform at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/platform
>
> _______________________________________________
> Platform mailing list
> Platform at lists.ocaml.org
> http://lists.ocaml.org/listinfo/platform
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/platform/attachments/20160930/d6c3df6d/attachment.html>