I am not convinced by the argument that "it works for Debian"; Debian has had a fair bit of heated maintainership conflicts in the past, and this is one of the reason why they now insist on having multiple co-maintainers. Debian is successful as a distribution, but the localized conflicts have alienated some communities (see for example https://lwn.net/Articles/496335/ ), and nobody knows whether a more flexible package ownership policy would have worked better or worse.
There are several different kinds of changes to a package, and it makes sense to let different people handle them. Of course nobody is suggesting that opam-repo maintainers should add arbitrary patches on top of some software to implement new features. Here are two kind of changes where external involvement may help: (1) Changes in global packaging policies that are orthogonal to any particular packages. When I changed around 3000 packages to add an "ocamlbuild" dependency, I couldn't possibly have contacted each specific maintainer and waited for each of them to do the change. (Under the future security infrastructure I suppose the change would have required the signature of one of the trusted repo maintainers; it was reviewed and approved by them so the process wouldn't have been very different.) Not only would have it required considerable work on my side, it would also have guaranteed an inconsistent ecosystem with some packages depending on ocamlbuild and some others not depending on it. (In the case of this transition this is ok, but in some other transient states may be unacceptable.) (2) Changes in external configurations that affect some systems that the maintainer is not particularly familiar with. In software distributions, Debian maintainers do Debian-specific patches to make changes to respect their local policity, and OpenBSD people fix configure scripts that assume too many GNUisms. Following your reasoning, this would be unacceptable and that they should always wait for upstream to merge their patches. I think the current system of "local change + notification for eventual upstreaming" works better. (Sometimes it goes wrong, eg. Debian maintainer breaking random number generation for a stylistic reason. There is no objective definition of which changes are acceptable locally and which must require upstream's approval, and people have to use their best judgment.) The opam-repository thread that spawned the present discussion is https://github.com/ocaml/opam-repository/pull/5338 I think that empowering Nix users to make the necessary opam-repository change to have good support for OCaml inside Nix(OS) is the right thing to do, instead of requiring the contributor to send dozens of emails to people they don't know, which can be enough of a requirement to discourage them from any further contribution. On Mon, Feb 22, 2016 at 8:15 AM, Fabrice Le Fessant <fabrice.le_fess...@ocamlpro.com> wrote: > Dear Jeremy, > > On Mon, Feb 22, 2016 at 11:39 AM Jeremy Yallop <yal...@gmail.com> wrote: >> >> Is it fair to say that your concerns are primarily about notification >> rather than permission? > > > No, it is about permission. When I publish something on the OPAM repository, > I take some responsability for it. I don't want anybody else to mess with my > packages, and then discover problems that either I could have discovered > much earlier if I had been contacted immediately, or either caused by a > maintainer that didn't know how to fix a problem I had caused. Am I the only > one to care about that ? > >> >> The problem isn't that people are modifying >> other people's packages, but that the original maintainers aren't >> always notified. > > > As I replied to Thomas, would you like Github to modify the source code of > your application they are hosting, and just add an issue in your BTS to tell > you afterwards ? > >> >> One thing I try to do when submitting pull requests that modify >> others' packages is to mention the GitHub username of the maintainer >> in the PR description so that they receive a notification. > > > Well, as I am watching tens of repos on Github, my mailbox is full of such > emails. I would not notice such a mention, unless I decide to read the > thread because the title is interesting. Direct mails would be much better. > >> >> If the change is likely to be at all controversial then I wait for the >> maintainer to comment before merging. > > > That's should be the only way to modify a package. Or if the package > maintainer does not reply to direct emails after a week or two (in which > case either the package should be removed, or the maintainer could be > changed). > >> >> This approach could be mostly automated, with a bot that retrieves the >> username of the original committer of each file from the GitHub API. >> However, I wonder if it'd be sufficient to add a note to the PR check >> procedure (https://github.com/ocaml/opam-repository/wiki/PR-checks) >> suggesting that opam-repository maintainers notify package maintainers >> when submitting changes. > > > Again, I think it is not about suggesting, as it is already the case today. > > --Fabrice > > > _______________________________________________ > opam-devel mailing list > opam-devel@lists.ocaml.org > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
