>>>>> On Mon, 17 Jun 2013, hasufell  wrote:

> @Ulrich Mueller
> * Will you make it easier for people to contribute to PMS? Currently
> people rather try to avoid any issues that are connected with PMS
> changes.

On IRC you've clarified this further (posting it here with your
permission):

> <hasufell> ulm: it's just an observation when discussing stuff over
> the past year on bugzilla and -dev that people think more than twice
> before they choose an approach that requires PMS changes
> <hasufell> it takes long, you have to deal with some unpleasant
> people (not you) and it might just be rejected. On the contrary...
> eclass solutions don't have that. I think that is a problem

How long it takes for a feature to appear in a new EAPI mostly depends
on the EAPI release cycle. For example, support for sub-slots was
first discussed in the gentoo-dev mailing list in June 2012 and was
included in EAPI 5 which was approved only three months later.

On the other hand, if you propose a new feature shortly after an EAPI
was finalised, you're out of luck and have to wait for the next one.
The only way to shorten this time would be to have new EAPIs more
often. However, it's a balance between that and having too many EAPIs.
IMHO, one new EAPI per year and about three or four that are actively
used in the tree at any time is just what we can handle.

Is contributing too difficult? For EAPI 5 we have only accepted
features where an implementation was ready. This was the lesson
learned from EAPI 4, which took almost two years (from April 2009 to
January 2011) from feature freeze to approval.

Generally, if you propose a new feature, then you should be its
champion and make sure that a wording for the spec as well as an
implementation are ready in time. If others like your feature, then
you may even find somebody else who will do that work for you. I guess
it's not so much different from other open source projects. (And BTW,
also for "eclass solutions" you need an implementation and must build
consensus in the -dev ML.)

For EAPI 5, I've tried to make the process as transparent as possible,
so each feature had its own bug, and all non-trivial ones were also
discussed in the mailing lists. In addition, we had a wiki page [1]
to collect pointers to all relevant information. I'll do the same for
future EAPIs (and of course others are invited to participate).

Ulrich

[1] http://wiki.gentoo.org/wiki/Future_EAPI/EAPI_5_tentative_features