On Tue, 2009-05-26 at 20:57 +0200, Tiziano Müller wrote: > This is your friendly reminder! Same bat time (typically the 2nd & 4th > Thursdays at 2000 UTC / 1600 EST), same bat channel (#gentoo-council @ > irc.freenode.net) ! > > If you have something you'd wish for us to chat about, maybe even vote > on, let us know! Simply reply to this e-mail for the whole Gentoo dev > list to see. > > For more info on the Gentoo Council, feel free to browse our homepage: > http://www.gentoo.org/proj/en/council/ > > > Following is the preliminary meeting agenda. First we'll have to fill > the empty spot. After a short upgrade on EAPI-3 implementation we will > discuss the removal of old eclasses, followed by our old friend GLEP 55. > If we still have time we can dive into the topic of general EAPI > development. >
Because Piotr recently amended GLEP55 to provide some further
clarification and justification as well as to present a few alternatives
addressing some objections people have expressed, it seems to me that
the GLEP55 discussion should now go something like this:
1. Approve the concept in principle (I think Piotr's examples
sufficiently show the need for something along the lines set out in the
revised GLEP);
2. Choose one of the proposed solutions. For what it's worth, I favor
the new extension (package.ebuild --> package.eb), and then I think
something like ${PN}-${PVR}.eapi-${EAPI}.eb (or equivalent) is probably
best. Here, ${PVR} is perhaps in a new version format.
a. No introduced overhead;
b. Current PMs will not even see it;
c. I think there is an advantage for the users and developers to be
able to see the required eapi immediately without having to read all
the .eb (or .ebuild if you choose .ebuild-<EAPI>) files.
3. Approve the GLEP.
I would do the first quickly in order to cut off all the continual noise
on gentoo-dev@, and I really think the revised GLEP makes the case for
it well enough. After that, it should no longer be a religious issue,
and I optimistically would not expect step 2 to take long at all.
I note that the .eapi-${EAPI} part could well be optional, in which case
GLEP54 falls naturally into the new scheme as something like
${PN}-${PVR}-scm.eb
>
> Approval/voting of new council member replacing Donnie Berkholz
> ---------------------------------------------------------------
>
> Unfortunately Donnie resigned as a member of the council (for
> details please read his mail on the g-council ml). Next in line
> are ulm and ssuominen.
>
>
> EAPI 3: Short discussion of the progress
> ----------------------------------------
>
> zmedico will provide an update on the progress of the implementation. Short
> discussion of problems and implementation decisions if needed.
>
>
> Removing old eclasses
> ---------------------
>
> Goal: Decide whether developers are allowed to remove eclasses. Problem:
> Upgrading using portage with a version before 2.1.4 will fail since portage
> always used eclasses from the tree instead of the ones from environment.bz2,
> even though the environment fail has been generated. Portage 2.1.4 got stabled
> over a year ago.
>
>
> Handling EAPI versioning in a forwards-compatible way
> -----------------------------------------------------
>
> Goal: Discuss whether one of the alternatives given in GLEP 55 is appropriate
> to solve the problem. Decide which one should be chosen.
>
>
> Define EAPI development/deployment cycles
> -----------------------------------------
>
> Goal: Start discussion about EAPI development/deployment. For example:
> Collect problems of eapi introductions in the past, like reverting
> ebuilds to former eapis to get them stable, not waiting for the pm
> support a certain eapi before requesting stable keywords for ebuilds
> using the new eapi, .... Collect problems of EAPI development like
> feature-freeze, late feature removals (due to implementation problems).
> Eventually develop a lightweight EAPI development model.
>
>
> Cheers,
> Tiziano
Regards,
Ferris
--
Ferris McCormick (P44646, MI) <fmc...@gentoo.org>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)
signature.asc
Description: This is a digitally signed message part
