On Mon, 23 Sep 2024, Richard Earnshaw (lists) via Gcc wrote: > One thing we must do, however, is break requirements into a number of > categories: must haves (red lines, we can't transition without this); should > haves (important, but we can likely find acceptable work-arounds); and would > like (this would make things really nice, but they won't really block a > transition).
The assessment of a forge against the criteria isn't expected to be simple yes/no; it's expected to involve more of an analysis/discussion of how criteria / underlying goals relate to the facilities provided by a particular forge. And there isn't a very sharp line between "work-around" and "doing this in some external software hooked up to the forge with an API is the expected way of doing such things with the forge". (Plenty of projects make extensive use of APIs to implement their own workflows on GitHub, for example. That sort of thing works much better for e.g. CI or actions that are supposed to happen post-commit, than for something like support for dependencies / patch series which is more of a core feature needing to be present in the underlying software.) -- Joseph S. Myers josmy...@redhat.com
