[gentoo-dev] Re: GLEP 55 Version 2

2009-06-06 Thread Steven J Long
Roy Bamford wrote:
> I've spent some time reading all of this years emails on GLEP55 and
> added a few lines to version 1.5 which is the last offical version.
>
Thanks for all the hard work.

My apologies for my mistaken comment at the end of the last Council meeting.
Clearly the mangler /does/ need to know the EAPI without sourcing for future
extensibility.

I'd just like to know what the implications would be for users if we kept
the .ebuild extension, and a new PMS were rolled out stating that the
mangler were allowed to find the EAPI without sourcing (and giving the
restrictions) once portage 2.2 was stable, or the ability to handle this
backported to 2.1.6, and issued in a release?

Would it be unacceptable to have a clear upgrade path for any users who
didn't actually update portage? (Perhaps a news item so they'd be
notified as and when they ran emerge.)

It strikes me that we went through a similar situation with bash-3.17 I
think it was, and that once we're past this, there'll never be any need
to worry in the future. So, given that it's taken so long and so much
discussion, why not just do this last big bump, and not worry about
about using another extension at all?

After all, the issue would only arise once Council approved an EAPI
requiring one of the incompatible changes, and 3 has only recently come
out.

Also, you asked for proponents of either side to provide statistics as to
the time difference between the various options. It's rather hard for me
to patch paludis, nor do I have the inclination. I am not being facetious,
simply pointing out that the comparison has to be made within a single app.
Comparing an approach implemented in portage vs one in paludis is comparing
apples and oranges.

Also, Patrick brought up cache improvements (like not having a single cache
file per ebuild, but rather per package. This could have the EAPI and
versions first, followed by metadata per version.) I feel we should bear in
mind that there are other areas where we can improve things, many of which
we have not even thought of, or at least discussed.

With respect to time gains in interactivity, much has been made of the
speed difference between portage and paludis. I have yet to see any
comparative numbers between pkgcore and paludis in this regard. (If we are
going to compare manglers and not algorithms.)

I think we are agreed now that an EAPI which can be extracted before source
does fulfil all the criteria (as others have said, this is actually what the
GLEP is about; ascertaining the EAPI without needing to source.) If not,
could someone please explain why not.

Regards,
Steve.
--
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)




[gentoo-dev] GLEP 55 Version 2

2009-06-06 Thread Roy Bamford
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ladies and Gentlemen,

I've spent some time reading all of this years emails on GLEP55 and 
added a few lines to version 1.5 which is the last offical version.

The HTML version (not with the GLEP style sheet) is at 
http://xrl.us/bevrnb (my devspace)
Its not ready to go to council as it still needs additional content 
which I don't have the background to contribuite. My role in this 
version of GLEP 55 has been interpretation and editorial.

I'm looking for three elements to add.

1. A description of the steps the PM needs to extract the EAPI in 
ebuilds today, if its any more than sourcing the ebuild.

2. Benchmarks and supporting code for EAPI extraction for EAPI in the 
filename.

3. Benchmarks and supporting code for EAPI extraction for EAPI in the 
ebuild.

Benchmarks for valid and invalid cache need to be supplied so we have 
both the user and developer views of performace. 

I expect items 2 and 3 to be provided by the proponents of these two 
competing options and critically examined for validity by the 
competitors.

When the above data is available, I'll update the document as it needs 
to contain all of the evidence to allow council to reach a decision 
without reading the ml. 

Reply with corrections and factual additions with supporting evidence 
only please. The role of the GLEP is to present the evidence and make a 
reccomendation. Its councils job to make any subjective assessments 
having read the GLEP.

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkoq7l8ACgkQTE4/y7nJvatqjQCeNe/mqS8goPZ5+H4yftn19mYJ
5i0AoLwsAmKcc6Ux4zjG3dExgRbcltwl
=edR+
-END PGP SIGNATURE-




Re: [gentoo-dev] Gentoo Council 2009/2010 - Nominations are now open

2009-06-06 Thread Raúl Porcel
Ferris McCormick wrote:
> I nominate:
> ssuominen
> armin76
> 
> Perhaps others later.
> 
> Regards,
> Ferris

Thanks but I decline.