Re: [gentoo-project] Council meeting 2016-03-13

Re: [gentoo-project] Council meeting 2016-03-13

[Andreas K. Hüttel]

Am Mittwoch, 9. März 2016, 15:34:04 schrieb Ulrich Mueller:
> The next council meeting will be on Sunday 2016-03-13, 19:00 UTC
> in the #gentoo-council channel on Freenode.
> 
> Proposed agenda:
> 
> 1. Roll call
> 2. GLEP 42 update [1,2]

After talking to Ulrich, here's still one more agenda item: 

Since we regularly get into discussions about PMS versus "historical 
behaviour" (see e.g. USE=multislot), I'm asking the concil to decide along the 
following lines:

1) All pre-PMS, non-PMS-conformant behaviour should be considered deprecated 
immediately.
2) We encourage creation of trackers to hunt down and kill pre-PMS, non-PMS-
conformant behaviour of ebuilds, eclasses, package managers
3) We introduce a hard deadline when all this should be fixed.

Cheers, 
Andreas

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

-- 
Andreas K. Hüttel
Gentoo Linux developer (council, perl, libreoffice)
dilfridge@gentoo.org
http://www.akhuettel.de/

[gentoo-project] Re: Council meeting 2016-03-13

[Ulrich Mueller]

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

>>>>> On Wed, 9 Mar 2016, Andreas K Hüttel wrote:

>> The next council meeting will be on Sunday 2016-03-13, 19:00 UTC
>> in the #gentoo-council channel on Freenode.

> After talking to Ulrich, here's still one more agenda item:

> Since we regularly get into discussions about PMS versus "historical
> behaviour" (see e.g. USE=multislot), I'm asking the concil to
> decide along the following lines:

> 1) All pre-PMS, non-PMS-conformant behaviour should be considered
> deprecated immediately.
> 2) We encourage creation of trackers to hunt down and kill pre-PMS,
> non-PMS-conformant behaviour of ebuilds, eclasses, package managers
> 3) We introduce a hard deadline when all this should be fixed.

Updated agenda:

1. Roll call
2. GLEP 42 update [1,2]
3. Historical behaviour vs PMS (see above)
4. Open bugs with council involvement [3]
5. Open floor


[1] https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4
[2] https://bugs.gentoo.org/show_bug.cgi?id=568068
[3] https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3096302&query_format=advanced

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

[gentoo-project] GLEP 42 update (was: Re: Council meeting 2016-03-13)

[Ulrich Mueller]

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

>>>>> On Wed, 9 Mar 2016, Ulrich Mueller wrote:

> 2. GLEP 42 update [1,2]

Following up to this, an updated version of GLEP 42 is in my user
space on the wiki:
https://wiki.gentoo.org/wiki/User:Ulm/GLEP:42

The relevant change for news item format 2.0 is here:
https://wiki.gentoo.org/index.php?title=User%3AUlm%2FGLEP%3A42&type=revision&diff=467060&oldid=467058

Ulrich


> [1] https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4
> [2] https://bugs.gentoo.org/show_bug.cgi?id=568068

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

Re: [gentoo-project] Council meeting 2016-03-13

[Alexis Ballier]

On Wednesday, March 9, 2016 5:37:08 PM CET, Andreas K. Hüttel wrote:
> 1) All pre-PMS, non-PMS-conformant behaviour should be 
> considered deprecated 
> immediately.
> 2) We encourage creation of trackers to hunt down and kill pre-PMS, non-PMS-
> conformant behaviour of ebuilds, eclasses, package managers
> 3) We introduce a hard deadline when all this should be fixed.


You seem to be generalizing to all cases from a very specific one: 
multislot is breaking an important assumption (SLOT being constant) and 
dropping it is not breaking anything.

Some examples that would fall under the scope of your proposal:

https://bugs.gentoo.org/show_bug.cgi?id=202631
-> Needed to comply with other PMS rules on some systems ('patch' being GNU 
patch inside ebuilds, etc.)

https://bugs.gentoo.org/show_bug.cgi?id=203891
-> Without this, we'd install a half-broken glibc by default. Any deadline 
would have to take in consideration the time needed to have a fixed glibc 
in stable.
(some ocaml stuff are also offenders here, but it is really minor in 
comparison, and I've been trying to move away from the "feature" causing 
the need for it as much as I could)

https://bugs.gentoo.org/show_bug.cgi?id=573306
-> Needed to get cross-compilation (or even ROOT!=/) to work properly. 
(Independtly of PM getting cross-compilation deps properly).


