[gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Andreas K. Huettel]

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

Dear all, 

the next council meeting will be 8/October/2017 18:00 UTC in the
#gentoo-council channel on freenode.

Please reply to this message with any items you would like us to discuss
or vote on.

The agenda will be sent out in a week.

Thanks,
Andreas

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

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

Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Michał Górny]

W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
Huettel napisał:
> Dear all, 
> 
> the next council meeting will be 8/October/2017 18:00 UTC in the
> #gentoo-council channel on freenode.
> 
> Please reply to this message with any items you would like us to discuss
> or vote on.
> 
> The agenda will be sent out in a week.
> 

So, in order:

1. Revisit hppa status -- no big talks this time, just slyfox should
tell us if he managed to get it reasonably alive and we decide if we
keep it or dump it.

2. The big GLEP reform -- [1] for importing new GLEPs, [2] for GLEP 1/2
updates. Preferably we could do it via bugs without waiting for
the meeting but let's put it on the agenda to set some deadline. Anyway,
read this *before* the meeting, it's big.

[1]:https://bugs.gentoo.org/630882
[2]:https://bugs.gentoo.org/631338


-- 
Best regards,
Michał Górny

Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Michał Górny]

W dniu wto, 26.09.2017 o godzinie 20∶58 +0200, użytkownik Michał Górny
napisał:
> W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
> Huettel napisał:
> > Dear all, 
> > 
> > the next council meeting will be 8/October/2017 18:00 UTC in the
> > #gentoo-council channel on freenode.
> > 
> > Please reply to this message with any items you would like us to discuss
> > or vote on.
> > 
> > The agenda will be sent out in a week.
> > 
> 
> So, in order:
> 

[...]

3. Also, if time permits we may take a look at the git pre-GLEP [3].
I have been delaying this for GLEP editors to pick it up but given that
there has been no action for 2 months... Of course, if the GLEP reform
is accepted, I'll port it to the new syntax.

[3]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git


-- 
Best regards,
Michał Górny

Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 2423 bytes --]

On 09/27/2017 09:24 PM, Michał Górny wrote:
> W dniu wto, 26.09.2017 o godzinie 20∶58 +0200, użytkownik Michał Górny
> napisał:
>> W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
>> Huettel napisał:
>>> Dear all, 
>>>
>>> the next council meeting will be 8/October/2017 18:00 UTC in the
>>> #gentoo-council channel on freenode.
>>>
>>> Please reply to this message with any items you would like us to discuss
>>> or vote on.
>>>
>>> The agenda will be sent out in a week.
>>>
>>
>> So, in order:
>>
> 
> [...]
> 
> 3. Also, if time permits we may take a look at the git pre-GLEP [3].

We can always look at it, but I don't necessarily believe it is ready
for a vote at this point, I seem to recall the last email discussion on
it ending without conclusion, so I'd suggest picking up on an email
thread discussing it and trying to separate out a few explicit
discussion points to have a better thread model.

Some questions that immediately springs to mind re-reading this is
(1) Is this an authoritative standard or a suggestion? if it is only a
suggestion does it belong in devmanual or git workflow on wiki rather
than in a GLEP to begin with? if it is authoritative, is it properly
well defined?

(2)(a) Should Bug be a generic indicator for bug information, including
upstream bugs, or; (b) do we want to separate upstream / other
information in e.g a References: field that can be used for other bugs
and descriptions (including security advisories etc). If so (c) is there
a benefit in using a full URI for Bug; or should this be reduced to only
the number, (d) How should multiple bugs be added, is this a comma or
space separated list, or multiple Bug listings with single bug number?
(I, personally, prefer the latter as it removes parsing semantics
regarding potential linebreaks and max widths, so multiple Bug is likely
needed anyways, so simplifying it to only one number seems like a good
thing)

For the other tags it seems like it is starting to start to be
consistent now, in particular with regards to earlier overloading of
same names for multiple purposes (e.g fixes), so thanks for that.

I'll have to review it more carefully when having some Gentoo time at home.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Michał Górny]

