1 |
On Thu, 2005-03-10 at 00:57 +0200, Alin Nastac wrote: |
2 |
> I'm only annoyed by the bad attitude of some devs who will get involved |
3 |
> only what suits them, forgetting that if they would not help, no one |
4 |
> will. Btw, what is the sense of ~arch if not "testing"? No gentooer |
5 |
> expects from a ~arch ebuild to be stable, so the sky would not fall if |
6 |
> you made a mistake and release it under this keyword. When I hear "I |
7 |
> cannot mark foo library as ~arch because I don't know how to test it" |
8 |
> smells like excuse to me. |
9 |
|
10 |
You didn't ask for ~arch, you asked for stable. Also, testing doesn't |
11 |
mean providing something that it broken. The testing branch is for |
12 |
*ebuild testing* not package testing. A broken package should never be |
13 |
added to the tree unless it is hard masked. You're seeming very quick |
14 |
to point to others and lay blame, but I just don't think you get the |
15 |
fact that there are others who take QA of their systems more seriously |
16 |
than you do. |
17 |
|
18 |
> As for QA... does anyone think we *can* have proper QA procedures, with |
19 |
> our release speed and decentralized development model? And with only ... |
20 |
> 350 devs from which God knows how many are still active? :-D |
21 |
> Who thinks that clearly doesn't have a clue what QA means. It is |
22 |
> practically impossible to test every combination of ebuilds/USE/CFLAGS |
23 |
> so all we do is a surface test, letting the burden of testing on the |
24 |
> shoulders of our users. |
25 |
|
26 |
This is true to an extent. I know that I test ebuilds that I put into |
27 |
portage with every combination of USE flags. I also make sure that the |
28 |
thing works. I will also file bugs to myself, if need be, and ask users |
29 |
for help with testing before putting something in the tree. Being |
30 |
tested does not necessarily mean that a developer did the testing, just |
31 |
that a developer verified that it was tested. If you aren't testing the |
32 |
ebuilds you're committing, then you aren't doing QA and you're leaving |
33 |
it up to others to discover if something you've added is broken. This |
34 |
should happen *before* it goes in the tree, not after. |
35 |
|
36 |
> Despite of our unorthodox development process, many people believes |
37 |
> (including me) that our distro surclass traditional ones and is |
38 |
> generally more stable (go figure!). |
39 |
|
40 |
There have been a few snafus here and there, but generally I would agree |
41 |
with you. |
42 |
|
43 |
> Maybe I'm too exigent, but I only ask from people to do what I do : be |
44 |
> genuinely interested in helping the devs who need it. Heck, I always try |
45 |
> to help any gentooer, dev or not. We all have our little systems because |
46 |
> our predecesors have worked on it, not because they sit down and |
47 |
> debated whether to mark foo ebuild as ~arch or not. |
48 |
|
49 |
Trying to force your ideas of QA onto another team isn't asking someone |
50 |
to help you, it is asking someone to drop their beliefs in quality to |
51 |
meet your timetables. That is counter-productive more than helpful. |
52 |
You're using a lot of emotional arguments, and none technical. |
53 |
|
54 |
Could the mips team have helped quicker? Sure. Maybe it would have |
55 |
been beneficial for them to have simply said, "Hey. We don't have that |
56 |
hardware so we can't test it." but trying to make them look like a bunch |
57 |
of lazy developers isn't helping your case much... ;] |
58 |
|
59 |
-- |
60 |
Chris Gianelloni |
61 |
Release Engineering - Strategic Lead/QA Manager |
62 |
Games - Developer |
63 |
Gentoo Linux |