[gentoo-pms] Scope of EAPI 3

[gentoo-pms] Scope of EAPI 3

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 737 bytes --]

Hi,

as the council did not show any interest in further additions to EAPI
3 on their mailing list [1] and most PMS, council, Prefix and PM
members will be happy to push out an decideable EAPI 3 draft fast, I
want to tie the features:

* mtime preservation, bug 264130
* Prefix offset support, bug 296716

No matter how nice other features would be, we should regard EAPI
3 similar to EAPI 1 which was a quick thing to get some small 
features done.  Any objections?

V-Li

[1]
http://archives.gentoo.org/gentoo-council/msg_9c9c338edfb698222deb1ae74c1a6d3f.xml

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Scope of EAPI 3

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Wed, 16 Dec 2009 23:49:38 +0100
Christian Faulhammer <fauli@gentoo.org> wrote:
> as the council did not show any interest in further additions to EAPI
> 3 on their mailing list [1] and most PMS, council, Prefix and PM
> members will be happy to push out an decideable EAPI 3 draft fast, I
> want to tie the features:
> 
> * mtime preservation, bug 264130
> * Prefix offset support, bug 296716
> 
> No matter how nice other features would be, we should regard EAPI
> 3 similar to EAPI 1 which was a quick thing to get some small 
> features done.  Any objections?

Unfortunately, Zac is doing otherwise, and experience shows that what
Zac does ends up being the final decision. You'll need to either
convince him to revert the other things he's put in EAPI 3 (which I
think is just unpack changes, so far), or get the Council to make him
do so, or persuade the Council to change their minds on what's in 3.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Scope of EAPI 3

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 1444 bytes --]

Hi,

Ciaran McCreesh <ciaran.mccreesh@googlemail.com>:

> On Wed, 16 Dec 2009 23:49:38 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
> > as the council did not show any interest in further additions to
> > EAPI 3 on their mailing list [1] and most PMS, council, Prefix and
> > PM members will be happy to push out an decideable EAPI 3 draft
> > fast, I want to tie the features:
> > 
> > * mtime preservation, bug 264130
> > * Prefix offset support, bug 296716
> > 
> > No matter how nice other features would be, we should regard EAPI
> > 3 similar to EAPI 1 which was a quick thing to get some small 
> > features done.  Any objections?
> 
> Unfortunately, Zac is doing otherwise, and experience shows that what
> Zac does ends up being the final decision. You'll need to either
> convince him to revert the other things he's put in EAPI 3 (which I
> think is just unpack changes, so far), or get the Council to make him
> do so, or persuade the Council to change their minds on what's in 3.

 No council decision, no xz support, no need for moaning.  Apart from
Zac other people have commit access to the Portage repository.  The
alternative is to get the council moving and vote at least on that as
it is really useful.  ulm, mail vote?

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://gentoo.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-pms] Scope of EAPI 3

[Zac Medico]

Ciaran McCreesh wrote:
> On Wed, 16 Dec 2009 23:49:38 +0100
> Christian Faulhammer <fauli@gentoo.org> wrote:
>> No matter how nice other features would be, we should regard EAPI
>> 3 similar to EAPI 1 which was a quick thing to get some small 
>> features done.  Any objections?
> 
> Unfortunately, Zac is doing otherwise, and experience shows that what
> Zac does ends up being the final decision. You'll need to either
> convince him to revert the other things he's put in EAPI 3 (which I
> think is just unpack changes, so far), or get the Council to make him
> do so, or persuade the Council to change their minds on what's in 3.

The council doesn't have to "make" me do anything. The final EAPI 3
will have exactly what the council wants and nothing more. I added
xz unpack in EAPI 3_pre2 because I just assumed that everyone would
agree on it. If the council wants to exclude xz unpack in the final
EAPI 3, that's okay and I'll do as the council wishes.
-- 
Thanks,
Zac

Re: [gentoo-pms] Scope of EAPI 3

[Ulrich Mueller]

>>>>> On Wed, 16 Dec 2009, Zac Medico wrote:

> Ciaran McCreesh wrote:
>> Unfortunately, Zac is doing otherwise, and experience shows that
>> what Zac does ends up being the final decision. You'll need to
>> either convince him to revert the other things he's put in EAPI 3
>> (which I think is just unpack changes, so far), or get the Council
>> to make him do so, or persuade the Council to change their minds on
>> what's in 3.

We don't need to do anything of the above. We abide by the council's
decision, because the council defines what goes into an EAPI and what
not.

In any case, since .xz support will be in EAPI 4, it would be a
trivial change to move it to EAPI 3.

> The council doesn't have to "make" me do anything. The final EAPI 3
> will have exactly what the council wants and nothing more. I added
> xz unpack in EAPI 3_pre2 because I just assumed that everyone would
> agree on it. If the council wants to exclude xz unpack in the final
> EAPI 3, that's okay and I'll do as the council wishes.

Thank you for the clarification.

I guess it's an one-line change in Portage to include or not include
xz in EAPI 3?

Ulrich

Re: [gentoo-pms] Scope of EAPI 3

[Zac Medico]

Ulrich Mueller wrote:
> I guess it's an one-line change in Portage to include or not include
> xz in EAPI 3?

That's right. It's just a conditional expression that decides
whether or not to enable it in the current EAPI. It reuses the same
generic code that's already used to unpack gz, bz2, and lzma files.
-- 
Thanks,
Zac