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

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

[Denis Dupeyron]

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.

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.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.3. Should we add prefix to EAPI3 and ship it all together when what's
           missing of EAPI3 is ready?

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.

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.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.3. Just document precisely the current behavior of portage and what can be
       relied upon.
  Note that none of these propositions have a solution for subsecond resolution
  requirements. But note also that no package could be identified as having
  such requirement yet. Do we care?

6. Wrap-up (5 minutes)
  6.1. Who is in charge of the logs? The summary?
  6.2. Date/time next meeting? Should we delay by one week to let our bodies
       recover from the end-of-year festivities?
  6.3. Who will follow-up topics and write the agenda for the next meeting?

7. Open floor (ad libitum)

See you Monday at 1900UTC.
Denis.

[1] http://archives.gentoo.org/gentoo-dev/msg_2a62689c71f95e4de5699a330b8b5524.xml
[2] http://archives.gentoo.org/gentoo-dev/msg_62b5df924d6e9e74c94149e7e7f17d23.xml
[3] http://archives.gentoo.org/gentoo-dev/msg_da4bd914abf0d830cbd063328abf742f.xml

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

[Ulrich Mueller]

>>>>> On Sun, 6 Dec 2009, Denis Dupeyron wrote:

> 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.

Shouldn't GLEP 57 be included in this list (although it's only
informational)?

> 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

In case we accept 5.1., I suggest that we delegate it to the Portage
team to produce a list (which can also be empty) of the "maybe others"
files.

>        Depending on the exact wording and exceptions this can be
>        made equivalent to 5.3 below.

Right, that's the intention of it.

We should also consider including this in EAPI 0 retroactively, as
suggested by Zac in [1]. Look at the following sequence of events:

  2007-07-28  Portage 2.1.3 is released, preserving mtimes when
              merging (if release candidates are counted, then the
              date is even earlier [2]).

  2008-05-08  PMS allows that file modification times are discarded. [3]

>   Note that none of these propositions have a solution for subsecond
>   resolution requirements. But note also that no package could be
>   identified as having such requirement yet. Do we care?

I don't.

Ulrich

[1] <http://archives.gentoo.org/gentoo-dev/msg_daf1b54f428f6a07cff96aedc9693b78.xml>
[2] <http://bugs.gentoo.org/show_bug.cgi?id=83877#c37>
[3] <http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=de6ee9c6ad50d4d130e9ad02f31bddced15293f4>

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

[David Leverton]

On Sunday 06 December 2009 11:48:13 Ulrich Mueller wrote:
> >        Depending on the exact wording and exceptions this can be
> >        made equivalent to 5.3 below.
>
> Right, that's the intention of it.

The intention is to make the spec for a new EAPI unnecessarily complex, just 
to avoid changing an existing implementation?

> We should also consider including this in EAPI 0 retroactively

Doing things like that defeats the purpose of EAPI.

>   2007-07-28  Portage 2.1.3 is released, preserving mtimes when
>               merging (if release candidates are counted, then the
>               date is even earlier [2]).

This was long after EAPI was invented, so it should have gone in with an EAPI 
bump.

>   2008-05-08  PMS allows that file modification times are discarded. [3]

That commit changed the wording from "Other file attributes may be discarded" 
to "Other file attributes, including modification time, may be discarded".  
Modification time was already included in the phrase "other file attributes", 
all the change did was to clarify it.

Also note that just because something isn't mentioned in PMS doesn't mean it's 
OK to go off and do whatever you feel like, without regard for compatibility, 
especially if it's a long-standing, well-defined behaviour like "reset mtimes 
to the current time".  People are expected to use common-sense when reading 
it (since we don't have enough man-power to make it completely airtight), not 
deliberately misinterpret it to support their own agenda (last part not 
directed at you, but that sort of behaviour has happened in the past).

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

[Ulrich Mueller]

>>>>> On Sun, 6 Dec 2009, David Leverton wrote:

> The intention is to make the spec for a new EAPI unnecessarily
> complex, just to avoid changing an existing implementation?

The spec first proposed was along the lines "mtime is updated if
(and only if) the package manager modifies the file" [1], but the
Paludis party raised objections that this was not specific enough.
But see below about "common sense".

>> We should also consider including this in EAPI 0 retroactively

> Doing things like that defeats the purpose of EAPI.

Normally I would agree with this. However, in this particular case the
damage has already been done. We wouldn't break anything by applying
this retroactively. The breakage of packages will go away in the
moment when all package managers preserve mtimes, independent of what
we write into the spec. So we could as well keep it simple (i.e.
without distinction between EAPIs).

> People are expected to use common-sense when reading it (since we
> don't have enough man-power to make it completely airtight), [...]

I fully agree. If such wisdom had been used earlier, the whole issue
would long be off the stove.

Ulrich

[1] <http://bugs.gentoo.org/264130#c41>

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

[David Leverton]

On Sunday 06 December 2009 14:05:59 Ulrich Mueller wrote:
> The spec first proposed was along the lines "mtime is updated if
> (and only if) the package manager modifies the file" [1], but the
> Paludis party raised objections that this was not specific enough.
> But see below about "common sense".

It's not specific enough because it gives the implementer no way of knowing 
which files don't require preservation, and therefore, which are safe to 
modify without preserving the mtime.  Common sense doesn't come into it.

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

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Sun, Dec 06, 2009 at 12:48:13PM +0100, Ulrich Mueller wrote:
> >>>>> On Sun, 6 Dec 2009, Denis Dupeyron wrote:
> > 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.
> Shouldn't GLEP 57 be included in this list (although it's only
> informational)?
Yes, GLEP57 should be voted on as well.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 330 bytes --]

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

[Denis Dupeyron]

On Sun, Dec 6, 2009 at 10:18 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Sun, Dec 06, 2009 at 12:48:13PM +0100, Ulrich Mueller wrote:
>> >>>>> On Sun, 6 Dec 2009, Denis Dupeyron wrote:
>> > 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.
>> Shouldn't GLEP 57 be included in this list (although it's only
>> informational)?
> Yes, GLEP57 should be voted on as well.

OK, let's add GLEP 57 then. However I was just told this was only
requested for January's meeting. So if everybody agrees, and since
discussing 5 GLEPs might take more time than the allotted 15 minutes,
this should be moved to the open floor session as suggested by solar.

I would also like to add the following:
1.5. Should we accept votes by email sent before the meeting?

The reason is that solar may not be able to attend the meeting and is
having trouble finding a proxy. In which case he offered to send his
votes by email. The inevitable question after the latter is: "Should a
council member voting by email be considered having missed the
meeting?" Let's keep that for another time though. There's enough on
our plate for this meeting.

Denis.

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)

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

[Zac Medico]

Denis Dupeyron wrote:
> 2. EAPI3 status (10 minutes)
>   Can we have an ETA? Even a vague one would help.

I guess about 3 months or so, but it's hard to say. See tracker bug
here as usual: http://bugs.gentoo.org/show_bug.cgi?id=273620.

While we're on this topic, I think we may want to consider dropping
the slot-operator dependencies that are currently in the EAPI 3
spec, in favor of a abi-slot-operator dependency [1] that is
generically useful for many cases in which reverse dependencies need
to be rebuilt [2].

[1] http://bugs.gentoo.org/show_bug.cgi?id=192319#c10
[2]
http://archives.gentoo.org/gentoo-dev/msg_071fb09fd5459e52de70826404f1fdcd.xml
-- 
Thanks,
Zac