1 |
On Sun, 25 Feb 2007 18:51:51 +0000 |
2 |
Steve Long <slong@××××××××××××××××××.uk> wrote: |
3 |
|
4 |
> And irrespective |
5 |
> of whether bug-wranglers have much to say, I'd still want them |
6 |
> involved, as they deal with the ebuild bugs. As such they could well |
7 |
> have ideas or viewpoints which would help. Even if they don't, it's |
8 |
> how I'd do it for any software development project- not having |
9 |
> testing/ QA/ bug fixers involved would leave me uneasy. |
10 |
|
11 |
bug-wranglers don't really have much to do with QA, their main job is |
12 |
just to assign bugs to the right people, and that doesn't have |
13 |
anything to do with a package manager specification (at most you could |
14 |
argue about the metadata.xml format, but even that is a long shot). |
15 |
|
16 |
> I don't buy the stuff about needing the so-called independent |
17 |
> implementation sorry. ``What people think is allowed rather than what |
18 |
> is?'' The spec defines what is allowed. Period. |
19 |
|
20 |
Thing is that if you only have a single implementation it's much easier |
21 |
for errors to slip by due to implicit assumptions. Unless you write a |
22 |
full compliance testsuite ... |
23 |
|
24 |
> And that still leaves the issue of EAPI 0 being the preexisting |
25 |
> implementation. What exactly is so wrong with that? |
26 |
|
27 |
Which implementation exactly? Portage isn't frozen, the behavioris more |
28 |
less constantly changing. Another issue are the things that just work by |
29 |
accident or only exist for legacy reasons, you don't really want those |
30 |
in a formal spec aimed at future developments. |
31 |
Also in general it's easier to extend a spec than to restrict it later |
32 |
on, no matter what the spec is about. |
33 |
|
34 |
Marius |
35 |
|
36 |
-- |
37 |
Public Key at http://www.genone.de/info/gpg-key.pub |
38 |
|
39 |
In the beginning, there was nothing. And God said, 'Let there be |
40 |
Light.' And there was still nothing, but you could see a bit better. |