| 1 |
On Wed, 25 Feb 2009 00:21:23 +0200 |
| 2 |
Petteri Räty <betelgeuse@g.o> wrote: |
| 3 |
|
| 4 |
> Let's try something new. I would like to get opinions [...] |
| 5 |
|
| 6 |
A multitude of leaves on every branch of the tree. That could be a |
| 7 |
multiple of the current tree size - maybe talk to infra about this. |
| 8 |
|
| 9 |
It's also a multitude of complexity - as an arch security liaison, I |
| 10 |
get to see how difficult it is already to figure out which revision to |
| 11 |
test and mark, and figuring out why a certain revision isn't ready yet |
| 12 |
is tantamount to figuring out what EAPI=foo actually means. |
| 13 |
|
| 14 |
As an ebuild developer I get to see how difficult it is to figure out |
| 15 |
which EAPI is ready enough to write ebuilds for - Changing filename |
| 16 |
extensions is to me like a Windows 95 way of opening a file and it |
| 17 |
doesn't at all tell me what I can and cannot put into that file. |
| 18 |
|
| 19 |
Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs |
| 20 |
that much until I want to use a new feature - I don't want to maintain |
| 21 |
EAPI=N branches of testing and stabling systems to test stuff either |
| 22 |
before it's published or when it's time for stabilisation. Stamping |
| 23 |
EAPIs down in filename extensions is just another way to point out the |
| 24 |
cruft. |
| 25 |
|
| 26 |
As a bug wrangler, it doesn't solve current problems of stale overlays |
| 27 |
with too novel or too old ebuilds. |
| 28 |
|
| 29 |
To users, it doesn't matter at all - which seems to bring about the |
| 30 |
question of the use case everyone's clamouring for. What developers |
| 31 |
will benefit this at all, how large are the branches this will affect, |
| 32 |
how many developers will have to rewrite tools, and so on? |
| 33 |
|
| 34 |
|
| 35 |
Kind regards, |
| 36 |
jer |
Archives