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

[Gabriel Scherer]

Fabrice,

You agree that sometimes repo maintainers have to make some changes.
In this situation, I think that the problem you raise of upstream devs
not seeing some of the changes and submitting a before-change
description for the new package version is inevitable. As we agree
that this may happen, we are looking for ways to avoid it -- that make
life easier for everyone.

For ocamlbuild, I have written in the release How-to (the description
of things that have to be done when creating a new release) that the
upstream opam file of the last existing release should be checked for
packaging-policy changes:
  https://github.com/ocaml/ocamlbuild/blob/master/howto/release.adoc#synchronizing-the-local-and-remote-opam-files

I would encourage other maintainers to adopt such a policy. Checking
once at release time is an acceptable amount of work for software that
gets released every few months, and it ensures that this problem does
not arise. Of course, this is not a silver bullet, other developers
have different packaging habits that make release for frequent or
numerous (Daniel tries to script it as much as possible because he has
many small packages) and they may prefer another way of working with
packaging changes.

P.S.: I agree that changing checksums are a good reason to ask
developers to validate changes before pushing them in the repo, rather
than notify them after the fact. First, only they can really tell what
the archive is supposed to be (note however that md5 hashes provide no
security against tampering). Second, we want to discourage them from
doing this, so having a heavier process in that case helps steer
everyone towards good practices.

On Mon, Feb 22, 2016 at 9:48 AM, Fabrice Le Fessant
<fabrice.le_fessant at ocamlpro.com> wrote:
> On Mon, Feb 22, 2016 at 3:28 PM Gabriel Scherer <gabriel.scherer at gmail.com>
> wrote:
>>
>> There are several different kinds of changes to a package, and it
>> makes sense to let different people handle them.
>
>
> Indeed, I think repo maintainers can have to make some changes, but these
> should be the exception, not the rule. Anyway, it's good to explicit them.
>
>>
>> (1) Changes in global packaging policies that are orthogonal to any
>> particular packages. When I changed around 3000 packages to add an
>> "ocamlbuild" dependency,
>
>
> Of course, such automatic changes can only be done that way. Maybe, however,
> it would have been possible to avoid it. For example, OCaml without
> ocamlbuild could be proposed as a package only available above some OPAM
> version (1.2.2 ?), and that version would automatically add an ocamlbuild
> dependency to every package, except if it has an "ocamlbuild: false" header
> (or something like that). I am not saying it is the best solution, but
> changing 4000 packages seem even worse for me. I presume that, most of the
> time, it is possible to fix such problems in opam rather than in
> opam-repository.
>
>>
>> (2) Changes in external configurations that affect some systems that
>> the maintainer is not particularly familiar with.
>
>
> Here, I have to disagree. First, it is always good to discuss such changes,
> just for developers to learn about platforms' specificities that they were
> not aware of. If you don't do that, you will fix a version, and the next
> version will be broken again. Second, you are mixing "repo maintainers" and
> "package maintainers". Maybe developers don't have to know about specific
> platforms (although they are probably using some platform specific thing
> otherwise no change would be needed), about here, we are discussing about
> what package maintainers are supposed to know, or to learn. Package
> maintainers, as in Debian, are not the authors, they are the people who
> decide to take responsibility for making a package public on OPAM. On the
> contrary, repo maintainers are only in charge of maintaining the global
> consistency of the repository, deciding when there is a conflict between
> package maintainers, and so on. The whole point of this discussion is to
> prevent repo maintainers from acting as package maintainers, so this
> distinction is important !
>
>>
>> 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.
>
>
> Except that their contributions will be gone at the next version of the
> package, and they will continue to have broken support...
>
> --Fabrice