| 1 |
28.2.2006, 18:09:54, Ciaran McCreesh wrote: |
| 2 |
|
| 3 |
> On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <jakub@g.o> wrote: |
| 4 |
| >> PVR includes the revision of an ebuild. This means that if a |
| 5 |
| >> revbump is made on a webapp package to fix a critical flaw, users |
| 6 |
| >> will still have the old broken package installed too. This is |
| 7 |
| >> especially relevant for security issues, but also applies to other |
| 8 |
| >> kinds of fix. |
| 9 |
> | |
| 10 |
> | Not including the revision into the SLOT can break the apps by |
| 11 |
> | removing the needed files from a live site... I still can't see any |
| 12 |
> | *QA* violation there. |
| 13 |
|
| 14 |
> Again, that's a design flaw. It's an eclass that's abusing SLOT, thus |
| 15 |
> it's a QA issue. |
| 16 |
|
| 17 |
OK, so kernel-2.eclass is abusing the slot as well, go scream on kernel |
| 18 |
devs. |
| 19 |
|
| 20 |
> | Yeah, it checks for that since that's the way the eclass is designed. |
| 21 |
> | You can't declare a slot in a kernel ebuild either. |
| 22 |
|
| 23 |
> One is a design flaw. The other is not. |
| 24 |
|
| 25 |
Ah, tell me about the dual standards :P |
| 26 |
|
| 27 |
> | Well, starts to be boring - so, either come with something valid from |
| 28 |
> | QA standpoint or stop now. |
| 29 |
|
| 30 |
> This is a valid issue from a QA standpoint. This is also why I'm not |
| 31 |
> going to waste my time doing a proper list -- rather than addressing |
| 32 |
> issues, they are being passed off as irrelevant or even features. |
| 33 |
|
| 34 |
Next time, rather think a couple of times up before claiming something very |
| 35 |
broken on a public mailing list where you have no proof for such claims. |
| 36 |
Will be immensely helpful for everyone involved. |
| 37 |
|
| 38 |
Thanks. |
| 39 |
|
| 40 |
|
| 41 |
-- |
| 42 |
|
| 43 |
jakub |
Archives