and soon some more pieces). In the top 20, I see around 10 people
associated with OCaml Labs working on opam-repository.
a very different job from fixing packages on a daily basis. The task of
doing on his spare time using opam-builder).
support when code signing lands (as it requires a quorum among committers).
with these engineers. I had the feeling that such a solution is easier for
many companies, compared to contracting OCamlPro to do such a task (i.e.
company).
Post by Anil MadhavapeddyThe top 4 out of 6 contributors to opam-repository work at Docker
according to the GitHub states [1], and we spend a significant amount of
time maintaining the general coherence of the repository and responding to
PRs, and working on CI infrastructure for OPAM (depext, ocaml-ci-scripts,
and soon some more pieces). In the top 20, I see around 10 people
associated with OCaml Labs working on opam-repository.
Did you have a concrete suggestion in your below mail for other
contributors? In general we should make it easier for power users to
contribute to the OPAM repository, as we will have an increased burden of
support when code signing lands (as it requires a quorum among committers).
[1] https://github.com/ocaml/opam-repository/graphs/contributors
Anil
On 30 Sep 2016, at 10:10, 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 ?).
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
Post by David AllsoppPerhaps 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?
Post by David AllsoppMaybe 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.)
Post by David AllsoppOn Tue, Sep 27, 2016 at 4:48 AM, Thomas Gazagnaire <
Post by David AllsoppPost by Daniel BünzliNowadays I consider it a lost cause when I file an issue on the
opam-
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlirepository.
I think this is an issue.
I perfectly understand that from the point of view of repo
maintainers the
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliamount of issues (136 now) doesn't entice them to go through the
backlog
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlito try to fix or close them. However I believe that if we try to
limit the
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlibacklog or tag them more appropriately there may be a better chance
that
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliissues do not simply get ignored.
https://github.com/ocaml/opam-
repository/issues?q=is%3Aopen+is%3Aissue+sort%3Aupdated-asc
1. Kill that `request for package` tag. Being a developer-oriented
package
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlisystem 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
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliwhen 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.
Post by David AllsoppPost by David AllsoppAgreed - 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).
Post by David AllsoppPost by David AllsoppIf 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).
Post by David AllsoppPost by David AllsoppFinally, 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.
Post by David AllsoppPost by David AllsoppIt 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...
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzli4. There seem to be a lot of old install glitches that I'm sure are
no
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlilonger 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
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliare unclear tag them with `scheduled for closure` and comment that
without
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliany further feedback in 7 days, the issue will be closed. Also in
general
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzliit would be nice to introduce tags to distinguish between repo
organisation issues like [1] (may be long lived) and end-user repo
install
Post by David AllsoppPost by David AllsoppPost by Daniel Bünzlifailures 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?
Post by David AllsoppI 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.
Post by David AllsoppThomas
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform
_______________________________________________
Platform mailing list
http://lists.ocaml.org/listinfo/platform
