[gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Ulrich Mueller]

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

>>>>> On Mon, 26 May 2014, Rich Freeman wrote:

> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC.
> Please reply to this email with any proposed agenda items.

I would like the council to approve a preliminary list of features
for EAPI 6, so that the PMS team then can start to work on the
specification.

Of course, the finished PMS spec for EAPI 6 will be brought before the
council again, for final approval.

Here is the list of candidate features, taken from the Wiki page [1]:

1. New features

   a) get_libdir()
        Bug #463586 [2]
        - Used in econf, but so far not available as separate PM function.

   b) einstalldocs()
        Bug #459692 [3]

   c) Query function for IUSE_EFFECTIVE
        Bug #449862 [4]

   d) PATCHES support in default src_prepare()
        Bug #463692 [5]
        - Needs 4a)

2. Extensions to existing features:

   a) nonfatal die()
        Bug #451938 [6]

   b) Allow empty DOCS variable
        Bug #463736 [7]

   c) Directory support for DOCS
        Bug #481980 [8]

   d) Unpack .txz
        Bug #458102 [9]

   e) Case-fold extensions in unpack()
        Bug #476730 [10]

   f) unpack() accept absolute paths
        Bug #483244 [11]

3. Other changes

   a) Bash 4.2
        Bug #431340 [12]

   b) failglob in global scope
        Bug #463822 [13]

4. Features rejected from EAPI 5

   a) Patch applying function in package manager
        Bug #463768 [14]
        - Needed for 2d) and 4b)
        - This will duplicate epatch() from eutils, in simplified form.
        - Name "eapply" has been suggested.

   b) User patches
        Bug #475288 [15], PMS wording [16]
        - Needs 4a)
        - Current wording of the spec requires that every ebuild must
          include a call to the function in src_prepare, which is
          controversial.
        - Names "apply_user_patches" or "eapply_user" have been suggested.

   c) EJOBS variable
        Bug #273101 [17], gentoo-dev discussion [18]
        - Discussion was in 2008. Is there (still) consensus?

   d) Source eclasses only once
        Bug #422533 [19], gentoo-dev discussion [20]

   e) HDEPEND: host dependencies for cross-compilation
        Bug #317337 [21]

   f) Directory support for package* and use*
        Bug #282296 [22]
        - Not intended for gentoo-x86 tree, only to be used in
        overlays.

Ulrich


[1] https://wiki.gentoo.org/wiki/Future_EAPI/EAPI_6_tentative_features
[2] https://bugs.gentoo.org/show_bug.cgi?id=463586
[3] https://bugs.gentoo.org/show_bug.cgi?id=459692
[4] https://bugs.gentoo.org/show_bug.cgi?id=449862
[5] https://bugs.gentoo.org/show_bug.cgi?id=463692
[6] https://bugs.gentoo.org/show_bug.cgi?id=451938
[7] https://bugs.gentoo.org/show_bug.cgi?id=463736
[8] https://bugs.gentoo.org/show_bug.cgi?id=481980
[9] https://bugs.gentoo.org/show_bug.cgi?id=458102
[10] https://bugs.gentoo.org/show_bug.cgi?id=476730
[11] https://bugs.gentoo.org/show_bug.cgi?id=483244
[12] https://bugs.gentoo.org/show_bug.cgi?id=431340
[13] https://bugs.gentoo.org/show_bug.cgi?id=463822
[14] https://bugs.gentoo.org/show_bug.cgi?id=463768
[15] https://bugs.gentoo.org/show_bug.cgi?id=475288
[16] http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commit;h=a8bf7862967cce36b7f1b408934a774126da2538
[17] https://bugs.gentoo.org/show_bug.cgi?id=273101
[18] http://archives.gentoo.org/gentoo-dev/msg_750e33f68b16d971dff1f40dd9145e56.xml
[19] https://bugs.gentoo.org/show_bug.cgi?id=422533
[20] http://marc.info/?l=gentoo-dev&m=134493783816587&w=2
[21] https://bugs.gentoo.org/show_bug.cgi?id=317337
[22] https://bugs.gentoo.org/show_bug.cgi?id=282296

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

[gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Andreas K. Huettel]

Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC.
> 
> Please reply to this email with any proposed agenda items.
> 

Let's decide that the maximum number of EAPIs allowed in the portage tree at 
any time must not exceed 7. 

7, since then EAPI=6 can still go ahead as planned. 

Any new plans afterwards can only proceed if EAPI=1 is finally gone 
(achievable), and for more improvements the bar gets a bit higher afterwards. 

Thanks to Johu for the inspiration.

-- 
Andreas K. Huettel
Gentoo Linux developer (council, kde)
dilfridge@gentoo.org
http://www.akhuettel.de/

[gentoo-project] Maximum number of EAPIs in tree (was: Call For Agenda Items - 10 Jun 2014)

[Ulrich Mueller]

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

>>>>> On Thu, 29 May 2014, Andreas K Huettel wrote:

> Let's decide that the maximum number of EAPIs allowed in the portage
> tree at any time must not exceed 7.

> 7, since then EAPI=6 can still go ahead as planned.

> Any new plans afterwards can only proceed if EAPI=1 is finally gone
> (achievable), and for more improvements the bar gets a bit higher
> afterwards.

That's tree policy, but doesn't prevent PMS and package managers from
supporting more than that number of EAPIs.

In fact, we could finalise the new EAPI, but devs would only be
allowed to commit such ebuilds to the tree when one of the old EAPIs
is gone. Nice way to increase peer pressure. :-)

Ulrich

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

Re: [gentoo-project] Maximum number of EAPIs in tree (was: Call For Agenda Items - 10 Jun 2014)

[Rich Freeman]

On Thu, May 29, 2014 at 5:45 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Thu, 29 May 2014, Andreas K Huettel wrote:
>
>> Let's decide that the maximum number of EAPIs allowed in the portage
>> tree at any time must not exceed 7.
>
>> 7, since then EAPI=6 can still go ahead as planned.
>
>> Any new plans afterwards can only proceed if EAPI=1 is finally gone
>> (achievable), and for more improvements the bar gets a bit higher
>> afterwards.
>
> That's tree policy, but doesn't prevent PMS and package managers from
> supporting more than that number of EAPIs.
>
> In fact, we could finalise the new EAPI, but devs would only be
> allowed to commit such ebuilds to the tree when one of the old EAPIs
> is gone. Nice way to increase peer pressure. :-)

I like the idea of controlling the number of EAPIs in the tree.  I
don't like doing it this way.

If the Council thinks there are too many EAPIs, then don't approve any
more until it is fixed.  Having everybody starting flamewars on the
list about fixing their ebuilds or don't touch my ebuilds or whatever
because projects are stepping on each other's toes seems like
dereliction of duty on the part of the Council.  What's the point of
having an elected body to make decisions if they're just going to say,
"here you go, we created a mess for you, now figure out how to sort it
out and let us know if you have any agenda items for next month...?"

I'm all for picking a guideline like 7, but in the end the same
council that sets the limit can change the limit or ignore the limit.
It is like having Congress set a budget limit - they can change the
limit as quickly as they set it, and they can even do it in the same
law that goes over the limit.

The Council has already taken measures to start deprecating EAPIs, and
I'd hope the next Council will continue this in a sensible fashion.
However, we can't dictate what they'll do, and if there is a good
reason for the number to be 8 then they can make it 8.

Rich

Re: [gentoo-project] Maximum number of EAPIs in tree (was: Call For Agenda Items - 10 Jun 2014)

[Jeroen Roovers]

On Thu, 29 May 2014 19:27:12 -0400
Rich Freeman <rich@thefreemanclan.net> wrote:

> It is like having Congress set a budget limit - they can change the
> limit as quickly as they set it, and they can even do it in the same
> law that goes over the limit.

I assume you picked US Congress because it is such an intelligent and
flexible pillar of democracy. Bravo, it truly is an example to us all.


     jer

Re: [gentoo-project] Maximum number of EAPIs in tree (was: Call For Agenda Items - 10 Jun 2014)

[Rich Freeman]