W dniu czw, 28.09.2017 o godzinie 11∶06 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 09/27/2017 09:24 PM, Michał Górny wrote:
> > W dniu wto, 26.09.2017 o godzinie 20∶58 +0200, użytkownik Michał Górny
> > napisał:
> > > W dniu pon, 25.09.2017 o godzinie 17∶08 +0200, użytkownik Andreas K.
> > > Huettel napisał:
> > > > Dear all, 
> > > > 
> > > > the next council meeting will be 8/October/2017 18:00 UTC in the
> > > > #gentoo-council channel on freenode.
> > > > 
> > > > Please reply to this message with any items you would like us to discuss
> > > > or vote on.
> > > > 
> > > > The agenda will be sent out in a week.
> > > > 
> > > 
> > > So, in order:
> > > 
> > 
> > [...]
> > 
> > 3. Also, if time permits we may take a look at the git pre-GLEP [3].
> 
> We can always look at it, but I don't necessarily believe it is ready
> for a vote at this point, I seem to recall the last email discussion on
> it ending without conclusion, so I'd suggest picking up on an email
> thread discussing it and trying to separate out a few explicit
> discussion points to have a better thread model.

If having a conclusion would be a requirement for doing anything, we'd
never have moved off EAPI 0.

> Some questions that immediately springs to mind re-reading this is
> (1) Is this an authoritative standard or a suggestion? if it is only a
> suggestion does it belong in devmanual or git workflow on wiki rather
> than in a GLEP to begin with? if it is authoritative, is it properly
> well defined?

Given the behavior of Gentoo developers, I think we have no other option
except making it authoritative standard. Otherwise, people will continue
using their own personal style even if it they knew it breaks our
tooling (compare: stable bot).

> (2)(a) Should Bug be a generic indicator for bug information, including
> upstream bugs, or; (b) do we want to separate upstream / other
> information in e.g a References: field that can be used for other bugs
> and descriptions (including security advisories etc).

As far as I'm concerned, one indicator for all bugs is enough,
especially that in some cases projects have Gentoo upstream which blur
the line between upstream and downstream bugs.

As for CVEs and other uncommon stuff, I don't have a strong opinion. If
you expect some specific machine action for them, it'd be better to have
a unique tag though.

>  If so (c) is there
> a benefit in using a full URI for Bug; or should this be reduced to only
> the number,

Only full URIs are acceptable. Numbers are ambiguous. The repository
and commits within it are mirrored to various sources, can be included
in external repositories and so on. We don't want to start closing
accidental bugs all over the place just because someone cherry-picked
a commit without escaping all references Gentoo developers left.

>  (d) How should multiple bugs be added, is this a comma or
> space separated list, or multiple Bug listings with single bug number?
> (I, personally, prefer the latter as it removes parsing semantics
> regarding potential linebreaks and max widths, so multiple Bug is likely
> needed anyways, so simplifying it to only one number seems like a good
> thing)

The spec already answers that. One URL per tag.

> For the other tags it seems like it is starting to start to be
> consistent now, in particular with regards to earlier overloading of
> same names for multiple purposes (e.g fixes), so thanks for that.
> 
> I'll have to review it more carefully when having some Gentoo time at home.

-- 
Best regards,
Michał Górny

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1741 bytes --]

On 09/28/2017 09:46 PM, Michał Górny wrote:
> W dniu czw, 28.09.2017 o godzinie 11∶06 +0200, użytkownik Kristian
> Fiskerstrand napisał:

>> (2)(a) Should Bug be a generic indicator for bug information, including
>> upstream bugs, or; (b) do we want to separate upstream / other
>> information in e.g a References: field that can be used for other bugs
>> and descriptions (including security advisories etc).
> 
> As far as I'm concerned, one indicator for all bugs is enough,
> especially that in some cases projects have Gentoo upstream which blur
> the line between upstream and downstream bugs.
> 
> As for CVEs and other uncommon stuff, I don't have a strong opinion. If
> you expect some specific machine action for them, it'd be better to have
> a unique tag though.

I'm actually thinking more of link to things like advisories and
mailing list discussions with a Reference tag in this case, which can
also be used along with e.g a URI to e.g a debian bugtracker for same
issue if picking a patch etc

> 
>>  If so (c) is there
>> a benefit in using a full URI for Bug; or should this be reduced to only
>> the number,
> 
> Only full URIs are acceptable. Numbers are ambiguous. The repository
> and commits within it are mirrored to various sources, can be included
> in external repositories and so on. We don't want to start closing
> accidental bugs all over the place just because someone cherry-picked
> a commit without escaping all references Gentoo developers left.
> 

Which could also be seen as an argument for Gentoo-Bug: XXXXXX

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Michał Górny]

