[gentoo-dev] EAPI-2

[gentoo-dev] EAPI-2

[Jorge Manuel B. S. Vicetto]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi again.

Quoting Zac earlier in #gentoo-portage:

21:46 < zmedico> jmbsvicetto: I think we essentially have a spec already
that people can agree on. just take my draft and subtract the eapi*
functions and the gitweb unpack extension.

So we're talking about adding the following to EAPI-2:

~ * The 'doman' helper function recognizes language codes in man page
~   source files, and uses them to generate an appropriate
~   installation path.

~ * The meaning of the !atom blocker syntax now implies that
~   temporary simultaneous installation of conflicting packages is
~   allowed [3].

~ * A new !!atom blocker syntax is now supported, for use in special
~   cases in which temporary simultaneous installation of conflicting
~   packages should not be allowed.

~ * Dependency atoms can be constrained to match specific USE flag
~   states, including USE conditional expressions embedded within
~   the atoms themselves.

~ * SRC_URI supports a syntax extension which allows customization
~   of output file names by using a "->" operator.

~ * A new src_prepare phase function is called after src_unpack.

~ * The old src_compile phase function is split into separate
~   src_configure and src_compile fuctions.

~ * Default phase function implementations for the current EAPI are
~   accessible via a function having a name that begins with default_
~   and ends with the respective phase function name.

~ * The default phase function implementation for the currently
~   executing phase is accessible as a function named 'default'.

Given the earlier discussion about EAPI-2 in
http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml
and cardoe's earlier request to the council ml, can the council members
discuss this proposal and consider voting it?
Does anyone have any objections to this proposal?

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjFtoQACgkQcAWygvVEyALQigCePXcGlT5m6JGB2OlB5swY6f4F
/yIAnRte3mm5PULg73j5KDrnKHSFB5h6
=lW1u
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2

[Doug Goldstein]

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

Jorge Manuel B. S. Vicetto wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi again.
>
> Quoting Zac earlier in #gentoo-portage:
>
> 21:46 < zmedico> jmbsvicetto: I think we essentially have a spec already
> that people can agree on. just take my draft and subtract the eapi*
> functions and the gitweb unpack extension.
>
> So we're talking about adding the following to EAPI-2:
>
> ~ * The 'doman' helper function recognizes language codes in man page
> ~   source files, and uses them to generate an appropriate
> ~   installation path.
>
> ~ * The meaning of the !atom blocker syntax now implies that
> ~   temporary simultaneous installation of conflicting packages is
> ~   allowed [3].
>
> ~ * A new !!atom blocker syntax is now supported, for use in special
> ~   cases in which temporary simultaneous installation of conflicting
> ~   packages should not be allowed.
>
> ~ * Dependency atoms can be constrained to match specific USE flag
> ~   states, including USE conditional expressions embedded within
> ~   the atoms themselves.
>
> ~ * SRC_URI supports a syntax extension which allows customization
> ~   of output file names by using a "->" operator.
>
> ~ * A new src_prepare phase function is called after src_unpack.
>
> ~ * The old src_compile phase function is split into separate
> ~   src_configure and src_compile fuctions.
>
> ~ * Default phase function implementations for the current EAPI are
> ~   accessible via a function having a name that begins with default_
> ~   and ends with the respective phase function name.
>
> ~ * The default phase function implementation for the currently
> ~   executing phase is accessible as a function named 'default'.
>
> Given the earlier discussion about EAPI-2 in
> http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml 
>
> and cardoe's earlier request to the council ml, can the council members
> discuss this proposal and consider voting it?
> Does anyone have any objections to this proposal?
>
> - --
> Regards,
>
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / SPARC / KDE
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkjFtoQACgkQcAWygvVEyALQigCePXcGlT5m6JGB2OlB5swY6f4F
> /yIAnRte3mm5PULg73j5KDrnKHSFB5h6
> =lW1u
> -----END PGP SIGNATURE-----
>
That removes the only two sections that appeared to have any chatter on 
them. Anyone involved in PMS or other package managers have any input on 
this?

