Re: [gentoo-dev] Gentoo Council Reminder for May 28

[Ferris McCormick]

On Wed, 2009-05-27 at 12:46 +0000, Ferris McCormick wrote:
> 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);
>
--- SNIP ---

I did not intend to set off another religious war with this.  I was
merely expressing my own opinion in response to the request from
Council.  But it seems every time GLEP55 is mentioned, there is a
cascade of emotional responses, but I don't see anything in GLEP55 worth
any sort of emotional response, so consider this directed at council.
If anyone has technical issues with it, please either make them as such
and leave out the personal attacks.

1.  For some reason, there were comments about the writing style used in
GLEP55.  Personally, I find it clear enough, and would expect that it
would be revised once Council settles on whether to adopt the proposed
solution or one of its alternatives. (That's why it's marked as a
draft.) In my opinion, as it stands it clearly shows the necessity for
it or its equivalent (one of the alternatives it mentions);

2.  I said that no matter what we do, I think we need a new extension;

3.  Personally, I prefer .eb (with eapi defined elsewhere)
to .ebuild-<eapi>, but I view that as more a matter of taste than a
major technical matter;

4.  Personally, I prefer ${PN}-${PVR}.eapi-<eapi>.eb (or a syntactic
equivalent); again, that is a matter of taste and performance;

5.  As an alternative, I have no problems with ${PN}-${PVR}.eb and using
#!eapi <eapi> as the first line of the .eb[uild] file.  In that case, I
suppose you could even follow through and source a program called
'eapi', but that's a PM implementation issue outside the scope of the
GLEP.  The argument against this is performance hit, I guess, and on
that I am not qualified to comment.

6.  My remarks about -scm were merely meant to show that once you
introduce the .eb extension, you can implement GLEP54 transparently in
whatever manner excites you.

As I said at the beginning, these are my personal preferences addressed
to Council in response to their request.  If others have preferences
which differ, please take them up with me (I am open to persuasion), and
please leave the emotion out of it.  But I think GLEP55 adequately makes
the case for it or one of the alternatives it mentions, so don't bother
arguing with me on that matter.  It's Council you need to convince, not
me.

Regards,
Ferris
-- 
Ferris McCormick (P44646, MI) <fmccor@g.o>
Developer, Gentoo Linux (Sparc, Userrel, Trustees)