> * Location of design documents: not sure at all this is best, because > versionning of the design document (at least during the design phase) doesn't > need to be synchronized with the source, but it has its advantages, and I > don't like github's wikis much. Seemed more practical for something in-depth > than just an issue. Do you suggest another option ? Adding headers is a good > idea.
repo + up-to-date headers is fine (and adding the right headers to other design spec as well) Thomas >> - Anil Madhavapeddy, 06/01/2015 15:39 - >> Looks great, Louis! My immediate thoughts: >> >> - This does have the potential to complicating pinning quite a lot, which >> needs to be balanced against the better upgrade messages. Do you think >> this will need a package selection priority the way that apt-pinning in >> Debian works (e.g. so that ocaml-tls can be selected ahead of openssl-tls >> for the TLS package). >> >> - The forking and providing replacements would be really useful for Mirage, >> where we're having an active discussion about how to provide Xen-specific >> versions of certain packages such as Zarith. Thomas (with any surname), >> opinions on this? >> >> - How much damage will this do to the internal solver heuristics? >> >> -anil >> >>> On 5 Jan 2015, at 08:36, Louis Gesbert <[email protected]> wrote: >>> >>> Hi all, and happy new year ! >>> >>> I just added to opam a design proposal to open discussion on the >>> implementation of the 'provides' field and its use-cases. >>> >>> It's at https://github.com/ocaml/opam/blob/master/doc/design/provides.md >>> >>> Cheers, >>> Louis >>> _______________________________________________ >>> opam-devel mailing list >>> [email protected] >>> http://lists.ocaml.org/listinfo/opam-devel >>> > _______________________________________________ > opam-devel mailing list > [email protected] > http://lists.ocaml.org/listinfo/opam-devel _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