[-- Attachment #3: "AVG certification" --]
[-- Type: text/plain, Size: 164 bytes --]


No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.169 / Virus Database: 270.6.19/1660 - Release Date: 9/8/2008 6:39 PM

Re: [gentoo-dev] EAPI-2

[Petteri Räty]

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

Jorge Manuel B. S. Vicetto kirjoitti:
> 
> and cardoe's earlier request to the council ml, can the council members
> discuss this proposal and consider voting it?
> Does anyone have any objections to this proposal?
> 

I won't approve it for use in the tree before it's written as a GLEP in 
order to avoid the fiasco with EAPI 1 (it's still not documented 
properly). I can however approve the list of items.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Tue, 09 Sep 2008 16:31:08 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Jorge Manuel B. S. Vicetto kirjoitti:
> > and cardoe's earlier request to the council ml, can the council
> > members discuss this proposal and consider voting it?
> > Does anyone have any objections to this proposal?
> 
> I won't approve it for use in the tree before it's written as a GLEP
> in order to avoid the fiasco with EAPI 1 (it's still not documented 
> properly). I can however approve the list of items.

What about the PMS EAPI 1 documentation do you consider 'not proper'?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2 do* functions die

[Peter Volkov]

В Пнд, 08/09/2008 в 23:34 +0000, Jorge Manuel B. S. Vicetto пишет:
> So we're talking about adding the following to EAPI-2:

While it's not too late. Can we make dobin, doman and other do*
functions finally die in EAPI=2? I've reviewed discussions on -dev
[1],[2] and bug 138792 [3] and seems that the only possible stopper is
that implementing them as functions makes impossible to use them with
xargs. Maybe for such rather rare case we should create new functions
(xdo{bin,*} or whatever name is better)?

[1] http://thread.gmane.org/gmane.linux.gentoo.devel/40437
[2] http://thread.gmane.org/gmane.linux.gentoo.devel/56443
[3] bugs.gentoo.org/138792

-- 
Peter.

Re: [gentoo-dev] EAPI-2 do* functions die

[Ciaran McCreesh]

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

On Tue, 09 Sep 2008 20:45:52 +0400
Peter Volkov <pva@gentoo.org> wrote:
> В Пнд, 08/09/2008 в 23:34 +0000, Jorge Manuel B. S. Vicetto пишет:
> > So we're talking about adding the following to EAPI-2:
> 
> While it's not too late. Can we make dobin, doman and other do*
> functions finally die in EAPI=2? I've reviewed discussions on -dev
> [1],[2] and bug 138792 [3] and seems that the only possible stopper is
> that implementing them as functions makes impossible to use them with
> xargs. Maybe for such rather rare case we should create new functions
> (xdo{bin,*} or whatever name is better)?

I'd suggest holding off on that one. There're at least three different
ways of implementing it, all with different implications, and it needs
proper discussion.

* Using traps looks nice on the surface, but in practice they're
sufficiently weird on things like conditionals that they're probably not
a useful solution.

* Banning xargs and doing them as functions is a possibility, but far
from ideal, especially since it's just working around a Portage
limitation.

* Making Portage support subprocess dies is the nice solution, but this
probably isn't an EAPI 2 timeframe feature.

In addition, having nonfatal versions of commands is also useful in
practice. Exheres has a 'nonfatal' command, so you can do 'nonfatal
dodoc foo bar baz'. This also needs discussing before deciding upon a
spec.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Jim Ramsay]

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

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

> On Tue, 09 Sep 2008 16:31:08 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Jorge Manuel B. S. Vicetto kirjoitti:
> > > and cardoe's earlier request to the council ml, can the council
> > > members discuss this proposal and consider voting it?
> > > Does anyone have any objections to this proposal?
> > 
> > I won't approve it for use in the tree before it's written as a GLEP
> > in order to avoid the fiasco with EAPI 1 (it's still not documented 
> > properly). I can however approve the list of items.
> 
> What about the PMS EAPI 1 documentation do you consider 'not proper'?
 
I was personally expecting to see some sort of section called "EAPI-1"
that contains something like:

"EAPI-1 consists of EAPI-0 with the following features added..."

Then an explanation of each change and the appropriate syntax.

I did see how EAPI-1 is integrated throughout the document, which is
valuable in a different way - but it's harder to answer the question
"What exactly does EAPI-1 add to EAPI-0?"

Perhaps I'll try sending you a patch with something like that, if I
have time, and if it would be appreciated.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox,gkrellm)

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

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Tue, 9 Sep 2008 22:14:57 -0400
Jim Ramsay <lack@gentoo.org> wrote:
> > What about the PMS EAPI 1 documentation do you consider 'not
> > proper'?
>  
> I was personally expecting to see some sort of section called "EAPI-1"
> that contains something like:
> 
> "EAPI-1 consists of EAPI-0 with the following features added..."
> 
> Then an explanation of each change and the appropriate syntax.
> 
> I did see how EAPI-1 is integrated throughout the document, which is
> valuable in a different way - but it's harder to answer the question
> "What exactly does EAPI-1 add to EAPI-0?"

The way it is now is valuable to package manage people, since they need
to know things like "my parser must be able to do foo, bar and baz",
not "my parser must be able to do foo" and then hidden away later "the
parser must also do bar and baz for EAPI 1".

> Perhaps I'll try sending you a patch with something like that, if I
> have time, and if it would be appreciated.

We've discussed having a purely informative appendix with a summary of
changes between EAPIs, and references to all the relevant sections. But
no-one's ever wanted it enough to submit a patch...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Tue, 09 Sep 2008 16:31:08 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
>> Jorge Manuel B. S. Vicetto kirjoitti:
>>> and cardoe's earlier request to the council ml, can the council
>>> members discuss this proposal and consider voting it?
>>> Does anyone have any objections to this proposal?
>> I won't approve it for use in the tree before it's written as a GLEP
>> in order to avoid the fiasco with EAPI 1 (it's still not documented 
>> properly). I can however approve the list of items.
> 
> What about the PMS EAPI 1 documentation do you consider 'not proper'?
> 

