Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   Council meeting summary for 10 July 2008 (http://www.linux-archive.org/gentoo-development/123850-council-meeting-summary-10-july-2008-a.html)

Donnie Berkholz 07-13-2008 07:11 AM

Council meeting summary for 10 July 2008
 
Hi all,

Here is the summary from Thursday's council meeting. The complete log
will show up at http://www.gentoo.org/proj/en/council/ shortly.

--
Thanks,
Donnie

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

GLEP 54: There were numerous questions that apparently were not brought
up on the mailing list in advance or were not addressed.

GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may be,
but that's unclear until it's been revised.

GLEP 56: Approved. Cardoe will get repoman changes made, followed by a
server-side script to generate use.local.desc from
metadata.xml.


The meeting wrapped up in under 1 hour again. We still need to work
harder to push more discussion and questions to the mailing list,
though.


Topics
======

GLEP 54
-------
Preparation: Post your opinion to the -dev thread "A few questions to
our nominees" 4+ hours before the meeting.

Last month:
dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml
lu_zero: http://archives.gentoo.org/gentoo-dev/msg_05614741b3942bfdfb21fd8ebb7955e0.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list
no later than July 17.

<Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
<Betelgeuse@> dberkholz: and older Portage versions work just fine

<Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0

< lu_zero@> dberkholz problem: if you have -scm installed
< lu_zero@> and then switch to a pm not knowing it
< lu_zero@> you have a nice recipe for inconsistency

< Halcy0n@> I would really like to see a list of features that we would
end up having after implementing this GLEP. The GLEP
mentions possible enhancements, but I'd like to see what we
would have planned if we go forward with this change.
< Halcy0n@> Well, it only mentions one enhancement, I'd like to see
what else we could do to judge if it is worth it.
Halcy0n@> Betelgeuse: yes, I know there are some things we could do,
but I'd like to see a more extensive list of possibilities,
what are other possible ways of doing this (like a metadata
tag for the ebuild), and why those other methods aren't
sufficient.

< dberkholz@> i think the point here is that the glep should address what
made its implementation superior to other possible ones,
which it also describes

< dberkholz@> ok, i've noted the issues raised here
< dberkholz@> once they're address, the glep can be revised and we'll
consider it again

Summary: Specific questions and requests are above.


GLEP 55
-------
Preparation: Post your opinion to the -dev thread "GLEP 55" 4+ hours
before the meeting.

Last month:
dberkholz: http://archives.gentoo.org/gentoo-dev/msg_c6e4ba8293f50c1e0444e67d59cf85ea.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list
once we're ready.

<Betelgeuse@> But I don't see the use of accepting it before we a)
Portage has something that would make use of it b) some
other pkg manager is made official
< Halcy0n@> So, can we vote on postponing a GLEP of this nature until
another glep requires such changes?

Summary: On hold pending a concrete requirement for it. GLEP 54 may be,
but that's unclear until it's been revised.


GLEP 56
-------
Preparation: Post your opinion to the -dev thread "[GLEP56] USE flag
descriptions in metadata" 4+ hours before the meeting. (Cardoe: Did the
requested updates ever get made?)

Last month:
dberkholz: http://archives.gentoo.org/gentoo-dev/msg_54ee20d2b1d8122370afdd4b3d7aafc9.xml

Goal: Status check at meeting to see who's ready to vote. Vote on-list
no later than July 17, if requested changes are made.

Requested changes were made:
http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0056.txt?r1=1.1&r2=1.2

< Cardoe > Well the first step of making that portion happen is going
to be to add a check to repoman that if use.local.desc is
not present in the repo, do new QA check.
< Cardoe > Once that's in place that developers can use, then the
infra script will happen.
< Cardoe > I've already discussed it with the Portage folks and the
infra folks.

Summary: Approved.


Roll call
=========

(here, proxy [by whom] or slacker?)

betelgeuse here
dberkholz here
dertobi123 here
flameeyes here
halcy0n here
jokey here
lu_zero here

Marius Mauch 07-13-2008 01:01 PM

Council meeting summary for 10 July 2008
 