W dniu czw, 28.09.2017 o godzinie 21∶56 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 09/28/2017 09:46 PM, Michał Górny wrote:
> > W dniu czw, 28.09.2017 o godzinie 11∶06 +0200, użytkownik Kristian
> > Fiskerstrand napisał:
> > > (2)(a) Should Bug be a generic indicator for bug information, including
> > > upstream bugs, or; (b) do we want to separate upstream / other
> > > information in e.g a References: field that can be used for other bugs
> > > and descriptions (including security advisories etc).
> > 
> > As far as I'm concerned, one indicator for all bugs is enough,
> > especially that in some cases projects have Gentoo upstream which blur
> > the line between upstream and downstream bugs.
> > 
> > As for CVEs and other uncommon stuff, I don't have a strong opinion. If
> > you expect some specific machine action for them, it'd be better to have
> > a unique tag though.
> 
> I'm actually thinking more of link to things like advisories and
> mailing list discussions with a Reference tag in this case, which can
> also be used along with e.g a URI to e.g a debian bugtracker for same
> issue if picking a patch etc
> 
> > 
> > >  If so (c) is there
> > > a benefit in using a full URI for Bug; or should this be reduced to only
> > > the number,
> > 
> > Only full URIs are acceptable. Numbers are ambiguous. The repository
> > and commits within it are mirrored to various sources, can be included
> > in external repositories and so on. We don't want to start closing
> > accidental bugs all over the place just because someone cherry-picked
> > a commit without escaping all references Gentoo developers left.
> > 
> 
> Which could also be seen as an argument for Gentoo-Bug: XXXXXX
> 

And then Gentoo-Closes, Debian-Closes, Fancybuntu-Closes, My-Fun-
Upstream-Tracker-Bug...

-- 
Best regards,
Michał Górny

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 1233 bytes --]

On 09/28/2017 10:17 PM, Michał Górny wrote:
>>>>  If so (c) is there
>>>> a benefit in using a full URI for Bug; or should this be reduced to only
>>>> the number,
>>> Only full URIs are acceptable. Numbers are ambiguous. The repository
>>> and commits within it are mirrored to various sources, can be included
>>> in external repositories and so on. We don't want to start closing
>>> accidental bugs all over the place just because someone cherry-picked
>>> a commit without escaping all references Gentoo developers left.
>>>
>> Which could also be seen as an argument for Gentoo-Bug: XXXXXX
>>
> And then Gentoo-Closes, Debian-Closes, Fancybuntu-Closes, My-Fun-
> Upstream-Tracker-Bug...

Not really, Closes is already used for multiple providers of
infrastructure such as Bitbucket and GitHub, so here URI is anyways
needed and isn't specific to Gentoo. Debian bug wouldn't be closed by us
to begin with, but it'd fit into a generic Reference: tag if we pulled a
patch from it or it discusses it somehow. Ditto for upstream, that goes
in Reference as well

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 2663 bytes --]

On 09/28/2017 09:46 PM, Michał Górny wrote:
> As far as I'm concerned, one indicator for all bugs is enough,
> especially that in some cases projects have Gentoo upstream which blur
> the line between upstream and downstream bugs.

I don't buy this argument. The Gentoo Package repository is different
from the upstream software repository, so there needs to be a separation
between how to manage these situations. The guidelines (or requirements,
depending on how we decide on things) in this case only has the package
repository in scope and we shouldn't differentiate between gentoo as
upstream and external upstreams for the purpose of the package repository.

For this to be an issue would be a new patch release / revbump that only
happens in the Gentoo Package Repository but is not part of upstream,
which would be odd, in particular given we have a specific section in
the Gentoo social contract on:
###
We will give back to the free software community

We will establish relationships with Free Software authors and
collaborate with them when possible. We will submit bug-fixes,
improvements, user requests, etc. to the “upstream” authors of software
included in our system. We will also clearly document our contributions
to Gentoo as well as any improvements or changes we make to external
sources used by Gentoo (whether in the form of patches, “sed tweaks” or
some other form). We acknowledge that our improvements and changes are
much more meaningful to the larger Free Software community if they are
clearly documented and explained, since not everyone has the time or
ability to understand the literal changes contained in the patches or
tweaks themselves.
###