I am talking as in it's not documented anywhere readily available in 
*.gentoo.org. Everything in current PMS git is probably documented.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI-2

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petteri Räty wrote:
> Ciaran McCreesh kirjoitti:
>> On Tue, 09 Sep 2008 16:31:08 +0300
>> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>> Jorge Manuel B. S. Vicetto kirjoitti:
>>>> and cardoe's earlier request to the council ml, can the council
>>>> members discuss this proposal and consider voting it?
>>>> Does anyone have any objections to this proposal?
>>> I won't approve it for use in the tree before it's written as a GLEP
>>> in order to avoid the fiasco with EAPI 1 (it's still not documented
>>> properly). I can however approve the list of items.
>>
>> What about the PMS EAPI 1 documentation do you consider 'not proper'?
>>
> 
> I am talking as in it's not documented anywhere readily available in
> *.gentoo.org. Everything in current PMS git is probably documented.
> 
> Regards,
> Petteri
> 

Are you saying that the docs in my dev space don't count?

http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjIIZ0ACgkQ/ejvha5XGaO+lQCdER+OYtthh1jwq4dECeRZyU1M
gb8An3LjpxhUKj+9URGLCgmzfBsJXHpU
=Y36b
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2

[Petteri Räty]

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

Zac Medico kirjoitti:
> Petteri Räty wrote:
>> Ciaran McCreesh kirjoitti:
>>> On Tue, 09 Sep 2008 16:31:08 +0300
>>> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>>> Jorge Manuel B. S. Vicetto kirjoitti:
>>>>> and cardoe's earlier request to the council ml, can the council
>>>>> members discuss this proposal and consider voting it?
>>>>> Does anyone have any objections to this proposal?
>>>> I won't approve it for use in the tree before it's written as a GLEP
>>>> in order to avoid the fiasco with EAPI 1 (it's still not documented
>>>> properly). I can however approve the list of items.
>>> What about the PMS EAPI 1 documentation do you consider 'not proper'?
>>>
>> I am talking as in it's not documented anywhere readily available in
>> *.gentoo.org. Everything in current PMS git is probably documented.
> 
>> Regards,
>> Petteri
> 
> 
> Are you saying that the docs in my dev space don't count?
> 
> http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1
> 

They don't have any official status as far as I know.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI-2

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Petteri Räty wrote:
> Zac Medico kirjoitti:
>> Petteri Räty wrote:
>>
>> Are you saying that the docs in my dev space don't count?
>>
>> http://dev.gentoo.org/~zmedico/portage/doc/portage.html#package-ebuild-eapi-1
>>
>>
> 
> They don't have any official status as far as I know.

Fair enough. Anyway, they are available for consideration.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjITKgACgkQ/ejvha5XGaO2KACdEq+y6Aoxk4AwVdWsrAHY9nK4
GWEAniiLjimhiOF2BZCXo8UVpBpCQcik
=0VoB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2

[Luca Barbato]

Jorge Manuel B. S. Vicetto wrote:
> Hi again.
> 
> Quoting Zac earlier in #gentoo-portage:
> 
> 21:46 < zmedico> jmbsvicetto: I think we essentially have a spec already
> that people can agree on. just take my draft and subtract the eapi*
> functions and the gitweb unpack extension.

I don't see any problems with it.

lu

-- 

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Mon, 08 Sep 2008 23:34:28 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> So we're talking about adding the following to EAPI-2:

Are we treating PROPERTIES as purely optional and having no defined
values for EAPI 2 then?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Mon, 08 Sep 2008 23:34:28 +0000
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
>> So we're talking about adding the following to EAPI-2:
> 
> Are we treating PROPERTIES as purely optional and having no defined
> values for EAPI 2 then?

You are correct.

- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjJQ8EACgkQ/ejvha5XGaPIegCeIx6YqAgAU8rtCyL5ZRKgTcJ0
49oAn3vVIszYOlAuMAdUUlqgHhWJMSdk
=0/4+
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2

[Tobias Scherbaum]

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

Luca Barbato wrote:
> Jorge Manuel B. S. Vicetto wrote:
> > Hi again.
> > 
> > Quoting Zac earlier in #gentoo-portage:
> > 
> > 21:46 < zmedico> jmbsvicetto: I think we essentially have a spec already
> > that people can agree on. just take my draft and subtract the eapi*
> > functions and the gitweb unpack extension.
> 
> I don't see any problems with it.

+1

  Tobias

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Mon, 08 Sep 2008 23:34:28 +0000
"Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> Given the earlier discussion about EAPI-2 in
> http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml
> and cardoe's earlier request to the council ml, can the council
> members discuss this proposal and consider voting it?
> Does anyone have any objections to this proposal?

I've prepared patches for PMS for this lot. They can be found on the
branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we
use these as the definitive definition?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Tue, 9 Sep 2008 22:14:57 -0400
Jim Ramsay <lack@gentoo.org> wrote:
> I was personally expecting to see some sort of section called "EAPI-1"
> that contains something like:
> 
> "EAPI-1 consists of EAPI-0 with the following features added..."

Have a look at the eapi-differences-summary branch on
git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
you're after?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Doug Goldstein]

Tobias Scherbaum wrote:
> Luca Barbato wrote:
>   
>> Jorge Manuel B. S. Vicetto wrote:
>>     
>>> Hi again.
>>>
>>> Quoting Zac earlier in #gentoo-portage:
>>>
>>> 21:46 < zmedico> jmbsvicetto: I think we essentially have a spec already
>>> that people can agree on. just take my draft and subtract the eapi*
>>> functions and the gitweb unpack extension.
>>>       
>> I don't see any problems with it.
>>     
>
> +1
>
>   Tobias
>   
+1

