[gentoo-dev] About what kind of changes could be stabilized on all arches by the same arch team

[gentoo-dev] About what kind of changes could be stabilized on all arches by the same arch team

[Pacho Ramos]

Recently I saw some cases where some bugs reported were getting blocked
by some arch teams being slow to reply. The issue is that this pending
bug reports were only related with changes that weren't arch dependent.

Some cases that comes to my mind now:
- Changes only adding systemd unit files
- Changes to fix logrotate files (yeah, also to handle restarting of
services in systemd to stop trying to use openRC ways on them ;))
- Packages only installing icons, wallpapers.
- Any more do you remember?

I was wondering if we could document what kind of revision bumps
depending on the changes they imply could be stabilized in all arches
with the previous revision already stable on relevant arches by any arch
team member.

Thanks a lot

[gentoo-dev] Re: About what kind of changes could be stabilized on all arches by the same arch team

[Pacho Ramos]

El dom, 27-07-2014 a las 07:31 -0700, Matt Turner escribió:
> On Sun, Jul 27, 2014 at 7:02 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> > Recently I saw some cases where some bugs reported were getting blocked
> > by some arch teams being slow to reply. The issue is that this pending
> > bug reports were only related with changes that weren't arch dependent.
> >
> > Some cases that comes to my mind now:
> > - Changes only adding systemd unit files
> > - Changes to fix logrotate files (yeah, also to handle restarting of
> > services in systemd to stop trying to use openRC ways on them ;))
> > - Packages only installing icons, wallpapers.
> > - Any more do you remember?
> 
> I suppose maybe there are significant changes to the ebuild, if not
> the installed files but I always wonder whether stabilizing an -r1
> version that just adds multilib support on an architecture that
> doesn't have multilib should actually require any testing.

In that concrete case I would make it require testing-by-arch as it
involves several changes in ebuild and the way things are installed,
also usually introduce out-of-sources building that can cause new bugs
in some cases :|

Well, that is the main reason I wrote the original mail: to be able to
have a list of the changes we all agree that need no special checking
per arch :)