On Sun, 13 Jul 2008 00:11:18 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:

> <Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for
> scm
> <Betelgeuse@> dberkholz: and older Portage versions work just fine

I thought we established that EAPI (no matter how it's defined) only
controls ebuild _contents_ ...

Marius
--
gentoo-dev@lists.gentoo.org mailing list

Doug Goldstein 07-13-2008 10:00 PM

Council meeting summary for 10 July 2008
 
Donnie Berkholz wrote:

Hi all,

Here is the summary from Thursday's council meeting. The complete log
will show up at http://www.gentoo.org/proj/en/council/ shortly.





With regard to GLEP 56. I've posted the necessary DTD changes, some
documentation changes (the old documentation patches need to be updated
to whats currently in CVS because some commits occurred between when
they were created and now), and the repoman patches to the bug [1].


My patches to repoman have already been committed to Portage trunk so
they'll appear in 2.2_rc2. pkgcore is being updated this weekend for
pcheck to support the new syntax according to ferringb. No one has
gotten back to me on paludis so I'm not sure about that status.


With regard to the DTD, it's a small change to allow the <cat> tag, the
rest are there already. As far as the docs team knows, neysx is the only
one that can commit to them. He's gone until September. So we might need
someone from infra to give another doc's team member the access to make
that commit.


Betelgeuse is committing the documentation patches as I update them for
the Gentoo Development Handbook. Halcy0n made a few requested updates to
the Gentoo Developer Manual. So that front is moving forward well.


I'll be working with robbat2 when he gets some free time this week on
getting the infra script I hacked up in place.


All and all I'd say we're moving forward on marking this GLEP as Final
pretty soon.


Biggest project left for me is to copy the current use.local.desc bits
into the respective metadata.xml's of each package. If maintainers want
to help, that'd be awesome.


[1] http://bugs.gentoo.org/show_bug.cgi?id=199788

--
Doug Goldstein <cardoe@gentoo.org>
http://dev.gentoo.org/~cardoe/
--
gentoo-dev@lists.gentoo.org mailing list

Ciaran McCreesh 07-13-2008 10:52 PM

Council meeting summary for 10 July 2008
 
On Sun, 13 Jul 2008 00:11:18 -0700
Donnie Berkholz <dberkholz@gentoo.org> wrote:
> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
> be, but that's unclear until it's been revised.

Which part of the 'Problem' section in the GLEP didn't you understand?
Do you seriously consider not being able to add or change global scope
functions in future EAPIs to be a non-issue, or were you ignoring those
two bullet points?

--
Ciaran McCreesh

"Alec Warner" 07-13-2008 11:16 PM

Council meeting summary for 10 July 2008
 
On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 13 Jul 2008 00:11:18 -0700
> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
>> be, but that's unclear until it's been revised.
>
> Which part of the 'Problem' section in the GLEP didn't you understand?
> Do you seriously consider not being able to add or change global scope
> functions in future EAPIs to be a non-issue, or were you ignoring those
> two bullet points?

I understood both.

As far as could be determined by the members at the meeting there no
compelling examples in Gentoo who to change or add global scope functions
in future EAPIs. As such those problems as stated are not in scope for Gentoo
because Gentoo is not attempting to do those things at this time.

>
> --
> Ciaran McCreesh
>
--
gentoo-dev@lists.gentoo.org mailing list

"Alec Warner" 07-13-2008 11:18 PM

Council meeting summary for 10 July 2008
 
On Sun, Jul 13, 2008 at 4:16 PM, Alec Warner <antarus@gentoo.org> wrote:
> On Sun, Jul 13, 2008 at 3:52 PM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Sun, 13 Jul 2008 00:11:18 -0700
>> Donnie Berkholz <dberkholz@gentoo.org> wrote:
>>> GLEP 55: On hold pending a concrete requirement for it. GLEP 54 may
>>> be, but that's unclear until it's been revised.
>>
>> Which part of the 'Problem' section in the GLEP didn't you understand?
>> Do you seriously consider not being able to add or change global scope
>> functions in future EAPIs to be a non-issue, or were you ignoring those
>> two bullet points?
>
> I understood both.
>
> As far as could be determined by the members at the meeting there no
> compelling examples in Gentoo who to change or add global scope functions
> in future EAPIs. As such those problems as stated are not in scope for Gentoo
> because Gentoo is not attempting to do those things at this time.

ugh, s/who//

>
>>
>> --
>> Ciaran McCreesh
>>
>
--
gentoo-dev@lists.gentoo.org mailing list

Ciaran McCreesh 07-13-2008 11:21 PM

Council meeting summary for 10 July 2008
 
On Sun, 13 Jul 2008 16:16:23 -0700
"Alec Warner" <antarus@gentoo.org> wrote:
> As far as could be determined by the members at the meeting there no
> compelling examples in Gentoo who to change or add global scope
> functions in future EAPIs. As such those problems as stated are not
> in scope for Gentoo because Gentoo is not attempting to do those
> things at this time.

You mean you don't want per-category/package eclasses, or eclasses that
can indicate that they only work with some EAPIs, or eclasses that can
indicate that they're being used incorrectly, or the death of
EXPORT_FUNCTIONS? All of these have been discussed as desirable future
extensions.

--
Ciaran McCreesh

"Alec Warner" 07-13-2008 11:37 PM

Council meeting summary for 10 July 2008
 
On Sun, Jul 13, 2008 at 4:21 PM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Sun, 13 Jul 2008 16:16:23 -0700
> "Alec Warner" <antarus@gentoo.org> wrote:
>> As far as could be determined by the members at the meeting there no
>> compelling examples in Gentoo who to change or add global scope
>> functions in future EAPIs. As such those problems as stated are not
>> in scope for Gentoo because Gentoo is not attempting to do those
>> things at this time.
>
> You mean you don't want per-category/package eclasses, or eclasses that
> can indicate that they only work with some EAPIs, or eclasses that can
> indicate that they're being used incorrectly, or the death of
> EXPORT_FUNCTIONS? All of these have been discussed as desirable future
> extensions.

I don't require any of those things, but maybe other people do and If
so; they should probably come
to the meeting or otherwise make themselves known because they were
not at the previous meeting.

The GLEP as written is not convincing; it doesn't say 'I am trying to
do X with Gentoo and cannot because of this
restriction.' It says 'In the future someone may want to do X and
they won't be able to because of this restriction so lets
try to remove the restriction now.' This is an admirable goal mind
you; but it is my opinion that there are more concrete features
that we could implement for benefits now rather than talk about what could be.

I chatted briefly with peper on IRC about this (as he was the original
GLEP author) so when he gets time he said he had some examples to
provide.

>
> --
> Ciaran McCreesh
>
--
gentoo-dev@lists.gentoo.org mailing list

Ciaran McCreesh 07-13-2008 11:43 PM

Council meeting summary for 10 July 2008
 
On Sun, 13 Jul 2008 16:37:35 -0700
"Alec Warner" <antarus@gentoo.org> wrote:
> I don't require any of those things, but maybe other people do and If
> so; they should probably come
> to the meeting or otherwise make themselves known because they were
> not at the previous meeting.

http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-libs/glibc/files/eblits/

I presume you're aware of that. People are already doing those other
things, and doing them badly, because there's currently no other option.
This isn't some hypothetical future requirement.

--
Ciaran McCreesh

Jeroen Roovers 07-14-2008 01:13 AM

Council meeting summary for 10 July 2008
 
On Mon, 14 Jul 2008 00:43:06 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> People are already doing those other things, and doing them badly,
> because there's currently no other option. This isn't some
> hypothetical future requirement.

When you wrote "doing them badly", did you mean to imply doing
something else than GLEP 55, or were you just slagging off whoever
implemented eblits in sys-libs/glibc?

In other words perhaps, is it your opinion that GLEP 55 needs to be
implemented because sys-libs/glibc requires an immediate rewrite? Are
there any bug reports that would be good examples of why this new
implementation is warranted?


JeR
--
gentoo-dev@lists.gentoo.org mailing list


All times are GMT. The time now is 04:58 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.