On Thu, May 29, 2014 at 8:11 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Thu, 29 May 2014 19:27:12 -0400
> Rich Freeman <rich@thefreemanclan.net> wrote:
>
>> It is like having Congress set a budget limit - they can change the
>> limit as quickly as they set it, and they can even do it in the same
>> law that goes over the limit.
>
> I assume you picked US Congress because it is such an intelligent and
> flexible pillar of democracy. Bravo, it truly is an example to us all.
>

No, I picked the US Congress because it makes stupid and meaningless
gestures all the time, like setting spending limits on itself, which
then just get overridden in every spending bill they subsequently
pass.

Rich

Re: [gentoo-project] Maximum number of EAPIs in tree (was: Call For Agenda Items - 10 Jun 2014)

[Ulrich Mueller]

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

>>>>> On Thu, 29 May 2014, Rich Freeman wrote:

> On Thu, May 29, 2014 at 5:45 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> In fact, we could finalise the new EAPI, but devs would only be
>> allowed to commit such ebuilds to the tree when one of the old EAPIs
>> is gone. Nice way to increase peer pressure. :-)

This was a joke. Please note the smiley.

> I like the idea of controlling the number of EAPIs in the tree.  I
> don't like doing it this way.

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

[gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 2986 bytes --]

Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC.
> 
> Please reply to this email with any proposed agenda items.

Here's an agenda item. For discussion at the moment, since this is not 
something the council can decide on its own; we need the help of Infra and the 
foundation. Hopefully it will turn into something concrete, though more on the 
lines of a GLEP or an Infra policy. Several Infra and Council members have 
contributed ideas.

########
Create a mechanism how Gentoo developers can 
* host non-critical services 
* on self-provided machines or later Gentoo-provided machines
* visible in a subdomain of gentoo.org, 
* which they themselves administer fully and are fully responsible for
* outside the direct control of Infra, but with some limitations (see below)

See it as a semi-official staging area for future core services.

The foundation is asked to consider supporting such initiatives financially if 
they are clearly in the interest of the general developer community.
########

Why?

The Gentoo infrastructure is administered with the help of tools like cfengine 
or puppet, designed to distribute configuration to many machines. The way this 
is set up now, fine-grained access control is not yet possible. Which means 
that someone planning deployment of a new service on an official machine needs 
to get access to the central repositories and thereby intrinsically also power 
over core, critical services such as, e.g., cvs. 

Obviously administrative access to critical services should be restricted to a 
small trusted group, and this is what Infra is. 

Any new service that does not need any elevated access permissions towards 
core critical services (example, a repoman-checker that grabs the public 
portage tree, analyzes it and generates alerts; example 2, a program that 
parses ebuild SRC_URI, checks for availability of future versions, and 
displays that information on a web interface) is effectively and unnecessarily 
blocked by this architecture. 

Our admins are busy keeping the core infrastructure running and safe (and they 
are doing this very well, thank you!); it's understandable that they may not 
want to accept additional burdens. Here's the way around it. 

Many of the pieces needed are already possible. This initiative aims to make a 
package of it and advertise it.

What limitations?

This is mostly obvious stuff.

* The maintainers need to take security into account
* Minimal/none interaction with core services (except publically available 
things)
* No use of infra passwords / credentials
* Disclaimers on the service if web-based
* Possibly some sort of infra access as non-privileged user required, e.g. for 
running glsa-check

Cheers & happy discussion, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

[gentoo-project] [gentoo-dev-announce] Re: Call For Agenda Items - 10 Jun 2014

[Ulrich Mueller]

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

>>>>> On Wed, 4 Jun 2014, Rich Freeman wrote:

> I do intend to post links to discussion archives, whenever the thread
> actually gets archived.  Gmane seems to be out-of-date, so we might
> rely on Council members having this email thread in front of them.

http://thread.gmane.org/gmane.linux.gentoo.devel.announce/2151

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Richard Yao]

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

On 05/29/2014 03:03 PM, Andreas K. Huettel wrote:
> Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
>> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00 UTC.
>>
>> Please reply to this email with any proposed agenda items.
>>
> 
> Let's decide that the maximum number of EAPIs allowed in the portage tree at 
> any time must not exceed 7. 
> 
> 7, since then EAPI=6 can still go ahead as planned. 
> 
> Any new plans afterwards can only proceed if EAPI=1 is finally gone 
> (achievable), and for more improvements the bar gets a bit higher afterwards. 
> 
> Thanks to Johu for the inspiration.
> 

