Re: [gentoo-dev] games-emulation/jgemu keywording request

[Sam James <sam@gentoo.org>]

orbea <orbea@riseup.net> writes:

> On Mon, 11 Sep 2023 16:21:43 -0400
> Mike Gilbert <floppym@gentoo.org> wrote:
>
>> On Mon, Sep 11, 2023 at 4:11 PM orbea <orbea@riseup.net> wrote:
>> >
>> > On Mon, 11 Sep 2023 20:38:48 +0100
>> > Sam James <sam@gentoo.org> wrote:
>> >  
>> > > orbea <orbea@riseup.net> writes:
>> > >  
>> > > > On Mon, 11 Sep 2023 19:18:45 +0100
>> > > > Sam James <sam@gentoo.org> wrote:
>> > > >  
>> > > >> orbea <orbea@riseup.net> writes:
>> > > >>  
>> > > >> > Hi,
>> > > >> >
>> > > >> > Several months ago I made this issue for keywording the
>> > > >> > games-emulation/jgemu meta package which is a collection of
>> > > >> > minimal emulators for the command-line games-emulation/jgrf
>> > > >> > frontend with a focus on accuracy.
>> > > >> >  
>> > > >>
>> > > >> You've not populated the package list and no arches are CC'd,
>> > > >> but we don't keyword things for no reason either on (very)
>> > > >> niche arches.
>> > > >>
>> > > >> Please select a reasonable set of architectures.
>> > > >>  
>> > > >> > https://bugs.gentoo.org/891201  
>> > > >>
>> > > >>  
>> > > >
>> > > > Apologies, I wasn't aware I needed to do that and in retrospect
>> > > > I should of thought of it. Just to be clear you mean add an
>> > > > issue for each issue and then use them as blockers for the
>> > > > games-emulation/jgemu issue?  
>> > >
>> > > No, one bug is okay if you populate the package list field in
>> > > Bugzilla.
>> > >
>> > > Just keep in mind that keywording isn't the same as upstreaam CI
>> > > either and we generally want to only keyword on arches where
>> > > someone is likely to use it.
>> > >  
>> >
>> > Apologies, I now understand what you meant...
>> >
>> > The goal is to hopefully entice real world testers on systems that
>> > jgemu may be used. This is not something a CI would be able to
>> > accomplish.  
>> 
>> This is not an appropriate use of Gentoo arch testing. We keyword
>> things based on user demand, not to satisfy the urges of upstream
>> developers.
>> 
>
> Its a common occurrence that upstreams refuse to consider distros and
> leave them hanging, but I honestly did not expect the inverse where the
> distro is unwilling while the upstream is....

That doesn't mean we're able to start acting as CI. We already have
enough test failures and build failures to handle for packages
where people want to use them on alt-arches.