Re: On pull request workflows for the GNU toolchain

[Joseph Myers via Gdb <gdb@sourceware.org>]

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