I think we should define a minimum amount of time before new EAPIs may
be introduced to the portage tree. 2 years seems reasonable.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Brian Dolbec]

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

On Thu, 05 Jun 2014 12:06:35 -0400
Richard Yao <ryao@gentoo.org> wrote:

> On 05/29/2014 03:03 PM, Andreas K. Huettel wrote:
> > Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
> >> The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00
> >> UTC.
> >>
> >> Please reply to this email with any proposed agenda items.
> >>
> > 
> > Let's decide that the maximum number of EAPIs allowed in the
> > portage tree at any time must not exceed 7. 
> > 
> > 7, since then EAPI=6 can still go ahead as planned. 
> > 
> > Any new plans afterwards can only proceed if EAPI=1 is finally gone 
> > (achievable), and for more improvements the bar gets a bit higher
> > afterwards. 
> > 
> > Thanks to Johu for the inspiration.
> > 
> 
> I think we should define a minimum amount of time before new EAPIs may
> be introduced to the portage tree. 2 years seems reasonable.
> 

That likely won't work.  Plus I believe it is already set at a minimum
of 1 year, with the possibility for exceptions to be approved by
council.  But if the ideas and patches to implement them are not done,
it could be many years before final approval.

-- 
Brian Dolbec <dolsen>


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Rich Freeman]

On Thu, Jun 5, 2014 at 12:42 PM, Brian Dolbec <dolsen@gentoo.org> wrote:
> On Thu, 05 Jun 2014 12:06:35 -0400
> Richard Yao <ryao@gentoo.org> wrote:
>>
>> I think we should define a minimum amount of time before new EAPIs may
>> be introduced to the portage tree. 2 years seems reasonable.
>>
>
> That likely won't work.  Plus I believe it is already set at a minimum
> of 1 year, with the possibility for exceptions to be approved by
> council.  But if the ideas and patches to implement them are not done,
> it could be many years before final approval.

I put it on the agenda, but my two cents:

New EAPIs require council approval already.  Setting a policy (like
this one - not speaking generally) on what the council is allowed to
do requires council approval.  Changing such a policy around what the
council is allowed to do requires council approval.  Making a one-time
exception to the policy the council set for itself requires council
approval.

So, I don't really get the point.  The council is basically telling
itself not to do something unless it thinks it should do it anyway.
It is a bit like Congress saying that a congressional pay raise should
require congressional approval when every one to-date has had it
anyway.

If we were arguing that new EAPIs should require a vote of all devs or
something I could at least see that as a policy that actually means
something, though I'd disagree with it.

That said, both proposals around EAPI limitations really just describe
what we're already trending towards.  The council has already
deprecated some EAPIs to keep the count down, and it looks like in
this entire term the most we're doing is giving a thumbs-up to the
general content of EAPI6 without actually giving it a final approval
(it still requires implementation).

So, we're not exactly trending towards drowning in EAPIs.  Just my two
cents - feel free to change my mind...

Rich

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Tom Wijsman]

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

On Thu, 05 Jun 2014 12:06:35 -0400
Richard Yao <ryao@gentoo.org> wrote:

> I think we should define a minimum amount of time before new EAPIs may
> be introduced to the portage tree. 2 years seems reasonable.

What is the goal of this suggestion?

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Roy Bamford]

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