The above examples are needed in order to be able to provide working stuff, 
predate PMS and do not conform to it. The only issue they cause is that 
alternative PMs might not implement them properly.


Alexis.

Re: [gentoo-project] Council meeting 2016-03-13

[Rich Freeman]

On Thu, Mar 10, 2016 at 7:44 AM, Alexis Ballier <aballier@gentoo.org> wrote:
>
> The above examples are needed in order to be able to provide working stuff,
> predate PMS and do not conform to it. The only issue they cause is that
> alternative PMs might not implement them properly.
>

I think the intent is to get stuff like this into PMS or change it,
not to just start breaking things arbitrarily.

The underlying message is that devs shouldn't just quietly rely on
non-PMS behavior without putting it on a tracker and use breakage as
an excuse.  If we're depending on non-PMS behavior we need to get that
onto a tracker so that either PMS or the packages can be fixed as
appropriate, and then once the issue is dealt with we need to stick to
PMS.

In any case, these are my general thoughts on the issue.  When
packages are still not aligned with PMS we should be tracking it and
fixing either the package or PMS.  Of course, we could spot some
non-PMS-compliant behavior that predates PMS 10 years from now, and it
isn't like we can just have QA just comment out some ebuild lines
without any regard to what it does to the tree.  When PMS issues come
up yesterday, tomorrow, or 10 years from now we have to deal with
their reality.  That said, we still need to DEAL with them and not
just ignore them.

-- 
Rich

Re: [gentoo-project] Council meeting 2016-03-13

[Chí-Thanh Christopher Nguyễn]

Rich Freeman schrieb:
> I think the intent is to get stuff like this into PMS or change it,
> not to just start breaking things arbitrarily.

That interpretation is a bit at odds with the wording "We introduce a 
hard deadline when all this should be fixed."


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] Council meeting 2016-03-13

[Rich Freeman]

On Thu, Mar 10, 2016 at 10:34 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> Rich Freeman schrieb:
>>
>> I think the intent is to get stuff like this into PMS or change it,
>> not to just start breaking things arbitrarily.
>
> That interpretation is a bit at odds with the wording "We introduce a hard
> deadline when all this should be fixed."
>

I'll let Andreas comment on his intent there.  I'm not sure how a
deadline could actually work.  If we know about an issue today,
setting a deadline won't really make anybody resolve it faster.  If we
judge that treecleaning the affected packages wouldn't be a big
problem we could always set a deadline and then treeclean, but
obviously if it is a toolchain package that isn't going to work.
Long-term, if an issue comes up in a critical package we can't just
say that it is after the deadline and therefore it is fine for package
managers to break it the next day.

This is the reality with anything concerning specifications.  If the
software doesn't do what the specs say, it is definitely a bug, but it
isn't always a bug with the software.  That's why we pay humans to
deal with these kinds of problems, and we pay the people who deal with
them well a lot more.

-- 
Rich

Re: [gentoo-project] Council meeting 2016-03-13

[Ulrich Mueller]

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

>>>>> On Thu, 10 Mar 2016, Alexis Ballier wrote:

> On Wednesday, March 9, 2016 5:37:08 PM CET, Andreas K. Hüttel wrote:
>> 1) All pre-PMS, non-PMS-conformant behaviour should be considered
>> deprecated immediately.
>> 2) We encourage creation of trackers to hunt down and kill pre-PMS,
>> non-PMS-conformant behaviour of ebuilds, eclasses, package managers
>> 3) We introduce a hard deadline when all this should be fixed.

> You seem to be generalizing to all cases from a very specific one:
> multislot is breaking an important assumption (SLOT being constant)
> and dropping it is not breaking anything.

> Some examples that would fall under the scope of your proposal:

> https://bugs.gentoo.org/show_bug.cgi?id=202631
> -> Needed to comply with other PMS rules on some systems ('patch'
> being GNU patch inside ebuilds, etc.)

No, it isn't. The package manager is required to ensure that "sed",
"patch", "find" etc. are the GNU versions. This is independent of any
profile.bashrc. If Portage relies on aliases set in profiles instead,
then this is a Portage bug which should be fixed.

PMS reference:
https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3.1.1

> https://bugs.gentoo.org/show_bug.cgi?id=203891
> -> Without this, we'd install a half-broken glibc by default. Any
> deadline would have to take in consideration the time needed to have
> a fixed glibc in stable.

> (some ocaml stuff are also offenders here, but it is really minor in
> comparison, and I've been trying to move away from the "feature"
> causing the need for it as much as I could)

We have discussed this at length (on the verge of derailing) in
the bug. Someone has to write a spec, then it can go into EAPI 7.
I actually like mgorny's proposal for a "dostrip" in comment 39.