Re: [gentoo-dev] EAPI-2

[Michael Hammer]

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

Hi folks!

I am not involved in creating the EAPI 2 draft but I am interested in
the discussion and would like to track the technical evolution but
this seams nearly impossible as you're not able to agree on a public
draft document.

* Ciaran McCreesh <ciaran.mccreesh@googlemail.com> [080911 20:02]:
> On Mon, 08 Sep 2008 23:34:28 +0000
> "Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org> wrote:
> > Given the earlier discussion about EAPI-2 in
> > http://archives.gentoo.org/gentoo-dev/msg_3e9d42191c3537c4f699c12cadd0ad99.xml
> > and cardoe's earlier request to the council ml, can the council
> > members discuss this proposal and consider voting it?
> > Does anyone have any objections to this proposal?
> 
> I've prepared patches for PMS for this lot. They can be found on the
> branch 'eapi-2' at git://git.overlays.gentoo.org/proj/pms.git . Can we
> use these as the definitive definition?

So my request to the council is not a technical decision on the
content itself but at least a decision about which document is the
official draft.

So here are my suggestions: (which are an enhancement over the GLEP
process)

- An official (by the council accepted) VCS repo (a la git) for the
  document (EAPI draft or even the PMS spec?)

- An interface (mailing address) where everyone interested can submit
  a patch for this document and a herd which is responsible for
  maintaining and merging the patches if accepted. (<- we need a
  procedure especially for the accept of patches. Voting, council
  decision, herd decision)

- A project page where the patches are published (and evtl. can be
  voted) and the HEAD is public readable

- The technical discussion can then be made in mailing list but then
  every dev has a possibility to follow the technical issues in a
  concentrated way and we have a place where we can cite and ref to.

- To make this work any other document or source for drafts has to be
  declined and not discussed (this seams hard but is IMHO the only way
  to make things work)

So long and thx for all the fish,

mueli

p.S.: If I missed something and something I mentioned already exists
then please correct me or forget my request but please be also so kind
and publish in a documentation (perhaps somewhere at [1]) where to
find informations on the EAPI process.

[1] ... http://www.gentoo.org/doc/en/list.xml

-- 
------------------------------------------------------------
Michael Hammer    |    <mueli@gentoo.org>     |     Graz, AT
Geno's Developer (Kerberos)  |  http://www.michael-hammer.at
 LocalWords:  Kerberos

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Fri, 12 Sep 2008 08:28:52 +0200
Michael Hammer <mueli@gentoo.org> wrote:
> - An official (by the council accepted) VCS repo (a la git) for the
>   document (EAPI draft or even the PMS spec?)

Uh, already exists.

> - An interface (mailing address) where everyone interested can submit
>   a patch for this document and a herd which is responsible for
>   maintaining and merging the patches if accepted. (<- we need a
>   procedure especially for the accept of patches. Voting, council
>   decision, herd decision)

Already exists.

> - A project page where the patches are published (and evtl. can be
>   voted) and the HEAD is public readable

Already exists.

> - The technical discussion can then be made in mailing list but then
>   every dev has a possibility to follow the technical issues in a
>   concentrated way and we have a place where we can cite and ref to.

Already happens.

> p.S.: If I missed something and something I mentioned already exists
> then please correct me or forget my request but please be also so kind
> and publish in a documentation (perhaps somewhere at [1]) where to
> find informations on the EAPI process.

How much research did you do before sending your email? Did you read
"EAPI and PMS for people who haven't been paying attention"?

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Jim Ramsay]

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

Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> On Tue, 9 Sep 2008 22:14:57 -0400
> Jim Ramsay <lack@gentoo.org> wrote:
> > I was personally expecting to see some sort of section called
> > "EAPI-1" that contains something like:
> > 
> > "EAPI-1 consists of EAPI-0 with the following features added..."
> 
> Have a look at the eapi-differences-summary branch on
> git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
> you're after?

From what I could make out of the raw latex code, yes!

Unrelated topic:  What packages are actually required to 'make pms.pdf'
so I can actually read it?  I get:

! LaTeX Error: File `appendix.sty' not found.

-- 
Jim Ramsay
Gentoo Developer (rox/fluxbox/gkrellm)

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

[gentoo-dev] Re: EAPI-2

[Ali Polatel]

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

Jim Ramsay yazmış:
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 9 Sep 2008 22:14:57 -0400
> > Jim Ramsay <lack@gentoo.org> wrote:
> > > I was personally expecting to see some sort of section called
> > > "EAPI-1" that contains something like:
> > > 
> > > "EAPI-1 consists of EAPI-0 with the following features added..."
> > 
> > Have a look at the eapi-differences-summary branch on
> > git://git.overlays.gentoo.org/proj/pms.git . Is that roughly what
> > you're after?
> 
> From what I could make out of the raw latex code, yes!
> 
> Unrelated topic:  What packages are actually required to 'make pms.pdf'
> so I can actually read it?  I get:
> 
> ! LaTeX Error: File `appendix.sty' not found.
> 

Use dev-tex/texmfind.
alip@trippin> texmfind appendix.sty
dev-texlive/texlive-latexextra [1 file]
appendix.sty

> -- 
> Jim Ramsay
> Gentoo Developer (rox/fluxbox/gkrellm)

