| 1 |
>>>>> On Mon, 17 Jun 2013, hasufell wrote: |
| 2 |
|
| 3 |
> @Ulrich Mueller |
| 4 |
> * Will you make it easier for people to contribute to PMS? Currently |
| 5 |
> people rather try to avoid any issues that are connected with PMS |
| 6 |
> changes. |
| 7 |
|
| 8 |
On IRC you've clarified this further (posting it here with your |
| 9 |
permission): |
| 10 |
|
| 11 |
> <hasufell> ulm: it's just an observation when discussing stuff over |
| 12 |
> the past year on bugzilla and -dev that people think more than twice |
| 13 |
> before they choose an approach that requires PMS changes |
| 14 |
> <hasufell> it takes long, you have to deal with some unpleasant |
| 15 |
> people (not you) and it might just be rejected. On the contrary... |
| 16 |
> eclass solutions don't have that. I think that is a problem |
| 17 |
|
| 18 |
How long it takes for a feature to appear in a new EAPI mostly depends |
| 19 |
on the EAPI release cycle. For example, support for sub-slots was |
| 20 |
first discussed in the gentoo-dev mailing list in June 2012 and was |
| 21 |
included in EAPI 5 which was approved only three months later. |
| 22 |
|
| 23 |
On the other hand, if you propose a new feature shortly after an EAPI |
| 24 |
was finalised, you're out of luck and have to wait for the next one. |
| 25 |
The only way to shorten this time would be to have new EAPIs more |
| 26 |
often. However, it's a balance between that and having too many EAPIs. |
| 27 |
IMHO, one new EAPI per year and about three or four that are actively |
| 28 |
used in the tree at any time is just what we can handle. |
| 29 |
|
| 30 |
Is contributing too difficult? For EAPI 5 we have only accepted |
| 31 |
features where an implementation was ready. This was the lesson |
| 32 |
learned from EAPI 4, which took almost two years (from April 2009 to |
| 33 |
January 2011) from feature freeze to approval. |
| 34 |
|
| 35 |
Generally, if you propose a new feature, then you should be its |
| 36 |
champion and make sure that a wording for the spec as well as an |
| 37 |
implementation are ready in time. If others like your feature, then |
| 38 |
you may even find somebody else who will do that work for you. I guess |
| 39 |
it's not so much different from other open source projects. (And BTW, |
| 40 |
also for "eclass solutions" you need an implementation and must build |
| 41 |
consensus in the -dev ML.) |
| 42 |
|
| 43 |
For EAPI 5, I've tried to make the process as transparent as possible, |
| 44 |
so each feature had its own bug, and all non-trivial ones were also |
| 45 |
discussed in the mailing lists. In addition, we had a wiki page [1] |
| 46 |
to collect pointers to all relevant information. I'll do the same for |
| 47 |
future EAPIs (and of course others are invited to participate). |
| 48 |
|
| 49 |
Ulrich |
| 50 |
|
| 51 |
[1] http://wiki.gentoo.org/wiki/Future_EAPI/EAPI_5_tentative_features |
Archives