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