-- 
Regards,
Ali Polatel

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Fri, 12 Sep 2008 14:14:51 -0400
Jim Ramsay <lack@gentoo.org> wrote:
> Unrelated topic:  What packages are actually required to 'make
> pms.pdf' so I can actually read it?  I get:

Have a look at the dependencies for app-doc/pms.

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Carsten Lohrke]

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

On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
> ~ * The meaning of the !atom blocker syntax now implies that
> ~   temporary simultaneous installation of conflicting packages is
> ~   allowed [3].
>
> ~ * A new !!atom blocker syntax is now supported, for use in special
> ~   cases in which temporary simultaneous installation of conflicting
> ~   packages should not be allowed.

I didn't really look into the issues, intended to be resolved with this, but 
I'm somewhat suspecious that this is merely a hack around inaccurate 
dependency listing in ebuilds on the one side and Portage's dependency 
resolver issues on the other. 

What I do strongly oppose is changing the meaning of the '!' symbol, as 
blockers, which should remain real blockers will not be adjusted by us, when 
changing an ebuild to EAPI 2++ in every case, since we're humans after all. 
So, if you implement this, keep '!' as is and find another symbol for 
these "soft" blockers.

> ~ * A new src_prepare phase function is called after src_unpack.
>
> ~ * The old src_compile phase function is split into separate
> ~   src_configure and src_compile fuctions.

All I do see is more complexity, but no real benefit.


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev] Re: EAPI-2

[Duncan]

Carsten Lohrke <carlo@gentoo.org> posted
200809141621.11069.carlo@gentoo.org, excerpted below, on  Sun, 14 Sep 2008
16:21:03 +0200:

> What I do strongly oppose is changing the meaning of the '!' symbol, as
> blockers, which should remain real blockers will not be adjusted by us,
> when changing an ebuild to EAPI 2++ in every case, since we're humans
> after all. So, if you implement this, keep '!' as is and find another
> symbol for these "soft" blockers.

I had wondered about that, but since no devs were bringing it up, I 
thought it must not be as big a deal as I had thought.  Now one has.

>> ~ * A new src_prepare phase function is called after src_unpack.
>>
>> ~ * The old src_compile phase function is split into separate ~  
>> src_configure and src_compile fuctions.
> 
> All I do see is more complexity, but no real benefit.

This is from a user's perspective, but there's a significant benefit to 
people with poor hardware.

I began my Gentoo journey with memory that only marginally supported the 
bandwidth it was rated for and had to live with the related crashes, 
reboots, and restart-the-emerges.  As such, I quickly learned the 
benefits of ccache and ebuid's step-by-step process.  I sure could have 
used a separate configure step at that point!  

With configure separate, it wouldn't have had to be redone each time I 
crashed and had to restart. I could and often did re-issue the half 
completed make commands by hand, letting the package's own build system 
pick up where it left off, but that didn't fill in the blanks in 
portage's package data, and I had to reissue the ebuild compile command 
to do so.  Only compile meant reconfigure too, which of course touched 
the various makefiles, forcing a recompile of the whole thing again -- 
and another chance at a crash while doing so.  If configure had been a 
separate stage, all those makefiles wouldn't have been touched and the 
package's build system would have seen that everything was built already, 
which would have saved me an AWFUL lot of trouble.

The unpack/prepare split wouldn't have been quite as useful as that was 
generally fast and crash resistant enough I didn't have problems with it, 
but it won't hurt, and would make user modification of existing ebuilds 
slightly easier.

As for the dev perspective, based on my ebuild hacking to date, I can see 
a significant benefit for the two spits there as well.  That the new 
phases match natural steps in most upstream package build processes where 
Gentoo formerly merged steps makes it that much simpler to trace down 
bugs when something goes wrong.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] EAPI-2

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
> On Dienstag, 9. September 2008, Jorge Manuel B. S. Vicetto wrote:
>> ~ * The meaning of the !atom blocker syntax now implies that
>> ~   temporary simultaneous installation of conflicting packages is
>> ~   allowed [3].
>>
>> ~ * A new !!atom blocker syntax is now supported, for use in special
>> ~   cases in which temporary simultaneous installation of conflicting
>> ~   packages should not be allowed.
> 
> I didn't really look into the issues, intended to be resolved with this, but 
> I'm somewhat suspecious that this is merely a hack around inaccurate 
> dependency listing in ebuilds on the one side and Portage's dependency 
> resolver issues on the other. 

Well, I'm open to alternative suggestions. Please see the previous
email in which I've attempted to explain the reasoning for the given
approach [1]. It seems to me that this approach is well suited for
solving cases in which temporary simultaneous installation of
blocking packages is needed.

> What I do strongly oppose is changing the meaning of the '!' symbol, as 
> blockers, which should remain real blockers will not be adjusted by us, when 
> changing an ebuild to EAPI 2++ in every case, since we're humans after all. 
> So, if you implement this, keep '!' as is and find another symbol for 
> these "soft" blockers.

Again, please see my previous email on this subject [1]. The reason
that I think we should change the meaning of the '!' symbol is that
the majority of existing EAPI 0 or 1 blockers appear to fit the new
meaning already. So, we'll only have to use the new !!atom syntax
for special cases in which temporary simultaneous installation of
blocking packages must be explicitly forbidden.

