| 1 |
On Sat, 17 Dec 2011 16:38:31 +0100 |
| 2 |
Pacho Ramos <pacho@g.o> wrote: |
| 3 |
|
| 4 |
> El sáb, 17-12-2011 a las 16:22 +0100, "Paweł Hajdan, Jr." escribió: |
| 5 |
> > For several mass-filed stabilization bugs I got comments why I |
| 6 |
> > didn't cc arches like ppc. |
| 7 |
|
| 8 |
And correctly so. |
| 9 |
|
| 10 |
> > One problem is that I cc x86 and amd64 via "edit many bugs at once" |
| 11 |
> > Bugzilla feature, and when filing bugs the script checks that it's |
| 12 |
> > repoman-possible to stabilize given package on x86 and amd64. |
| 13 |
> > |
| 14 |
> > Not all packages are even keyworded ~ppc, and I guess there are |
| 15 |
> > packages that can be stabilized on x86 and amd64, but not ppc |
| 16 |
> > because of ~ppc dependencies. |
| 17 |
|
| 18 |
I would think you'd stabilise only packages for which a previous |
| 19 |
version is already stable. If you focused on that, the problem of |
| 20 |
dependencies being unstable wouldn't exist. ~arch on all ebuilds |
| 21 |
simply means no security support, so asking to go stable means adding |
| 22 |
that, and this changes the entire purpose of your stabilisation bugs |
| 23 |
when you ask arch teams to go stable for the first time. |
| 24 |
|
| 25 |
> > All of that is of course solvable with a smarter script, however I'm |
| 26 |
> > really worried about the additional load on the "rare arches". |
| 27 |
|
| 28 |
Um, so somebody else will have to go through the whole load of bug |
| 29 |
reports to fix the arch teams you left out? Because your script doesn't |
| 30 |
do it? |
| 31 |
|
| 32 |
> > What do you think? Should I make my scripts smarter, or is it fine |
| 33 |
> > to just cc x86 and amd64? Is anyone from non-x86-non-amd64 arch |
| 34 |
> > teams annoyed by the queue of stabilization bugs? |
| 35 |
|
| 36 |
I'd like you to file correct stabilisation bug reports. Which means |
| 37 |
CCing all arches that have /previous/ ebuilds stable. We've always done |
| 38 |
it like this. |
| 39 |
|
| 40 |
> I am not in ppc* teams but, from my point of view, looks like they are |
| 41 |
> understaffed and I doubt they could handle so many requests. |
| 42 |
|
| 43 |
Same goes for all the less popular architectures. |
| 44 |
|
| 45 |
> For mass stabilization purposes I would keep the script for amd64/x86 |
| 46 |
> only for now :-/ |
| 47 |
|
| 48 |
The only way to maintain these architectures properly is to not exclude |
| 49 |
them in the first place. Once you start doing that, you might as well |
| 50 |
stop supporting security, go ~arch or drop them entirely. |
| 51 |
|
| 52 |
The only way to show there is a problem with staffing and/or the |
| 53 |
availability of supported systems is to include these arch teams in |
| 54 |
stabilisation bugs and then draft in more developers. In a volunteer |
| 55 |
project, hiding the problems makes sure no one will come in and fix |
| 56 |
them. |
| 57 |
|
| 58 |
The good thing about including slow arch teams is that when you've |
| 59 |
gathered up a couple hundred or thousand bug reports, you can make a |
| 60 |
very good case about dropping the old stable ebuilds, effectively |
| 61 |
moving the slow arch to unstable. |
| 62 |
|
| 63 |
|
| 64 |
jer |
Archives