1 |
On Thu, 1 Apr 2010 21:39:43 +0300 |
2 |
Dror Levin <spatz@g.o> wrote: |
3 |
> > If anyone's been personal and insulting in this discussion, it isn't |
4 |
> > Ciaran. |
5 |
> |
6 |
> I'll take that as an April Fools' day joke. |
7 |
|
8 |
Could you point out where I've been personal and insulting in this |
9 |
discussion please? I'd like to learn for future reference the kind of |
10 |
technical criticisms that you mistake for insults so that I can phrase |
11 |
them in a way less likely to mislead in the future. |
12 |
|
13 |
> I really like this attitude, though. Once you're done criticizing the |
14 |
> technological aspects of some proposal you start raising concerns |
15 |
> about how hard it is to implement features for Portage, how long that |
16 |
> takes, etc. Well, since that's not really constructive, I suggest you |
17 |
> keep those concerns to yourself. |
18 |
|
19 |
So you're saying that when designing EAPIs, we should no longer |
20 |
consider Portage implementation time? |
21 |
|
22 |
Currently, one of the requirements for including a feature in an EAPI |
23 |
is that the Portage people expect to be able to deliver it quickly. |
24 |
We've left out a huge number of widely requested features from previous |
25 |
EAPIs simply because they weren't considered deliverable by Portage in |
26 |
a realistic timeframe, and when selecting features we've been careful |
27 |
to pick those that require the minimum total amount of work on the |
28 |
Portage side. Hence pkg_pretend -- although a subset of its |
29 |
functionality could be handled in other ways, it's considered most |
30 |
practical to go for the single cheapest feature that implements |
31 |
everything people need. |
32 |
|
33 |
Would you prefer a perfect EAPI ten years from now and nothing until |
34 |
then, or a better EAPI than one that we currently have one year from |
35 |
now? The Council has been pretty explicit in wanting the latter, so if |
36 |
you want policy to be changed to the former then you'll need to take it |
37 |
up with them. |
38 |
|
39 |
-- |
40 |
Ciaran McCreesh |