1 |
Hi, |
2 |
|
3 |
Richard Freeman <rich0@g.o>: |
4 |
|
5 |
> Raúl Porcel wrote: |
6 |
> > |
7 |
> > So it would be cool if they accepted help from other devs who don't |
8 |
> > have an amd64 system but have access to one and can test stuff. Cla |
9 |
> > is willing to help. |
10 |
[...] |
11 |
> I don't keyword a package stable unless I've done at least a moderate |
12 |
> amount of testing on the package to ensure that it works. If a |
13 |
> package looks simple but obscure I might go ahead and install it and |
14 |
> play with it, but I'd probably never keyword an emacs package stable, |
15 |
> since I don't ever use emacs and I won't pretend that all there is to |
16 |
> it is installing it and typing "hello world" and figuring out how to |
17 |
> quit. |
18 |
|
19 |
Hah, got you. Emacs team has a collection of test plans, that are |
20 |
understandable and have a step-by-step guide to the package. You may |
21 |
not have noticed because at the moment, Emacs teams handles nearly all |
22 |
stabilisation requests itself on amd64. |
23 |
Yes, testing is crucial, but it eases your pain if you have an arch |
24 |
tester going over it beforehand and amd64 is well equipped with that. |
25 |
|
26 |
> If there are folks out there who can test on amd64 systems then I'm |
27 |
> sure that the amd64 team would look forward to their help (just |
28 |
> contact kingtaco about it) - either by arch testing or perhaps by |
29 |
> just keywording as appropriate. However, we do need to be careful |
30 |
> about just going on a hunt to close bugs - "if it builds then it's |
31 |
> stable" isn't really a policy I think we want to follow. As an amd64 |
32 |
> user as well as a dev I know that I'd rather be a little further |
33 |
> behind on package foo (with the ability to accept ~amd64 on it if I |
34 |
> wanted to) than to have packages breaking every other week because |
35 |
> somebody keyworded them just because it compiled and didn't have any |
36 |
> glaring faults. |
37 |
|
38 |
There are dozens of bugs out there for amd64, that are no |
39 |
stabilisation requests but contain a patch or simple requests that |
40 |
could be handled in a fast way....problem is, nobody does. Don't get |
41 |
Raul or myself wrong, we are not here to accuse someone or do a mud |
42 |
fight. We care and are worried about the state of amd64, but do not |
43 |
want to lower the work invested by some members of the team, so don't |
44 |
take anything personal or try to justify by all means. |
45 |
As a matter of fact amd64 has some broken packages in the stable tree |
46 |
where bugs exist and noone seems to care. |
47 |
|
48 |
> I think we also need better coordination across gentoo regarding when |
49 |
> packages should be stabilized. I've seen amd64 CC'ed on stablereq |
50 |
> bugs filed by end users, and arch teams keywording them left and |
51 |
> right, and there is no sign that the package maintainer wants the |
52 |
> package stabilized. I know that I'd be annoyed if arch teams |
53 |
> stabilized a package that I maintained and I didn't intend for it to |
54 |
> become stable for whatever reason. At the very least maintainers |
55 |
> should be contacted before packages go stable - and they should |
56 |
> probably document their intent in STABLEREQ bugs before everybody |
57 |
> goes crazy closing them out. |
58 |
|
59 |
This happens seldomly...and normally stabilisations are assigned to |
60 |
the maintainer which should react and cc arches. Only |
61 |
maintainer-wanted is directly cced with arches by bug wranglers. So |
62 |
such problems occur if developers/trusted users create the stabilisation |
63 |
bug. |
64 |
|
65 |
> I think that if we have the right policies then we'll be where we |
66 |
> want to be. Personally, it doesn't concern me a great deal that |
67 |
> there are tons of bugs open on an arch in and of itself (although |
68 |
> blockers and security bugs are a different matter). I'd rather that |
69 |
> then keyword something stable anytime one person (usually not the |
70 |
> maintainer) asks us to. And users who feel like they're being held |
71 |
> up should feel free to ping a dev to talk about it - and comments by |
72 |
> users and maintainers in bugs indicating how stable a package really |
73 |
> is make people like me more warm and fuzzy about keywording it |
74 |
> without as much personal testing. |
75 |
|
76 |
Again, this is not a question of not testing but a question of getting |
77 |
more work done (by more people). Sometimes I do amd64 bugs although I |
78 |
am not on the team, my only test system is a remote machine with |
79 |
hardened kernel (miranda), but I do test the packages I mark stable. |
80 |
|
81 |
V-Li |
82 |
|
83 |
-- |
84 |
Christian Faulhammer, Gentoo Lisp project |
85 |
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode |
86 |
|
87 |
<URL:http://www.faulhammer.org/> |