1 |
On Fri, 2004-06-18 at 17:08 -0400, Travis Tilley wrote: |
2 |
> > Sometimes it is the case that because of the state of the package or the |
3 |
> > ebuild (missing features) you don't want to make a certain ebuild stable at |
4 |
> > all. Or that you know that it could create problems not directly related to |
5 |
> > the ebuild being bad. In any case from a maintainer viewpoint is is quite |
6 |
> > anoying to have your judgement challenged under your fingers. |
7 |
> |
8 |
> isnt that situation something for -*? when i was ready for gcc 3.4 getting |
9 |
> much wider testing than just the very brave and curious i said so by marking |
10 |
> it ~amd64 (and then going into the ppc64 and mips channels to announce it to |
11 |
> those i thought would need to know. note that it isnt quite ready for general |
12 |
> use on x86 at all, which others seem to consider the high holy arch for |
13 |
> determining stability/usability... pffft). |
14 |
|
15 |
My initial email tried so hard to not make 'maintainer arch' the same as |
16 |
'x86', then why do you bring that up as a focus point. It is this |
17 |
attitude (my arch vs yours) that makes it hard to get any healthy |
18 |
discussion going here. |
19 |
|
20 |
> when i knew that the binutils ebuilds were kinda wonky and not working right, |
21 |
> i ripped them out of ~arch and popped them into -*. when i made a mistake |
22 |
> with gcc and SSP, i had a new release out within minutes of figuring it out. |
23 |
> when i found out that glibc 2.3.4.20040605 was failing makecheck inside the |
24 |
> ebuild but succeeding outside of it, i marked it -* until i figured out |
25 |
> why... that glibc ebuild is now stable on ppc64 (pretty early... committed |
26 |
> june 05, stable june 12) and i'm pretty excited about that. it didnt go into |
27 |
> ppc64 stable while -*, and testing shows it fixes the segfaults that happen |
28 |
> on that arch. you'll have to ask tom gall, but it may be the first release to |
29 |
> pass "make check" on ppc64. :) using gcc 3.4 no less, with altivec fixes. :) |
30 |
|
31 |
-* means broken on all arches by definition. Sure it's a pretty good |
32 |
solution here for what you want to do, but it still is bending the |
33 |
rules. |
34 |
|
35 |
What i see from your developers tale here, is that you do your testing |
36 |
in the live tree. I mean serious.. messing libtool, gcc & glibc and |
37 |
being happy with that ? I'd say that stuff should've been done in |
38 |
package.mask, certainly not in ~arch. One used to get his cvs access |
39 |
rights under discussion after these kind of things. |
40 |
|
41 |
> and in other news, i got a bug for all arch maintainers to mark a version of |
42 |
> gaim stable that was stable on x86. i flatly refused, as the yahoo plugin |
43 |
> didnt work at all on 64bit archs (like the version i had in stable did)... |
44 |
> when it finally did work, i marked it stable. so much for x86 being a |
45 |
> measuring stick of any kind... |
46 |
|
47 |
Well, i assume the yahoo plugin worked on x86 at that point. 'x86' here |
48 |
being the 'maintainers arch' i assume, it was ready for going stable. |
49 |
Next 64bits arch weren't stable, so you did the right thing not marking |
50 |
it as such. 'x86' again is mentioned here, it's irrelevant which |
51 |
platform is the 'maintainers arch', don't get so hang up on x86. It is a |
52 |
measuring stick that the _ebuild_ & _package_ were tested at that time. |
53 |
I wonder if they even were aware of the 64bit platform problems, if so |
54 |
they should've probably pushed to 64 bit teams to mark it -<arch> for |
55 |
their respective platforms (known not to work). See, the 'maintainers |
56 |
arch' should know about _all_ problems with the packages. If you were |
57 |
aware of it & failed to inform them, then this is really your mistake |
58 |
showing. |
59 |
|
60 |
> i dont think i want someone on another arch telling me what i can and cant |
61 |
> mark stable unless there's a good reason behind it. "i havent marked this as |
62 |
> stable yet on my arch" is -not- a good reason... especially with gcc 3.4 |
63 |
> needed for an n32 mips port (c++ wont compile at all without it apparently), |
64 |
> and so many apps in testing (not -*) with gcc 3.4 fixes that certainly work |
65 |
> better than "not at all, period" (i mean, i HAVE been working on gcc 3.4 |
66 |
> fixes in the tree since before it was released. before i even put the ebuild |
67 |
> in the tree on apr 19th). or ppc64 needing the same for altivec fixes and |
68 |
> getting away from having to use hammer-branch cvs snapshots. or amd64 needing |
69 |
> the same... amd64 fixes and proper arch support (for example, we JUST got an |
70 |
> -march= option) and because some kernels just miscompile with 3.3.3 on amd64. |
71 |
|
72 |
Actually 'i haven't marked this as stable yet on my arch' is a good |
73 |
reason if the ebuild maintainer tells you so, for the simple reason that |
74 |
you lack the overview over the full package maintenance outside the |
75 |
scope of your arch. I cannot believe how you can so easily disregard |
76 |
this form of basic QA. |
77 |
|
78 |
As an example of it can go wrong, there was an arch that marked gtk+-2.4 |
79 |
stable before the maintainers arch & effectively broke the building of |
80 |
over a dozen packages in the tree. The maintainers were keeping it in |
81 |
~arch to get those issues fixed, but with their QA hurting ways the arch |
82 |
got their users into trouble for no reason whatsoever. In smaller ways |
83 |
this has happened numerous times now with different arches doing it. |
84 |
|
85 |
> BAH. and DOUBLE bah. ok, i'm done ranting :) hope it isnt too bad of a rant... |
86 |
> ^^; |
87 |
|
88 |
Your arguments tend to be emotional and really based on an arch vs arch |
89 |
attitude, not willing to take into account serious QA problems in your |
90 |
'solutions'. See it in the bigger picture of Gentoo overall quality for |
91 |
once, not your shortsighted amd64 only vision. |
92 |
|
93 |
- foser |