| 1 |
On Sun, 16 Feb 2014 09:03:31 -0500 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> Well, that depends on your perspective. If they fix them by deleting |
| 5 |
> the old version, then whether they've made things better or worse is a |
| 6 |
> matter of philosophy. |
| 7 |
|
| 8 |
When you've cut the understaffed arch team out of the loop and removed |
| 9 |
the troublesome old ebuild, things are actually better. |
| 10 |
|
| 11 |
The problem with any arch team is that they may have ideas about what |
| 12 |
should be available in the stable branch that might not match what they |
| 13 |
can nowadays realistically maintain. This might be because fewer people |
| 14 |
use that architecture than did in the past, or it might be because the |
| 15 |
best systems using that architecture have become too slow for modern |
| 16 |
versions of some software, or because a one time arch developer |
| 17 |
happened to like certain packages and at the time thought it was a nice |
| 18 |
idea to mark X packages stable there. |
| 19 |
|
| 20 |
We've seen problems like this in the past with the bigger desktop |
| 21 |
environments being stable (but lagging) on typical workstation |
| 22 |
architectures, for instance, and also with expansive server application |
| 23 |
frameworks on typical server architectures. |
| 24 |
|
| 25 |
> That's basically the counter-argument to removing old versions. If |
| 26 |
> the newer version doesn't work at all, then the old buggy version is |
| 27 |
> superior. It is better to have the bugs ignored, than to pester the |
| 28 |
> maintainer until the package is disabled entirely. |
| 29 |
> |
| 30 |
> Honestly, this whole conversation seems rather theoretical. |
| 31 |
|
| 32 |
Would you like some examples to be able to move beyond the theoretical? |
| 33 |
I have plenty. |
| 34 |
|
| 35 |
> What I haven't heard from is the minor arch leads. Actually, |
| 36 |
> looking at the base project page, it seems like half of them don't |
| 37 |
> even have leads. |
| 38 |
|
| 39 |
That's what "understaffed" means. I guess for them to engage in this |
| 40 |
discussion would take away even more precious time. :) |
| 41 |
|
| 42 |
> The other issue is that at least some devs have been stabilizing new |
| 43 |
> packages on minor archs for which the council decided to drop stable |
| 44 |
> keywords. How to handle that is on the next agenda as well. |
| 45 |
|
| 46 |
Why is this a problem? Also, doesn't profiles.desc already handle this? |
| 47 |
|
| 48 |
> Basically all of this boils down to whether it is a good compromise to |
| 49 |
> redefine "stable" to something different on minor archs so that they |
| 50 |
> can make some use of the keyword, and do it without driving |
| 51 |
> maintainers nuts. I don't have a big problem with that, as long as it |
| 52 |
> is done in a way that doesn't place any burden on anybody who doesn't |
| 53 |
> use the minor arch (including bug wranglers, maintainers, etc). |
| 54 |
|
| 55 |
What does that mean? "Stable" should mean the same for everyone, as |
| 56 |
should "unstable" and "not keyworded". It sends a very clear message to |
| 57 |
whomever would like to use a certain ebuild on a certain architecture. |
| 58 |
|
| 59 |
|
| 60 |
jer |
Archives