>> ~ * A new src_prepare phase function is called after src_unpack.
>>
>> ~ * The old src_compile phase function is split into separate
>> ~   src_configure and src_compile fuctions.
> 
> All I do see is more complexity, but no real benefit.

My impression is that most people tend to see these as useful
extensions despite the slight increases in complexity.

> 
> Carsten

[1]
http://archives.gentoo.org/gentoo-dev/msg_2551bea5c002093d5bacc26723208d93.xml
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjNR5sACgkQ/ejvha5XGaPR0gCgkiG7H4HZ4ASh/SyLboFGTCix
50EAmwU6WWU3gx5GV+EU1NqRmY+s4fDb
=rbQz
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI-2

[David Leverton]

On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
> Tobias Scherbaum wrote:
> > Luca Barbato wrote:
> >> I don't see any problems with it.
> >
> > +1
> >
> >   Tobias
>
> +1

Since this latest version hasn't generated any noticeable disagreement, could 
the Council please formally vote on it at the next meeting?

Re: [gentoo-dev] EAPI-2

[Petteri Räty]

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

David Leverton kirjoitti:
> On Thursday 11 September 2008 21:06:48 Doug Goldstein wrote:
>> Tobias Scherbaum wrote:
>>> Luca Barbato wrote:
>>>> I don't see any problems with it.
>>> +1
>>>
>>>   Tobias
>> +1
> 
> Since this latest version hasn't generated any noticeable disagreement, could 
> the Council please formally vote on it at the next meeting?
> 

Hopefully someone formats it to a real GLEP before that.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Sun, 14 Sep 2008 23:51:11 +0300
Petteri Räty <betelgeuse@gentoo.org> wrote:
> Hopefully someone formats it to a real GLEP before that.

git clone git://git.overlays.gentoo.org/proj/pms.git
git diff origin/master..origin/eapi-2

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Carsten Lohrke]

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

On Sonntag, 14. September 2008, Zac Medico wrote:
> Well, I'm open to alternative suggestions. Please see the previous
> email in which I've attempted to explain the reasoning for the given
> approach [1]. It seems to me that this approach is well suited for
> solving cases in which temporary simultaneous installation of
> blocking packages is needed.

Thanks for pointing me to it, Zac. I do not pretend to be able to pull the 
white bunny out of the black hat, presenting you the perfect alternative, 
especially since you've thought about it a lot more than me. I just feel 
uncomfortable, having ebuilds overwrite each others files. According to the 
referenced data, it'll work around a number of issues. The time will show, If 
real hard blocker issues remain a problem, I guess.


> Again, please see my previous email on this subject [1]. The reason
> that I think we should change the meaning of the '!' symbol is that
> the majority of existing EAPI 0 or 1 blockers appear to fit the new
> meaning already. So, we'll only have to use the new !!atom syntax
> for special cases in which temporary simultaneous installation of
> blocking packages must be explicitly forbidden.

Just the majority or pretty much all and the others are easily to find out and 
moved to EAPI 2, so the point I raised ceases to exist!?


I want to share another thought regarding this proposed addtion:

!! has the double meaning a) "unmerge the following ebuilds later" and 
b) "overwriting files of the following ebuilds while merging changes makes 
them owned by the freshly merged ebuild"

so we have one symbol denoting two different commands, which could find use 
independently. Moreso, if we add more of these symbols to express something 
different, our syntax may look almost like Lisp in the end:

 use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) )

Looks ugly, doesnt it? 

How about using two symbols for !! and having the possibility to aggreagate 
them, e.g.

use? ( !XY||: ( ( foo bar ) baz ) )

instead?!


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Donnie Berkholz]

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

On 21:55 Sun 14 Sep     , Ciaran McCreesh wrote:
> On Sun, 14 Sep 2008 23:51:11 +0300
> Petteri Räty <betelgeuse@gentoo.org> wrote:
> > Hopefully someone formats it to a real GLEP before that.
> 
> git clone git://git.overlays.gentoo.org/proj/pms.git
> git diff origin/master..origin/eapi-2

Ciaran, could you merge eapi-differences-summary into eapi-2 to address 
Petteri's concern about specifying EAPI differences in one place? Or 
just merge both of them into master.

It would also be extremely useful to have some way to discriminate the 
status of each EAPI (perhaps in the same appendix): approved, draft, or 
in progress.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Sun, 14 Sep 2008 15:28:09 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> On 21:55 Sun 14 Sep     , Ciaran McCreesh wrote:
> > On Sun, 14 Sep 2008 23:51:11 +0300
> > Petteri Räty <betelgeuse@gentoo.org> wrote:
> > > Hopefully someone formats it to a real GLEP before that.
> > 
> > git clone git://git.overlays.gentoo.org/proj/pms.git
> > git diff origin/master..origin/eapi-2
> 
> Ciaran, could you merge eapi-differences-summary into eapi-2 to
> address Petteri's concern about specifying EAPI differences in one
> place? Or just merge both of them into master.

Alright, eapi-2 has the fancy table and eapi-differences-summary is
gone.

> It would also be extremely useful to have some way to discriminate
> the status of each EAPI (perhaps in the same appendix): approved,
> draft, or in progress.

Well, I'd say anything in master is final, and anything on a branch
isn't...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Donnie Berkholz]

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

