On Wed, 25 Feb 2009 00:21:23 +0200
Petteri Räty <betelgeuse@g.o> wrote:

> Let's try something new. I would like to get opinions [...]

A multitude of leaves on every branch of the tree. That could be a
multiple of the current tree size - maybe talk to infra about this.

It's also a multitude of complexity - as an arch security liaison, I
get to see how difficult it is already to figure out which revision to
test and mark, and figuring out why a certain revision isn't ready yet
is tantamount to figuring out what EAPI=foo actually means.

As an ebuild developer I get to see how difficult it is to figure out
which EAPI is ready enough to write ebuilds for - Changing filename
extensions is to me like a Windows 95 way of opening a file and it
doesn't at all tell me what I can and cannot put into that file.

Either as an arch, or as ebuild dev pur sang, I don't care about EAPIs
that much until I want to use a new feature - I don't want to maintain
EAPI=N branches of testing and stabling systems to test stuff either
before it's published or when it's time for stabilisation. Stamping
EAPIs down in filename extensions is just another way to point out the
cruft.

As a bug wrangler, it doesn't solve current problems of stale overlays
with too novel or too old ebuilds.

To users, it doesn't matter at all - which seems to bring about the
question of the use case everyone's clamouring for. What developers
will benefit this at all, how large are the branches this will affect,
how many developers will have to rewrite tools, and so on?


Kind regards,
      jer