Until then, ebuilds should neither rely on the variable, nor should
they call functions like prepallstrip that are internal to the package
manager.

PMS reference:
https://projects.gentoo.org/pms/6/pms.html#x1-14500011.3.3.16

> https://bugs.gentoo.org/show_bug.cgi?id=573306
> -> Needed to get cross-compilation (or even ROOT!=/) to work
> properly. (Independtly of PM getting cross-compilation deps
> properly).

I cannot say much about this one, or about cross-compilation in
general. Reading the bug, I am not too optimistic, though. Seems there
aren't even clear answers to the three simple questions that have been
posed.

> The above examples are needed in order to be able to provide working
> stuff, predate PMS and do not conform to it. The only issue they
> cause is that alternative PMs might not implement them properly.

Well, the first PMS version was approved by the council in 2008
(for EAPI 2). At some point we should have tracked down all remaining
non-PMS-conformant behaviour, so it can be fixed in ebuilds, in the
package manager, or in the PMS itself.

So +1 for Andreas's items 1) and 2). Not so sure about item 3) though.
For some things a hard deadline could work, but for others like
cross-compiling it may not.

Ulrich

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

Re: [gentoo-project] Council meeting 2016-03-13

[Rich Freeman]

On Thu, Mar 10, 2016 at 11:40 AM, Ulrich Mueller <ulm@gentoo.org> wrote:
>
> Well, the first PMS version was approved by the council in 2008
> (for EAPI 2). At some point we should have tracked down all remaining
> non-PMS-conformant behaviour, so it can be fixed in ebuilds, in the
> package manager, or in the PMS itself.
>

One thing I can say with a pretty high level of assurance is that
there will NEVER be a point in time when we've tracked down all
remaining non-PMS-conformant behavior.
This is a bit like saying that at some point in time a mature piece of
software will be free of bugs.  I'd like to think that we'll get there
with PMS some day, but I'm not so naive to actually believe that.  The
rate of finding new issues should of course go down, but software QA
is a hard problem.

But, I agree completely that when we discover these they're bugs and
need to be fixed.  PMS is broken is a description of a problem, not a
resolution to a problem.

-- 
Rich

Re: [gentoo-project] Council meeting 2016-03-13

[Alexis Ballier]

On Thursday, March 10, 2016 5:40:18 PM CET, Ulrich Mueller wrote:
>>>>>> On Thu, 10 Mar 2016, Alexis Ballier wrote:
>
>> On Wednesday, March 9, 2016 5:37:08 PM CET, Andreas K. Hüttel wrote:
>>> 1) All pre-PMS, non-PMS-conformant behaviour should be considered
>>> deprecated immediately.
>>> 2) We encourage creation of trackers to hunt down and kill pre-PMS,
>>> non-PMS-conformant behaviour of ebuilds, eclasses, package managers
>>> 3) We introduce a hard deadline when all this should be fixed.
>
>> You seem to be generalizing to all cases from a very specific one:
>> multislot is breaking an important assumption (SLOT being constant)
>> and dropping it is not breaking anything.
>
>> Some examples that would fall under the scope of your proposal:
>
>> https://bugs.gentoo.org/show_bug.cgi?id=202631
>> -> Needed to comply with other PMS rules on some systems ('patch'
>> being GNU patch inside ebuilds, etc.)
>
> No, it isn't. The package manager is required to ensure that "sed",
> "patch", "find" etc. are the GNU versions. This is independent of any
> profile.bashrc. If Portage relies on aliases set in profiles instead,
> then this is a Portage bug which should be fixed.
>
> PMS reference:
> https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3.1.1


Well, you can go into the debate whether perfectly working and needed 
behavior predating PMS which EAPI0 was supposed to normalize is a PMS bug 
or a portage bug, but your point would be much better emphasized with a 
patch providing the behavior you believe to be correct. It might even be a 
better solution since profiles aliases do not really work when e.g. 
building freebsd stuff from a gnu userland.
Mind the upgrade path though: If you remove the aliases from profiles, you 
might not be able to install the portage version providing them. Kind of 
defeats one of the goals of PMS :)


>> https://bugs.gentoo.org/show_bug.cgi?id=203891
>> -> Without this, we'd install a half-broken glibc by default. Any
>> deadline would have to take in consideration the time needed to have
>> a fixed glibc in stable.
>
>> (some ocaml stuff are also offenders here, but it is really minor in
>> comparison, and I've been trying to move away from the "feature"
>> causing the need for it as much as I could)
>
> We have discussed this at length (on the verge of derailing) in
> the bug. Someone has to write a spec, then it can go into EAPI 7.
> I actually like mgorny's proposal for a "dostrip" in comment 39.