On 23:35 Sun 14 Sep     , Ciaran McCreesh wrote:
> On Sun, 14 Sep 2008 15:28:09 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
> > Ciaran, could you merge eapi-differences-summary into eapi-2 to
> > address Petteri's concern about specifying EAPI differences in one
> > place? Or just merge both of them into master.
> 
> Alright, eapi-2 has the fancy table and eapi-differences-summary is
> gone.

Great, thanks!

> > It would also be extremely useful to have some way to discriminate
> > the status of each EAPI (perhaps in the same appendix): approved,
> > draft, or in progress.
> 
> Well, I'd say anything in master is final, and anything on a branch
> isn't...

How do I remove kdebuild-1 from the master build? We decided a while 
back that EAPIs not approved by the council shouldn't be in the approved 
spec.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Ciaran McCreesh]

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

On Sun, 14 Sep 2008 16:40:50 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> How do I remove kdebuild-1 from the master build? We decided a while 
> back that EAPIs not approved by the council shouldn't be in the
> approved spec.

pms.tex:

%%% Enable the below if you'd like to see KDEBUILD things.
\setboolean{ENABLE-KDEBUILD}{true}

I'd still like the people responsible for kdebuild to go ahead with
their plans to ask the council to approve it, though...

-- 
Ciaran McCreesh

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

Re: [gentoo-dev] EAPI-2

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Carsten Lohrke wrote:
> On Sonntag, 14. September 2008, Zac Medico wrote:
>> Well, I'm open to alternative suggestions. Please see the previous
>> email in which I've attempted to explain the reasoning for the given
>> approach [1]. It seems to me that this approach is well suited for
>> solving cases in which temporary simultaneous installation of
>> blocking packages is needed.
> 
> Thanks for pointing me to it, Zac. I do not pretend to be able to pull the 
> white bunny out of the black hat, presenting you the perfect alternative, 
> especially since you've thought about it a lot more than me. I just feel 
> uncomfortable, having ebuilds overwrite each others files. According to the 
> referenced data, it'll work around a number of issues. The time will show, If 
> real hard blocker issues remain a problem, I guess.

Since >=sys-apps/portage-2.1.5, heuristics have been used to allow
this behavior and there hasn't been a single report of it causing a
problem. Note that !atom will mean "_may_ be temporarily installed
simultaneously" rather than "_must_ be temporarily installed
simultaneously". Just because they _may_ be installed simultaneously
doesn't mean that it makes any sense to do so. It's only needed to
resolve a subset of cases (like bug 234886 [1]) and it's probably
best for the package manager to avoid doing it whenever possible.
When portage uses heuristics to trigger this behavior, as it does
when solving bug 234886 [1] automatically, it only uses this
approach when it finds that no viable alternative solution exists.

I might add that I consider these blocker extensions to have vital
importance since experience has show that manual resolution of
blockers is often difficult for users to accomplish on their own,
and even when they seek advice from others, they are often given
faulty advice. Most people just don't have the knowledge or
experience necessary to manually solve these types of problems
correctly. Even when the user does know how to manually solve the
problem correctly, it's an annoying task that's much better
automated. I consider lack of automatic resolution to be a severe
usability issue which upsets users and also increases supports costs
in the form of users complaining or seeking help in places like
{bugs,forums,lists}.gentoo.org.

>> Again, please see my previous email on this subject [1]. The reason
>> that I think we should change the meaning of the '!' symbol is that
>> the majority of existing EAPI 0 or 1 blockers appear to fit the new
>> meaning already. So, we'll only have to use the new !!atom syntax
>> for special cases in which temporary simultaneous installation of
>> blocking packages must be explicitly forbidden.
> 
> Just the majority or pretty much all and the others are easily to find out and 
> moved to EAPI 2, so the point I raised ceases to exist!?

It seems to me that the new !!atom syntax will only be needed in
relatively few cases, and it won't be hard for ebuild maintainers to
adjust to. I'm open to alternative suggestions though...

> I want to share another thought regarding this proposed addtion:
> 
> !! has the double meaning a) "unmerge the following ebuilds later" and 
> b) "overwriting files of the following ebuilds while merging changes makes 
> them owned by the freshly merged ebuild"
> 
> so we have one symbol denoting two different commands, which could find use 
> independently. Moreso, if we add more of these symbols to express something 
> different, our syntax may look almost like Lisp in the end:
> 
>  use? ( ! ( X ( Y ( || ( ( foo bar ) baz ) ) ) ) ) )
> 
> Looks ugly, doesnt it? 
> 
> How about using two symbols for !! and having the possibility to aggreagate 
> them, e.g.
> 
> use? ( !XY||: ( ( foo bar ) baz ) )
> 
> instead?!

Well, I suspect that you might be complicating things more than
necessary. I tend to think the syntax extensions that I've already
proposed are well suited to our needs.

[1] http://bugs.gentoo.org/show_bug.cgi?id=234886
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkjNpYMACgkQ/ejvha5XGaOMjgCgqAYk6eeMyLUOS9qdC0lZU8GK
uVMAn0/cf9xJPnAppok+AvkQ/99MGQhQ
=r1D/
-----END PGP SIGNATURE-----

[gentoo-dev] Re: EAPI-2

[Duncan]

