On 22 Feb 2016, at 15:41, David Allsopp <dra-n...@metastack.com> wrote: > > No they would not – getting people on the conversation thread of a PR is > vastly superior; it groups the information and discussion in the place where > it’s merged and archives it there. I have certainly had to bisect > opam-repository before, so being able to go from a > SHA1->Merge->PR->Conversation is very useful.
I'm in complete agreement with David here. We already have an established process for submitting a PR, and I'd strongly prefer that we do not create another out-of-band mechanism (email) to contact people. Why not just create an issue in opam-repository and assign to the submitter, for instance? Fabrice: I think in the short term, not CCing opam-devel for such e-mails would be appreciated. I tend to just e-mail people directly if they really don't respond. > On this string of PRs, I’m wondering if you’re treating the symptom, and not > the cause. Each PR so far is to do with an altered checksum from a code > service’s binary release system which suggests that they’re not canonical > (i.e. that they’ve changed the zip in what should be a trivial manner – e.g. > putting the files in a different order). Rather than fixing the checksums, > and causing this to happen again at the whim of a zip library, would it not > be better to put in place a policy that zip links should not be to > GitHub/BitBucket/Whatever auto-generating URLs but to actual static files > (e.g. on github.io)? Indeed -- GitHub does seem to repack archives with different distribution checksums, quite probably when they change their. On the broader question that Fabrice raises about access rights to individual packages, it's probably worth bisecting the contributors and why packages need to be affected: - individual package maintainers: submit a single package, and tend not to get regular updates about its health, for instance when a related package is upgraded. We do need a mechanism to update a maintainer about when a package is broken by an unrelated change. Right now, if this happens we add an upper bound constraint, but this doesn't remind the package maintainer to release a version compatible with the new related package. - distribution porters: adding depexts to a lot of packages (I've just rolled through and added Alpine and Fedora for instance), or minor patches hidden behind an `os` constraint. For this work, blocking on 10-20 package maintainers would be very onerous and hold back the health of the repository for that work. - architecture porters: often have a number of short-term fixes for (e.g.) ARM, and these are placed behind patch constraints so that for an x86 user, the OPAM experience is unmodified. These then need to be rolled upstream. I'm struggling a little to see what the specific problem that Fabrice is raising is, which appears to be the desire to "lock" a package against commits until he approves it. This is a reasonable request and should be as simple as the current active repository maintainers not merging requests that touch OCamlPro packages until approved by Fabrice (and/or other OCamlPro staff?). If this results in a hanging PR (as has happened in the past with ocp-build errors due to a lack of resources upstream to maintain it), then we need to just take an executive decision and either commit it or close the PR. I don't see anyone else who wants this: I am quite happy for people doing bulk builds to generate and improve constraints against my packages. More generally, lightweight tooling to make it easier to enforce such constraints locally would be very useful -- for instance, something to probe for disparities in source archives and the `opam` metadata in the repository and alert for inconsistencies. regards, Anil _______________________________________________ opam-devel mailing list opam-devel@lists.ocaml.org http://lists.ocaml.org/listinfo/opam-devel
