| 1 |
On 08/14/2012 02:35 PM, Ciaran McCreesh wrote: |
| 2 |
> On Tue, 14 Aug 2012 23:17:56 +0200 |
| 3 |
> "Andreas K. Huettel" <dilfridge@g.o> wrote: |
| 4 |
>> Waiting for a profile EAPI increase seems to be |
| 5 |
>> something like waiting for Sankt Nimmerleinstag (in German, waiting |
| 6 |
>> for the nameday of a saint that does not actually exist, i.e. |
| 7 |
>> hopelessly waiting forever). |
| 8 |
> |
| 9 |
> The only reason all this takes so long is because getting anything done |
| 10 |
> with EAPIs involves wasting months dealing with people who demand to |
| 11 |
> know why their favourite unicorn isn't there yet, why the EAPI process |
| 12 |
> isn't what they want it to be, why EAPIs have to exist at all, why we |
| 13 |
> have to care about stability, why we have to change things, why we |
| 14 |
> can't change things, etc etc. |
| 15 |
> |
| 16 |
> If getting things quickly is a goal, then you should ask the Council to |
| 17 |
> look into reducing the amount of public discussion and concensus that's |
| 18 |
> necessary to deliver a new EAPI. |
| 19 |
|
| 20 |
It seems like there's some confusion here. Approving a new EAPI and |
| 21 |
deciding to use a new EAPI in a given profile are two entirely different |
| 22 |
things. If we want to us a new EAPI in a profile, we just have to deploy |
| 23 |
it such that users are only exposed to that profile when they |
| 24 |
consciously running `eselect profile` (and they can always revert back |
| 25 |
to the previous profile if it turns out that their installed package |
| 26 |
manager doesn't support the new profile). |
| 27 |
-- |
| 28 |
Thanks, |
| 29 |
Zac |
Archives