Further, for things to be an issue it would requires that automatic
tools touches bugs based on data. I can see that for Closes, which is an
explicit action, but not really for Gentoo-Bug, as a commit could be a
partial solution referencing it, e.g a stabilization, so the most an
automated tool would do is likely post a comment that the bug was
referenced in commit XYZ.

For Closes it brings up the question on whether only a specific list of
categories should be considered for such automated tooling, e.g for
specification of to https://bugs.gentoo.org/NNNNNN it will only
influence "Gentoo Linux" product and reject action from the Gentoo
Package Repository for the others, then the root cause of the upstream
issue is handled, as bugs for that is in Gentoo Hosted Projects.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Michał Górny]

W dniu pią, 29.09.2017 o godzinie 14∶45 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 09/28/2017 10:17 PM, Michał Górny wrote:
> > > > >  If so (c) is there
> > > > > a benefit in using a full URI for Bug; or should this be reduced to only
> > > > > the number,
> > > > 
> > > > Only full URIs are acceptable. Numbers are ambiguous. The repository
> > > > and commits within it are mirrored to various sources, can be included
> > > > in external repositories and so on. We don't want to start closing
> > > > accidental bugs all over the place just because someone cherry-picked
> > > > a commit without escaping all references Gentoo developers left.
> > > > 
> > > 
> > > Which could also be seen as an argument for Gentoo-Bug: XXXXXX
> > > 
> > 
> > And then Gentoo-Closes, Debian-Closes, Fancybuntu-Closes, My-Fun-
> > Upstream-Tracker-Bug...
> 
> Not really, Closes is already used for multiple providers of
> infrastructure such as Bitbucket and GitHub, so here URI is anyways
> needed and isn't specific to Gentoo. Debian bug wouldn't be closed by us
> to begin with, but it'd fit into a generic Reference: tag if we pulled a
> patch from it or it discusses it somehow. Ditto for upstream, that goes
> in Reference as well
> 

How is this an argument for introducing a completely incompatible
and inconsistent concept for the other of the pair?

-- 
Best regards,
Michał Górny

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 910 bytes --]

On 09/30/2017 07:32 PM, Michał Górny wrote:
>>>> Which could also be seen as an argument for Gentoo-Bug: XXXXXX
>>>>
>>> And then Gentoo-Closes, Debian-Closes, Fancybuntu-Closes, My-Fun-
>>> Upstream-Tracker-Bug...
>> Not really, Closes is already used for multiple providers of
>> infrastructure such as Bitbucket and GitHub, so here URI is anyways
>> needed and isn't specific to Gentoo. Debian bug wouldn't be closed by us
>> to begin with, but it'd fit into a generic Reference: tag if we pulled a
>> patch from it or it discusses it somehow. Ditto for upstream, that goes
>> in Reference as well
>>
> How is this an argument for introducing a completely incompatible
> and inconsistent concept for the other of the pair?

Please elaborate

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Michał Górny]

W dniu sob, 30.09.2017 o godzinie 19∶36 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 09/30/2017 07:32 PM, Michał Górny wrote:
> > > > > Which could also be seen as an argument for Gentoo-Bug: XXXXXX
> > > > > 
> > > > 
> > > > And then Gentoo-Closes, Debian-Closes, Fancybuntu-Closes, My-Fun-
> > > > Upstream-Tracker-Bug...
> > > 
> > > Not really, Closes is already used for multiple providers of
> > > infrastructure such as Bitbucket and GitHub, so here URI is anyways
> > > needed and isn't specific to Gentoo. Debian bug wouldn't be closed by us
> > > to begin with, but it'd fit into a generic Reference: tag if we pulled a
> > > patch from it or it discusses it somehow. Ditto for upstream, that goes
> > > in Reference as well
> > > 
> > 
> > How is this an argument for introducing a completely incompatible
> > and inconsistent concept for the other of the pair?
> 
> Please elaborate
> 

You get two tags: Bug to reference without closing, and Closes to
reference+close. Both should have the same usage for consistency.

-- 
Best regards,
Michał Górny

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Andreas K. Huettel]

Am Samstag, 30. September 2017, 20:48:20 CEST schrieb Michał Górny:
> > 
> > Please elaborate
> 
> You get two tags: Bug to reference without closing, and Closes to
> reference+close. Both should have the same usage for consistency.

... and that's actually a very good argument for using full URLs in both.

-- 
Dr. Andreas K. Hüttel
tel. +49 151 241 67748 (mobile)
e-mail mail@akhuettel.de
http://www.akhuettel.de/

Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Andreas K. Huettel]

