1 |
On Thursday 13 December 2012 13:59:40 Jory A. Pratt wrote: |
2 |
> Well there are exceptions to every rule, it is the ideal to get a |
3 |
> discussion to make a better decision as to when a revision of a package |
4 |
> should be removed and no longer supported. Well many slots can be useful |
5 |
> for many packages, there has to be a time we start removing them older |
6 |
> slots that just are not practical any longer. |
7 |
|
8 |
seeing as how the gcc ebuilds are maintained by the toolchain group which is |
9 |
entirely active, i frankly don't care what people think should happen to them. |
10 |
don't take this personally because it isn't -- i'll say the same thing to |
11 |
anyone who says drop the older gcc ebuilds yet isn't maintaining them. i'll |
12 |
probably listen a bit more to a toolchain member, but since that number is low |
13 |
and they haven't been complaining ... |
14 |
|
15 |
the expectation with the older slots is that they'll get updates on a per-case |
16 |
basis. generally, if the fix exists and the backport isn't crazy, i'll do it. |
17 |
considering the steady influx of requests, i'm pretty sure that these do serve |
18 |
a useful purpose to people. |
19 |
|
20 |
no one is suggesting that people have to support packages with older gcc |
21 |
versions (or if they are, then tell them to not be dumb). we already close |
22 |
bugs filed related to gcc versions older than current stable as "upgrade to |
23 |
stable". if a maintainer decides they want to add a particular change, then |
24 |
that's their call. |
25 |
|
26 |
don't like the older versions ? don't install them. problem solved. they |
27 |
aren't causing issues otherwise. |
28 |
-mike |