On 2014.06.03 23:02, Andreas K. Huettel wrote:
> Am Montag, 26. Mai 2014, 14:13:32 schrieb Rich Freeman:
> > The next Gentoo Council meeting will be on 10 Jun 2014, at 19:00
> UTC.
> > 
> > Please reply to this email with any proposed agenda items.
> 
> Here's an agenda item. For discussion at the moment, since this is 
> not
> 
> something the council can decide on its own; we need the help of 
> Infra
> and the 
> foundation. Hopefully it will turn into something concrete, though
> more on the 
> lines of a GLEP or an Infra policy. Several Infra and Council members
> have 
> contributed ideas.
> 
> ########
> Create a mechanism how Gentoo developers can 
> * host non-critical services 
> * on self-provided machines or later Gentoo-provided machines
> * visible in a subdomain of gentoo.org, 
> * which they themselves administer fully and are fully responsible 
> for
> * outside the direct control of Infra, but with some limitations (see
> below)
> 
> See it as a semi-official staging area for future core services.
> 
> The foundation is asked to consider supporting such initiatives
> financially if 
> they are clearly in the interest of the general developer community.
> ########
> 
> Why?
> 
> The Gentoo infrastructure is administered with the help of tools like
> cfengine 
> or puppet, designed to distribute configuration to many machines. The
> way this 
> is set up now, fine-grained access control is not yet possible. Which
> means 
> that someone planning deployment of a new service on an official
> machine needs 
> to get access to the central repositories and thereby intrinsically
> also power 
> over core, critical services such as, e.g., cvs. 
> 
> Obviously administrative access to critical services should be
> restricted to a 
> small trusted group, and this is what Infra is. 
> 
> Any new service that does not need any elevated access permissions
> towards 
> core critical services (example, a repoman-checker that grabs the
> public 
> portage tree, analyzes it and generates alerts; example 2, a program
> that 
> parses ebuild SRC_URI, checks for availability of future versions, 
> and
> 
> displays that information on a web interface) is effectively and
> unnecessarily 
> blocked by this architecture. 
> 
> Our admins are busy keeping the core infrastructure running and safe
> (and they 
> are doing this very well, thank you!); it's understandable that they
> may not 
> want to accept additional burdens. Here's the way around it. 
> 
> Many of the pieces needed are already possible. This initiative aims
> to make a 
> package of it and advertise it.
> 
> What limitations?
> 
> This is mostly obvious stuff.
> 
> * The maintainers need to take security into account
> * Minimal/none interaction with core services (except publically
> available 
> things)
> * No use of infra passwords / credentials
> * Disclaimers on the service if web-based
> * Possibly some sort of infra access as non-privileged user required,
> e.g. for 
> running glsa-check
> 
> Cheers & happy discussion, 
> Andreas
> 
> -- 
> 
> Andreas K. Huettel
> Gentoo Linux developer 
> dilfridge@gentoo.org
> http://www.akhuettel.de/
> 
> 

The foundation do not need to be involved any more that they are now.
Anyone can apply for foundation funding for a project.
As an individual trustee, I don't see this project as any different to 
any other project that way apply for funding.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
trustees

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call For Agenda Items - 10 Jun 2014

[Rich Freeman]

On Sat, Jun 7, 2014 at 1:35 PM, Roy Bamford <neddyseagoon@gentoo.org> wrote:
> The foundation do not need to be involved any more that they are now.
> Anyone can apply for foundation funding for a project.
> As an individual trustee, I don't see this project as any different to
> any other project that way apply for funding.

I think the idea is that the policy would be that the Foundation would
agree to not fund services that didn't follow the guidelines.

The rationale would be that if somebody hosts a service funded by the
Foundation and it gets used to serve malware then the Foundation might
be legally responsible.  That is why most organizations don't let
random people run its webservers/etc without any kind of adherence to
central administration/security/etc.  Or perhaps Foundation funds get
used to build some service, but because there is no coordination with
infra there is no way to ever move it into production and it just
fizzles out.

This wouldn't be about keeping people from running services, but
rather encouraging it in a way that makes it safer for the community,
gives recognition to those who built it, and gives it some kind of
roadmap to being a full-fleged Gentoo service.  Maybe it creates a way
to on-board new devs into Infra as well.

I'm talking about services - if somebody wants a sparc under their
desk not generally exposed to the world advertising its services under
the Gentoo name then there really isn't any need for this.

I imagine most organizations do it this way.  If some Google employee
wants to build a development tool or a 10% project hosted on a PC in
their cube most likely the policy requirements are minimal, but on the
other hand if somebody is touching some server that actually generates
content that goes out under the google.com domain then I'm sure the
red tape gets fairly thick.

If we're not going to give any kind of Foundation preference to
following the new guidelines, then I don't really see the point in
going forward with it.

Rich