Am Mittwoch, 27. September 2017, 21:24:53 CEST schrieb Michał Górny:
> [...]
> 
> 3. Also, if time permits we may take a look at the git pre-GLEP [3].
> I have been delaying this for GLEP editors to pick it up but given that
> there has been no action for 2 months... Of course, if the GLEP reform
> is accepted, I'll port it to the new syntax.
> 
> [3]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> 
> 

As extensions, how about:

Closes: https://bugs.gentoo.org/NNNNNN OBSOLETE
 (optional third parameter gives the resolution)

Bug: https://bugs.gentoo.org/NNNNNN un-cc arm@gentoo.org
or generically
Bug: https://bugs.gentoo.org/NNNNNN (command) (parameter)


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Michał Górny]

W dniu nie, 01.10.2017 o godzinie 22∶41 +0200, użytkownik Andreas K.
Huettel napisał:
> Am Mittwoch, 27. September 2017, 21:24:53 CEST schrieb Michał Górny:
> > [...]
> > 
> > 3. Also, if time permits we may take a look at the git pre-GLEP [3].
> > I have been delaying this for GLEP editors to pick it up but given that
> > there has been no action for 2 months... Of course, if the GLEP reform
> > is accepted, I'll port it to the new syntax.
> > 
> > [3]:https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git
> > 
> > 
> 
> As extensions, how about:
> 
> Closes: https://bugs.gentoo.org/NNNNNN OBSOLETE
>  (optional third parameter gives the resolution)
> 
> Bug: https://bugs.gentoo.org/NNNNNN un-cc arm@gentoo.org
> or generically
> Bug: https://bugs.gentoo.org/NNNNNN (command) (parameter)
> 

I'd rather not obfuscate the syntax more. Furthermore, when I wanted to
add un-CC support I got opinions that this doesn't really belong in
commit messages.

As for resolutions, I don't think that we really have a very good case
for using different resolutions when closing via a commit. I mean, most
of the time you use that tag because you actually fixed a bug. The only
alternate case I see is when you're removing the package completely but
I've seen many different ideas on what's the really correct status
there...

-- 
Best regards,
Michał Górny

Re: Git workflow GLEP (Was: Re: [gentoo-project] Call for agenda items, council meeting 8/October/2017 18:00 UTC)

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 556 bytes --]

On 10/01/2017 10:37 PM, Andreas K. Huettel wrote:
> Am Samstag, 30. September 2017, 20:48:20 CEST schrieb Michał Górny:
>>>
>>> Please elaborate
>>
>> You get two tags: Bug to reference without closing, and Closes to
>> reference+close. Both should have the same usage for consistency.
> 
> ... and that's actually a very good argument for using full URLs in both.
> 

Indeed, I agree on that.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

[gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Ulrich Mueller]

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

>>>>> On Mon, 25 Sep 2017, Andreas K Huettel wrote:

> the next council meeting will be 8/October/2017 18:00 UTC in the
> #gentoo-council channel on freenode.

> Please reply to this message with any items you would like us to
> discuss or vote on.

Here is again an item that was retracted from last month's agenda,
in modified form. This time, it only affects the syntax of dependency
groups but not their truth value:

I request the Council to approve a PMS change, namely to ban empty
dependency groups like "|| ( )" or "foo? ( )".

Currently, any parenthesised groups in package dependency
specifications [1] are permitted to contain zero items. As was
recently discovered, Portage was changed in 2011 to treat empty
dependency groups as an error. Apparently nobody has missed the
feature for six years, and no ebuild (or eclass) in the Gentoo
repository is using it.

I see removing empty groups retroactively for all EAPIs (therefore
tightening the rules for ebuilds) as the best path of action, because
ebuilds cannot rely on proper package manager support for the feature.

Proposed patch for PMS is in [2].

Ulrich


[1] https://projects.gentoo.org/pms/6/pms.html#x1-780008.2
[2] https://archives.gentoo.org/gentoo-pms/message/a612bdc64f7aa3e556b129a67493da1b

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 595 bytes --]

On 10/02/2017 09:25 PM, Ulrich Mueller wrote:
> Here is again an item that was retracted from last month's agenda,
> in modified form. This time, it only affects the syntax of dependency
> groups but not their truth value:

