[opam-devel] current opam-repository policy : who can modify a package description

[Gabriel Scherer]

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_fessant at ocamlpro.com> wrote:
> Dear Jeremy,
>
> On Mon, Feb 22, 2016 at 11:39 AM Jeremy Yallop <yallop at 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 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>