Zac Medico <zmedico@gentoo.org> posted 48CDA584.6030600@gentoo.org,
excerpted below, on  Sun, 14 Sep 2008 17:00:04 -0700:

> I might add that I consider these blocker extensions to have vital
> importance since experience has show that manual resolution of blockers
> is often difficult for users to accomplish on their own,

++

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] EAPI-2

[Michael Hammer]

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

* Ciaran McCreesh <ciaran.mccreesh@googlemail.com> [080912 17:38]:
> How much research did you do before sending your email?

Obviously not enough. (sry for that)

> Did you read "EAPI and PMS for people who haven't been paying attention"?

No I didn't until now and thx for the hint.

But for me it's still questionable why we don't have a gentoo project
for this important task? (a git summary page is not a project page
IMHO). If someone wants to drop in into the task it's not easy as
information is scattered (IMHO). What are GLEPs for if not for gentoo
enhancements like a PMS draft and the fixation of location, type,
maintainer, modification interface of that document? I even would go
further and would say there should be a procedure for maintaining and
approval of the document and changes on them. (a bit more formal then
a mail with "could the council please discuss 'it'" somewhere in the
depth of a discussion thread)

cite form the mail:

"So far as I'm aware, everyone who's currently working on PMS is
working off this repository:"

That's not a formulation I would choose for an approved repository
location or am I missing a council decission?

Once again sry for the inconvenience caused, greets

mueli


-- 
------------------------------------------------------------
Michael Hammer    |    <mueli@gentoo.org>     |     Graz, AT
Gentoo Developer (Kerberos)  |  http://www.michael-hammer.at

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Jan Kundrát]

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

Michael Hammer wrote:
> But for me it's still questionable why we don't have a gentoo project
> for this important task? 

You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?

Cheers,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] EAPI-2

[Ulrich Mueller]

>>>>> On Mon, 15 Sep 2008, Jan Kundrát wrote:

>> But for me it's still questionable why we don't have a gentoo project
>> for this important task? 

> You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?

That's only a stub, but not a viable project page. It doesn't even
contain a pointer where to find the PMS document.

Ulrich

Re: [gentoo-dev] EAPI-2

[Michael Hammer]

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

* Ulrich Mueller <ulm@gentoo.org> [080915 12:08]:
> >>>>> On Mon, 15 Sep 2008, Jan Kundrát wrote:
> 
> >> But for me it's still questionable why we don't have a gentoo project
> >> for this important task? 
> 
> > You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?
> 
> That's only a stub, but not a viable project page. It doesn't even
> contain a pointer where to find the PMS document.

++

-- 
------------------------------------------------------------
Michael Hammer    |    <mueli@gentoo.org>     |     Graz, AT
Gentoo Developer (Kerberos)  |  http://www.michael-hammer.at

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Michael Hammer]

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

* Jan Kundrát <jkt@gentoo.org> [080915 11:51]:
> Michael Hammer wrote:
>> But for me it's still questionable why we don't have a gentoo project
>> for this important task? 
>
> You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?

Definitely not ;) I am missing content like:

- responsible devs
- a link to the document source
- the procedure description how the PMS is created
- summary of the history with the core changes for each release (EAPI)
aso.

All this API discussion has a bit of an "only for members" character
for me which is IMHO not the way it should be. I am pretty well
knowing that writing documentation is a big effort but that's what you
have to do if you want to create a standard. I also think that you
have to define procedures for modification, evaluation and decision
on drafts like we have for GLEPs.

The next point I am missing is a clean assignment of authority and
responsibility. That's of course clear if a procedure is defined.

g, mueli

-- 
------------------------------------------------------------
Michael Hammer    |    <mueli@gentoo.org>     |     Graz, AT
Gentoo Developer (Kerberos)  |  http://www.michael-hammer.at

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-dev] EAPI-2

[Doug Goldstein]

Jan Kundrát wrote:
> Michael Hammer wrote:
>> But for me it's still questionable why we don't have a gentoo project
>> for this important task? 
>
> You mean something like http://www.gentoo.org/proj/en/qa/pms.xml ?
>
> Cheers,
> -jkt
>
This page is incomplete and needs some more details added to it. The
Gentoo Council took this up at the last meeting on Sept 11th. and plan
to some details posted to gentoo-dev in the coming weeks. However, I've
been spearheading this a bit and I'm getting married this weekend and
then I have my honeymoon so, except things to be almost at a stand still
from me until October.

Re: [gentoo-dev] EAPI-2

[Petteri Räty]

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

Ciaran McCreesh kirjoitti:
> On Sun, 14 Sep 2008 15:28:09 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> On 21:55 Sun 14 Sep     , Ciaran McCreesh wrote:
>>> On Sun, 14 Sep 2008 23:51:11 +0300
>>> Petteri Räty <betelgeuse@gentoo.org> wrote:
>>>> Hopefully someone formats it to a real GLEP before that.
>>> git clone git://git.overlays.gentoo.org/proj/pms.git
>>> git diff origin/master..origin/eapi-2
>> Ciaran, could you merge eapi-differences-summary into eapi-2 to
>> address Petteri's concern about specifying EAPI differences in one
>> place? Or just merge both of them into master.
> 
> Alright, eapi-2 has the fancy table and eapi-differences-summary is
> gone.
>

Yeah this will do.

Regards,
Petteri


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]