| 1 |
> Sometimes it is the case that because of the state of the package or the |
| 2 |
> ebuild (missing features) you don't want to make a certain ebuild stable at |
| 3 |
> all. Or that you know that it could create problems not directly related to |
| 4 |
> the ebuild being bad. In any case from a maintainer viewpoint is is quite |
| 5 |
> anoying to have your judgement challenged under your fingers. |
| 6 |
|
| 7 |
isnt that situation something for -*? when i was ready for gcc 3.4 getting |
| 8 |
much wider testing than just the very brave and curious i said so by marking |
| 9 |
it ~amd64 (and then going into the ppc64 and mips channels to announce it to |
| 10 |
those i thought would need to know. note that it isnt quite ready for general |
| 11 |
use on x86 at all, which others seem to consider the high holy arch for |
| 12 |
determining stability/usability... pffft). |
| 13 |
|
| 14 |
when i knew that the binutils ebuilds were kinda wonky and not working right, |
| 15 |
i ripped them out of ~arch and popped them into -*. when i made a mistake |
| 16 |
with gcc and SSP, i had a new release out within minutes of figuring it out. |
| 17 |
when i found out that glibc 2.3.4.20040605 was failing makecheck inside the |
| 18 |
ebuild but succeeding outside of it, i marked it -* until i figured out |
| 19 |
why... that glibc ebuild is now stable on ppc64 (pretty early... committed |
| 20 |
june 05, stable june 12) and i'm pretty excited about that. it didnt go into |
| 21 |
ppc64 stable while -*, and testing shows it fixes the segfaults that happen |
| 22 |
on that arch. you'll have to ask tom gall, but it may be the first release to |
| 23 |
pass "make check" on ppc64. :) using gcc 3.4 no less, with altivec fixes. :) |
| 24 |
|
| 25 |
and in other news, i got a bug for all arch maintainers to mark a version of |
| 26 |
gaim stable that was stable on x86. i flatly refused, as the yahoo plugin |
| 27 |
didnt work at all on 64bit archs (like the version i had in stable did)... |
| 28 |
when it finally did work, i marked it stable. so much for x86 being a |
| 29 |
measuring stick of any kind... |
| 30 |
|
| 31 |
i dont think i want someone on another arch telling me what i can and cant |
| 32 |
mark stable unless there's a good reason behind it. "i havent marked this as |
| 33 |
stable yet on my arch" is -not- a good reason... especially with gcc 3.4 |
| 34 |
needed for an n32 mips port (c++ wont compile at all without it apparently), |
| 35 |
and so many apps in testing (not -*) with gcc 3.4 fixes that certainly work |
| 36 |
better than "not at all, period" (i mean, i HAVE been working on gcc 3.4 |
| 37 |
fixes in the tree since before it was released. before i even put the ebuild |
| 38 |
in the tree on apr 19th). or ppc64 needing the same for altivec fixes and |
| 39 |
getting away from having to use hammer-branch cvs snapshots. or amd64 needing |
| 40 |
the same... amd64 fixes and proper arch support (for example, we JUST got an |
| 41 |
-march= option) and because some kernels just miscompile with 3.3.3 on amd64. |
| 42 |
|
| 43 |
BAH. and DOUBLE bah. ok, i'm done ranting :) hope it isnt too bad of a rant... |
| 44 |
^^; |
| 45 |
|
| 46 |
P.S: to elaborate on x86's gcc 3.4 readiness, a lot of apps seem to use |
| 47 |
assembly that isnt gcc 3.4 friendly. gcc 3.4 -itself- should be fine, but i |
| 48 |
dont think anyone's ready for the flood of bug reports that would be assigned |
| 49 |
to gcc-porting that are x86 only... especially since i've been the most |
| 50 |
gung-ho about gcc 3.4 so far and i'm not messing with x86. speaking of which, |
| 51 |
we need more testers/porters on x86 to start looking at gcc-porting bugs! |
| 52 |
|
| 53 |
|
| 54 |
-- |
| 55 |
Travis Tilley |
| 56 |
Gentoo/AMD64 |
| 57 |
Gentoo/Toolchain |
| 58 |
|
| 59 |
-- |
| 60 |
gentoo-dev@g.o mailing list |
Archives