I might be misremembering, but wasn't the discussion going along the
lines of this actually belonging in devmanual, and as such is more QA
territory, if it doesn't affect the value the package manager evaluates to?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Rich Freeman]

On Mon, Oct 2, 2017 at 12:33 PM, Kristian Fiskerstrand <k_f@gentoo.org> wrote:
> On 10/02/2017 09:25 PM, Ulrich Mueller wrote:
>> Here is again an item that was retracted from last month's agenda,
>> in modified form. This time, it only affects the syntax of dependency
>> groups but not their truth value:
>
> I might be misremembering, but wasn't the discussion going along the
> lines of this actually belonging in devmanual, and as such is more QA
> territory, if it doesn't affect the value the package manager evaluates to?
>

Does the PMS actually define what the correct behavior is for this
syntax?  IMO a spec ought to do that, unless we really want to define
it as "undefined."  (While rare that actually does come up for various
reasons.)

Now, if it is defined and we just need to communicate that we want our
devs to avoid it anyway, then that is QA territory.  There are an
infinite number of ways to write a program that meets a spec, but that
doesn't mean that we want all of them showing up.

We could also make it a QA issue for now and then fix the spec in the
next PMS revision, and leave the behavior undefined going back.

-- 
Rich

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 665 bytes --]

On 10/02/2017 09:58 PM, Rich Freeman wrote:
> Does the PMS actually define what the correct behavior is for this
> syntax? 

it evaluates to a true, i.e always valid/resolved. And although
explicitly naming an empty group in an ebuild is, probably?, not useful,
I don't see why we'd have a definition that errors out on explicit
definition but not on an implicit reduction, as the package manager
needs to be able to handle the situation anyways. I'm all for banning
the empty construct in QA scope though.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Michał Górny]

W dniu pon, 02.10.2017 o godzinie 22∶01 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 10/02/2017 09:58 PM, Rich Freeman wrote:
> > Does the PMS actually define what the correct behavior is for this
> > syntax? 
> 
> it evaluates to a true, i.e always valid/resolved. And although
> explicitly naming an empty group in an ebuild is, probably?, not useful,
> I don't see why we'd have a definition that errors out on explicit
> definition but not on an implicit reduction, as the package manager
> needs to be able to handle the situation anyways. I'm all for banning
> the empty construct in QA scope though.
> 

Have you read the commit message? The current spec makes no sense by
itself, and no package manager has been following it for 6+ years.

-- 
Best regards,
Michał Górny

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Rich Freeman]

On Mon, Oct 2, 2017 at 4:05 PM, Michał Górny <mgorny@gentoo.org> wrote:
> W dniu pon, 02.10.2017 o godzinie 22∶01 +0200, użytkownik Kristian
> Fiskerstrand napisał:
>> On 10/02/2017 09:58 PM, Rich Freeman wrote:
>> > Does the PMS actually define what the correct behavior is for this
>> > syntax?
>>
>> it evaluates to a true, i.e always valid/resolved. And although
>> explicitly naming an empty group in an ebuild is, probably?, not useful,
>> I don't see why we'd have a definition that errors out on explicit
>> definition but not on an implicit reduction, as the package manager
>> needs to be able to handle the situation anyways. I'm all for banning
>> the empty construct in QA scope though.
>>
>
> Have you read the commit message? The current spec makes no sense by
> itself, and no package manager has been following it for 6+ years.
>

IMO the spec ought to define a correct behavior, which portage
follows.  Maybe that means changing the spec.  Maybe that means
changing portage.  It sounds like the two don't match right now and
that isn't really ideal, though it isn't necessarily a crisis at least
in the explicit case which is degenerate.  I imagine that if the
implicit case were misbehaving we'd have heard of it by now, but I
can't speak to what portage actually is doing and whether it follows
the spec.

And by all means ban explicit empty ()'s as a QA practice.


-- 
Rich

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Ulrich Mueller]

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

>>>>> On Mon, 2 Oct 2017, Kristian Fiskerstrand wrote:

> On 10/02/2017 09:58 PM, Rich Freeman wrote:
>> Does the PMS actually define what the correct behavior is for this
>> syntax?

> it evaluates to a true, i.e always valid/resolved. And although
> explicitly naming an empty group in an ebuild is, probably?, not
> useful, I don't see why we'd have a definition that errors out on
> explicit definition but not on an implicit reduction, as the package
> manager needs to be able to handle the situation anyways.