I like it too and consider it a much better solution, but that's not the 
point.


> Until then, ebuilds should neither rely on the variable, nor should
> they call functions like prepallstrip that are internal to the package
> manager.
>
> PMS reference:
> https://projects.gentoo.org/pms/6/pms.html#x1-14500011.3.3.16


You prefer to install half-broken libc by default rather than fixing PMS, 
noted.



>> https://bugs.gentoo.org/show_bug.cgi?id=573306
>> -> Needed to get cross-compilation (or even ROOT!=/) to work
>> properly. (Independtly of PM getting cross-compilation deps
>> properly).
>
> I cannot say much about this one, or about cross-compilation in
> general. Reading the bug, I am not too optimistic, though. Seems there
> aren't even clear answers to the three simple questions that have been
> posed.


You should probably read again then: A few additive answers without 
ping-pong usually means all the parties agree.

[...]


Alexis.

Re: [gentoo-project] Council meeting 2016-03-13

[Andreas K. Huettel]

Am Donnerstag, 10. März 2016, 20:19:11 schrieb Alexis Ballier:
> Well, you can go into the debate whether perfectly working and needed 
> behavior predating PMS which EAPI0 was supposed to normalize is a PMS bug 
> or a portage bug,

And this type of argumentation is *exactly* the reason why I am bringing up 
the agenda topic. 

Either we have a specification (and then we should either stick to it or 
improve it) or we don't. Still regularly coming up with "blah blah this was 
before PMS, serious infighting between devs, portage was perfectly fine, no I 
won't fix anything" after 8 (EIGHT) years is not an option anymore. 

The main reason for the deadline proposal is that maintainers get their 
backsides moving. 

Yes one possible fix indeed is a PMS improvement, we all know this probably 
will surpass all deadline time requirements. 

However, if there is no motion in an issue AT ALL, the deadline should make it 
possible to bypass maintainers and delegate a solution to QA at some point. No 
more stalling.

-- 

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

Re: [gentoo-project] Council meeting 2016-03-13

[Alexis Ballier]

On Thursday, March 10, 2016 11:41:21 PM CET, Andreas K. Huettel wrote:
> Am Donnerstag, 10. März 2016, 20:19:11 schrieb Alexis Ballier:
>> Well, you can go into the debate whether perfectly working and needed 
>> behavior predating PMS which EAPI0 was supposed to normalize is a PMS bug 
>> or a portage bug,
>
> And this type of argumentation is *exactly* the reason why I am bringing up 
> the agenda topic. 
>
> Either we have a specification (and then we should either stick to it or 
> improve it) or we don't. Still regularly coming up with "blah blah this was 
> before PMS, serious infighting between devs, portage was 
> perfectly fine, no I 
> won't fix anything" after 8 (EIGHT) years is not an option anymore. 


This was clear since the beginning and by cutting my reasonning in the 
middle you don't get the point *AT ALL*...

If you want the council to state that having a spec that does not match 
reality or reality that does not adhere to the spec is bad, then why not, 
but that sounds like stating the obvious since this is the definition of a 
spec that was approved years ago and for which council already stated the 
need for it even before.


> The main reason for the deadline proposal is that maintainers get their 
> backsides moving. 
>
> Yes one possible fix indeed is a PMS improvement, we all know this probably 
> will surpass all deadline time requirements. 
>
> However, if there is no motion in an issue AT ALL, the deadline 
> should make it 
> possible to bypass maintainers and delegate a solution to QA at 
> some point. No 
> more stalling.


You seem to assume that in all the issues there's an evil person blocking 
improvements. In all the examples I pointed out, nobody is blocking 
anything, the lack of proper solution is.

A deadline does not help moving forward, that's doing the work that does...


Alexis.

[gentoo-project] Council meeting 2016-03-13

[Ulrich Mueller]

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

The next council meeting will be on Sunday 2016-03-13, 19:00 UTC
in the #gentoo-council channel on Freenode.

Proposed agenda:

1. Roll call
2. GLEP 42 update [1,2]
3. Open bugs with council involvement [3]
4. Open floor


[1] https://archives.gentoo.org/gentoo-dev/message/b9460b9c8d578c3498c217c17b75afd4
[2] https://bugs.gentoo.org/show_bug.cgi?id=568068
[3] https://bugs.gentoo.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=CONFIRMED&bug_status=IN_PROGRESS&email2=council%40gentoo.org&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype2=substring&list_id=3096302&query_format=advanced

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