-
Notifications
You must be signed in to change notification settings - Fork 106
OPAM Aggregation
This is a list of requirements for a distributed GitHub repository aggregator that gives us a unified view into unikernel issues across the totality of GitHub. The original email thread has more context.
In no particular order, from the e-mail thread:
-
@dsheets: an automatically generated list of 'lagging' packages that only work with versions of dependencies that are not the newest. This would probably need to be integrated into test results in order to cross-check the explicit version constraints.
-
@talex5: a list of outstanding pull requests needing review across all repositories
-
@yomimono: I'm not in the Mirage organization so I've had to watch a lot of repositories by hand (and I'm certainly still missing some); it would be nice to be able to watch them all automatically. A common dashboard would probably replace most of my need for this (probably modulo e-mail notifications, which I do find useful)
-
@djs55: I always forget to modify TROVE, but it’s hard to forget the tags in the opam metadata when you’re in the middle of releasing and they’re right in front of you.
-
@samoht: the ability to see lagged releases (ie. repo with commits but without a release). And maybe a one-click release button. Highlight high-level/multi-repo tracking issues (such as error handling, irmin/mirage integration, API updates). Lint release: check that all tags on a repo have a non-empty GitHub release, check that there's a CHANGES{.md} file, check that we have some tests. Ideally, we should start to have "gatekeepers" for all of our projects. If you are a gatekeeper, having a view for all issues/PR for these projects would be useful.
-
various (@dbuenzli, @talex5, @samoht): figure out changelog handling, ideally independently of GitHub and from either OPAM or Git metadata.
-
various (@dsheets @samoht @avsm): Gitter integration is working well for Cohttp/Opium but needs careful signalling to make sure that GitHub issues don't disappear into a chat melange. But something along the lines of "Have an issue? Click here to post it and here to chat about it." in the documentation for every library would go a long way.
### Tags
The tags field can be used to add metadata to a particular package.
- org:mirage -- this is a package maintained by the MirageOS team. The mirage-tcpip stack would have this tag.
- mirage -- this is a package that is part of the MirageOS ecosystem. Lwt for example could have this tag.
- networking -- this is a networking-related package. Something non-Mirage related could also use it.