Why would it need to handle explicit empty groups? If all
use-conditionals inside a group evaluate to false, then it must be
able to compute it. That doesn't prevent us from having strict syntax
requirements.

IMHO it is unlikely that anyone would write an explicit || ( ) in an
ebuild. Then the only place where this can arise is a failed automatic
calculation of dependencies which presumably would be in an eclass.

A recent example is https://bugs.gentoo.org/620400 where the void ruby
dependency was discovered because Portage flagged the empty group.

> I'm all for banning the empty construct in QA scope though.

For my taste, we have too many of these already. If we decide that
explicit empty groups are useful (for what?), then we have no reason
to ban them by QA. If not, then why should the PM support them?
Furthermore, code that supports a banned construct will not see any
real life testing.

In addition, Portage doesn't support empty groups since 2011. That for
itself is not an argument to change PMS, but it shows that there is no
need for the construct.

Ulrich

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Kristian Fiskerstrand]

[-- Attachment #1.1: Type: text/plain, Size: 655 bytes --]

On 10/03/2017 01:05 PM, Ulrich Mueller wrote:
> Why would it need to handle explicit empty groups? If all
> use-conditionals inside a group evaluate to false, then it must be
> able to compute it. That doesn't prevent us from having strict syntax
> requirements.

So the code paths for parsing of the ebuild anyways differs from
handling the implicit case, i.e it is an actual reduction in code
complexity to ban this case explicitly in PMS?

What does other package managers building on PMS do?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3


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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Rich Freeman]

On Tue, Oct 3, 2017 at 7:05 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> In addition, Portage doesn't support empty groups since 2011. That for
> itself is not an argument to change PMS, but it shows that there is no
> need for the construct.
>

If the behavior of portage doesn't match the specification in PMS that
is reason enough to change one or the other.  The purpose of PMS is to
document how package managers are supposed to behave.

You could:

1.  Change portage to behave as PMS specifies.
2.  Change PMS to specify portage's behavior.
3.  Change PMS to make the behavior explicitly undefined.

Sure, this might be a lower-priority bug but this seems like a valid
one.  What is the point in having a specification if we don't actually
specify what we're doing?

-- 
Rich

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Ulrich Mueller]

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

>>>>> On Tue, 3 Oct 2017, Rich Freeman wrote:

> If the behavior of portage doesn't match the specification in PMS that
> is reason enough to change one or the other.  The purpose of PMS is to
> document how package managers are supposed to behave.

> You could:

> 1.  Change portage to behave as PMS specifies.
> 2.  Change PMS to specify portage's behavior.
> 3.  Change PMS to make the behavior explicitly undefined.

> Sure, this might be a lower-priority bug but this seems like a valid
> one.  What is the point in having a specification if we don't actually
> specify what we're doing?

I believe I am aware of the options. :-) The goal is indeed that PMS
and Portage behaviour should match, which isn't the case since 2011.
So the normal course of action would be to change Portage. There are
two aspects that make me believe that changing PMS would be a better
choice, though: First, the feature is of questionable usefulness and
hasn't seen any use in the tree. And second, if we implement GLEP 73
(which is in the list for EAPI 7) we are likely to tighten the rules
in any case. So if we go for your option 1 or 3 above, the spec (and
package managers as well) will end up with EAPI dependent behaviour,
for a feature that isn't used. The proposed retroactive change would
avoid that, and for existing EAPIs there is no practical difference.

Ulrich

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

Re: [gentoo-project] Re: [gentoo-dev-announce] Call for agenda items, council meeting 8/October/2017 18:00 UTC

[Michał Górny]

W dniu wto, 03.10.2017 o godzinie 13∶10 +0200, użytkownik Kristian
Fiskerstrand napisał:
> On 10/03/2017 01:05 PM, Ulrich Mueller wrote:
> > Why would it need to handle explicit empty groups? If all
> > use-conditionals inside a group evaluate to false, then it must be
> > able to compute it. That doesn't prevent us from having strict syntax
> > requirements.
> 
> So the code paths for parsing of the ebuild anyways differs from
> handling the implicit case, i.e it is an actual reduction in code
> complexity to ban this case explicitly in PMS?
> 
> What does other package managers building on PMS do?

PkgCore treats empty groups as an error. 

Paludis seems to follow the spec to the letter, and this implies a lot
of extra code to handle the unexpected special cases.

-- 
Best regards,
Michał Górny