Re: [gentoo-council] Agenda for the meeting of December 7th, 2009

[Ned Ludd]

On Sun, 2009-12-06 at 00:40 -0700, Denis Dupeyron wrote:
> Hi all,
>
> Here's the agenda for the meeting on Monday. Two topics didn't make it for this
> meeting. I will be addressing the reasons why this happened in a different
> email as I don't want to delay this agenda any longer. One obvious reason
> though is time: you'll see that it's pretty packed.

I have a work meeting that will conflict with this council meeting. I
have yet to find a suitable proxy so I'll just put in my votes/notes in
here by email.

However leio pointed out a vote by mail doesn't consider points made
during any discussion during the meeting. So if no objections from the
council I'd like to vote post meeting after reading the logs. But if
that not acceptable then here are my pre meeting votes.


> 1. Intro (5 minutes, including late arrivals)
>   1.1. Make sure somebody is logging
>   1.2. Roll call
>   1.3  Who wants to chair? I can volunteer if nobody doesn't as I know the
>        topics already.
>   1.4. Last chance for remarks on the agenda (in particular does anybody mind
>        extending the duration of topics as the timing is tight)
>
> 2. EAPI3 status (10 minutes)
>   Can we have an ETA? Even a vague one would help.
>
> 3. Prefix (15 minutes)
>   3.1. The prefix team has answered all questions (see full thread at [1]),
>        provided a PMS patch [2], and have a portage branch ready with most if
>        not all features. Vote for or against it. If voting against please
>        suggest improvements.
>   3.2. EAPI bump
>     3.2.1. Should we make a quick, prefix-specific EAPI bump?

3.2.1: Yes to the PM defining these variables internally.


>     3.2.2. Should we wrap together prefix plus whatever features of EAPI3 which
>            are already ready into an intermediate EAPI and ship that now?
3.2.2: Not really if getting a status update will come no sooner then
the meeting.

>     3.2.3. Should we add prefix to EAPI3 and ship it all together when what's
>            missing of EAPI3 is ready?

3.2.3: No reason to delay the introduction of the internal variables. 



> 4. GLEPs 58, 59, 60 and 61 (15 minutes)
>   Read more about this as well as a nice summary at [3]. Vote for or against
>   each of these 4 GLEPs. If voting against please suggest improvements and/or
>   alternatives.

This was asked to be handled in January vs Dec.
http://archives.gentoo.org/gentoo-dev/msg_da4bd914abf0d830cbd063328abf742f.xml

If we must vote then I would most likely have to go with.

58: Yes (obsolete sha1 in favor of sha512. keep sha256)
59: Yes
60|60: January (or reviewed the meeting after 58 & 59 are completed in
the tree)


> 5. mtime preservation (15 minutes)
>   Three alternatives have been proposed:
>   5.1. The package manager must preserve modification times of regular files.
>        This includes files being compressed before merging. Exceptions to this
>        are:
>         - Files newly created by the package manager
> 	- Binary object files being stripped of symbols
> 	- Maybe others
>        Depending on the exact wording and exceptions this can be made
>        equivalent to 5.3 below.
5.1: Yes || 5.3 
But this seems like a lot of overhead. Why not just tag the ebuilds
needing this behavior vs potentially slowing down the PM all the time? 
What are some real world cases of needing to keep the mtime? *.py[c|o]
files?


>   5.2. Let ebuilds call dopreservemtimes (with an API similar to docompress) in
>        both src_install and pkg_preinst. Doing so would instruct the package
>        manager that it must preserve mtimes (including subsecond, if supported
>        on the filesystem) for a particular set of paths, even if doing so means
>        no stripping etc. All other mtimes may be rewritten as the package
>        manager sees fit, and from this next EAPI onwards must be rewritten at
>        merge time for anything predating the start of the build.

5.2: No. This sounds overly complex

>   5.3. Just document precisely the current behavior of portage and what can be
>        relied upon.

5.3: Yes (as there seems to be no consensus among the PM devs on this
topic)