| 1 |
El dom, 27-07-2014 a las 07:31 -0700, Matt Turner escribió: |
| 2 |
> On Sun, Jul 27, 2014 at 7:02 AM, Pacho Ramos <pacho@g.o> wrote: |
| 3 |
> > Recently I saw some cases where some bugs reported were getting blocked |
| 4 |
> > by some arch teams being slow to reply. The issue is that this pending |
| 5 |
> > bug reports were only related with changes that weren't arch dependent. |
| 6 |
> > |
| 7 |
> > Some cases that comes to my mind now: |
| 8 |
> > - Changes only adding systemd unit files |
| 9 |
> > - Changes to fix logrotate files (yeah, also to handle restarting of |
| 10 |
> > services in systemd to stop trying to use openRC ways on them ;)) |
| 11 |
> > - Packages only installing icons, wallpapers. |
| 12 |
> > - Any more do you remember? |
| 13 |
> |
| 14 |
> I suppose maybe there are significant changes to the ebuild, if not |
| 15 |
> the installed files but I always wonder whether stabilizing an -r1 |
| 16 |
> version that just adds multilib support on an architecture that |
| 17 |
> doesn't have multilib should actually require any testing. |
| 18 |
|
| 19 |
In that concrete case I would make it require testing-by-arch as it |
| 20 |
involves several changes in ebuild and the way things are installed, |
| 21 |
also usually introduce out-of-sources building that can cause new bugs |
| 22 |
in some cases :| |
| 23 |
|
| 24 |
Well, that is the main reason I wrote the original mail: to be able to |
| 25 |
have a list of the changes we all agree that need no special checking |
| 26 |
per arch :) |
Archives