Re: On pull request workflows for the GNU toolchain

Joseph Myers via Gdb
2024-09-23T15:01:24Z

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
josmyers@redhat.com