[gentoo-dev] [RFC] Portage einfo, elog... output format change

[gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

Hi, everyone.

I know I'm going to regret asking this... but I've prepared a change to
the Portage output format and I think it asks for a wider discussion
than internally in Portage team.

The primary problem with the current output format is that different
kinds of messages differ only in color.  This makes them
indistinguishable without colors and hard to grep.  ago's been asking
for a better way to grep for QA warnings and this is pretty much what
motivated me to do this.

The proposed new format distinguished message types both using colors
and strings.  This is roughly inspired by Xorg logs.  For example,
instead of:

 * some message
 * other message
 * hell if i know what this is

You get:

[WW] some message
[EE] other message
[QA] hell if i know what this is

I've also added more colors to explicitly distinguish einfo from elog,
and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
used by Portage with four-character versions to keep messages aligned. 
The 'zings' used for merging files remain three-character, so now it's
easily possible to distinguish messages from installed file list.

The PR doing this is: https://github.com/gentoo/portage/pull/759

Example screenshot:
https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Wolfgang E. Sanyer]

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

I love it - this is similar to the xorg log output, and i think it makes
the portage output much cleaner and easier to read.

El mar., 28 de septiembre de 2021 11:36 a. m., Michał Górny <
mgorny@gentoo.org> escribió:

> Hi, everyone.
>
> I know I'm going to regret asking this... but I've prepared a change to
> the Portage output format and I think it asks for a wider discussion
> than internally in Portage team.
>
> The primary problem with the current output format is that different
> kinds of messages differ only in color.  This makes them
> indistinguishable without colors and hard to grep.  ago's been asking
> for a better way to grep for QA warnings and this is pretty much what
> motivated me to do this.
>
> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.  For example,
> instead of:
>
>  * some message
>  * other message
>  * hell if i know what this is
>
> You get:
>
> [WW] some message
> [EE] other message
> [QA] hell if i know what this is
>
> I've also added more colors to explicitly distinguish einfo from elog,
> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> used by Portage with four-character versions to keep messages aligned.
> The 'zings' used for merging files remain three-character, so now it's
> easily possible to distinguish messages from installed file list.
>
> The PR doing this is: https://github.com/gentoo/portage/pull/759
>
> Example screenshot:
>
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
>
> --
> Best regards,
> Michał Górny
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 2370 bytes --]

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ulrich Mueller]

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

>>>>> On Tue, 28 Sep 2021, Michał Górny wrote:

> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.

Using the same markers as Xorg (especially [--]) but with different
meaning may be confusing though. Xorg has these:

    Markers: (--) probed, (**) from config file, (==) default setting,
    (++) from command line, (!!) notice, (II) informational,
    (WW) warning, (EE) error, (NI) not implemented, (??) unknown.

So, maybe change einfo from [--] to [II]?

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote:
> > > > > > On Tue, 28 Sep 2021, Michał Górny wrote:
> 
> > The proposed new format distinguished message types both using
> > colors
> > and strings.  This is roughly inspired by Xorg logs.
> 
> Using the same markers as Xorg (especially [--]) but with different
> meaning may be confusing though. Xorg has these:
> 
>     Markers: (--) probed, (**) from config file, (==) default setting,
>     (++) from command line, (!!) notice, (II) informational,
>     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> 
> So, maybe change einfo from [--] to [II]?

Nah, the whole point is to avoid letters since it's not very important.
Alternatively to '[--]' I could make it look down '[..]' or maybe even
without eyes entirely '[  ]'.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ulrich Mueller]

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

>>>>> On Tue, 28 Sep 2021, Michał Górny wrote:

> On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote:
>>     Markers: (--) probed, (**) from config file, (==) default setting,
>>     (++) from command line, (!!) notice, (II) informational,
>>     (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
>> 
>> So, maybe change einfo from [--] to [II]?

> Nah, the whole point is to avoid letters since it's not very important.
> Alternatively to '[--]' I could make it look down '[..]' or maybe even
> without eyes entirely '[  ]'.

Yeah, anything but [--]. The version with the dots is nice.

Ulrich

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Hank Leininger]

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

On 2021-09-28, Ulrich Mueller wrote:
> >>>>> On Tue, 28 Sep 2021, Michał Górny wrote:
> > On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote:
> >>         Markers: (--) probed, (**) from config file, (==) default
> >>         setting,
> >>         (++) from command line, (!!) notice, (II) informational,
> >>         (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> >> 
> >> So, maybe change einfo from [--] to [II]?
> 
> > Nah, the whole point is to avoid letters since it's not very
> > important.
> > Alternatively to '[--]' I could make it look down '[..]' or maybe even
> > without eyes entirely '[  ]'.
> 
> Yeah, anything but [--]. The version with the dots is nice.

I think any change from only-color would be an improvement; mgorny's
first version looks nice.

I can see why symmetry with Xorg EE, WW, etc. has an appeal but also the
downsides of a) since things don't actually line up 1:1 it could be
misleading to try; b) it's also somewhat language-biased.

Something a lot of tools have started doing is [?] prefixes to their
output; I don't know if there's even a semi-formal spec on it, but what
seems to me to map well would be:

[!] fatal error (die / eerror?)
[*] important but nonfatal (ewarn?)
[+] info, maybe memorable, but not harmful (elog?)
[.] status/verbose message (einfo?)

Could double that if preserving a 4-char-wide tag is preferred.

That doesn't cover all needed, like eqawarn, but there are more to
choose from.

It's unfortunate that many of these are regex metacharacters, making
slightly more (human) overhead when grepping, but we already have that
with the [] delimeters.

> > or maybe even without eyes entirely '[  ]'.

For no reason I can articulate, the empty one bugs me. I would get over
it though ;)

Thanks,

-- 

Hank Leininger <hlein@korelogic.com>
9606 3BF9 B593 4CBC E31A  A384 6200 F6E3 781E 3DD7

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

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

On 9/28/21 8:36 AM, Michał Górny wrote:
> Hi, everyone.
>
> I know I'm going to regret asking this... but I've prepared a change to
> the Portage output format and I think it asks for a wider discussion
> than internally in Portage team.
>
> The primary problem with the current output format is that different
> kinds of messages differ only in color.  This makes them
> indistinguishable without colors and hard to grep.  ago's been asking
> for a better way to grep for QA warnings and this is pretty much what
> motivated me to do this.
>
> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.  For example,
> instead of:
>
>  * some message
>  * other message
>  * hell if i know what this is
>
> You get:
>
> [WW] some message
> [EE] other message
> [QA] hell if i know what this is
>
> I've also added more colors to explicitly distinguish einfo from elog,
> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> used by Portage with four-character versions to keep messages aligned. 
> The 'zings' used for merging files remain three-character, so now it's
> easily possible to distinguish messages from installed file list.

Didn't expect to be the only dissenting opinion on something like this
but. . . Some applications parse portage output looking for these
'zings'. At very least app-portage/kuroo does it this way; there must be
others, right? This is obviously not the ideal way to get information
out of portage, but it's been stable for the 15 years Kuroo has existed.
10-ish years ago dol-sen started some work on building and API for
portage, but then got sucked into core portage development to the point
of abandoning their GTK+ portage GUI porthole, which was the original
impetus for an API, and as far as we know, the API never made it to the
point it could replace parsing the output.

It wouldn't be worth blocking progress for one application that not many
people use, but assuming there are others that will also break with this
change. Are we sure there's no way to support ago's (very valuable) work
without breaking other things?

-A

>
> The PR doing this is: https://github.com/gentoo/portage/pull/759
>
> Example screenshot:
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
>


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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Francesco Riosa]

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

Il giorno mer 29 set 2021 alle ore 23:52 A Schenck <lane_andrew@hotmail.com>
ha scritto:

> On 9/28/21 8:36 AM, Michał Górny wrote:
> > Hi, everyone.
> >
> > I know I'm going to regret asking this... but I've prepared a change to
> > the Portage output format and I think it asks for a wider discussion
> > than internally in Portage team.
> >
> > The primary problem with the current output format is that different
> > kinds of messages differ only in color.  This makes them
> > indistinguishable without colors and hard to grep.  ago's been asking
> > for a better way to grep for QA warnings and this is pretty much what
> > motivated me to do this.
> >
> > The proposed new format distinguished message types both using colors
> > and strings.  This is roughly inspired by Xorg logs.  For example,
> > instead of:
> >
> >  * some message
> >  * other message
> >  * hell if i know what this is
> >
> > You get:
> >
> > [WW] some message
> > [EE] other message
> > [QA] hell if i know what this is
> >
> > I've also added more colors to explicitly distinguish einfo from elog,
> > and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > used by Portage with four-character versions to keep messages aligned.
> > The 'zings' used for merging files remain three-character, so now it's
> > easily possible to distinguish messages from installed file list.
>
> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.
>
> It wouldn't be worth blocking progress for one application that not many
> people use, but assuming there are others that will also break with this
> change. Are we sure there's no way to support ago's (very valuable) work
> without breaking other things?
>
> -A
>

Kuroo is already a quite complex application that parse portage output. A
quick grep seems to show that changes needed are quite manageable.
Also the parsing should be more accurate with proposed changes.
Rather it should be easy for the application to know in advance which
format the output will be.
There is also the opportunity to have a flag that enable (or disable) the
augmented output, but IMHO this should be done only if the added complexity
is NIL

$ grep -c  -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1  | grep -v
:0$
kuroo-1.2.1/TODO:1
kuroo-1.2.1/src/history/history.cpp:3
kuroo-1.2.1/src/config/configdialog.h:2
kuroo-1.2.1/src/queue/queuelistview.cpp:1
kuroo-1.2.1/src/core/scanupdatesjob.cpp:1
kuroo-1.2.1/src/core/global.h:2
kuroo-1.2.1/src/core/packageinspector.cpp:4
kuroo-1.2.1/src/core/packageversion.h:2
kuroo-1.2.1/src/core/etcupdate.h:1
kuroo-1.2.1/src/core/portagedb.cpp:2
kuroo-1.2.1/src/core/scanhistoryjob.cpp:3
kuroo-1.2.1/src/core/global.cpp:1
kuroo-1.2.1/src/core/dependatom.h:2
kuroo-1.2.1/src/core/emerge.cpp:8




>
> >
> > The PR doing this is: https://github.com/gentoo/portage/pull/759
> >
> > Example screenshot:
> >
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
> >
>
>

[-- Attachment #2: Type: text/html, Size: 4865 bytes --]

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Sam James]

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



> On 29 Sep 2021, at 22:52, A Schenck <lane_andrew@hotmail.com> wrote:
> 
> [snip]

> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.
> 

Valid point, and I wish that we could get more useful information out
of Portage with easy APIs.

> It wouldn't be worth blocking progress for one application that not many
> people use, but assuming there are others that will also break with this
> change. Are we sure there's no way to support ago's (very valuable) work
> without breaking other things?

Note that this isn't just for ago's purposes. One, it makes it easier to generally
grep or parse portage output, but also (very importantly), it makes Portage's
output more _accessible_.

Right now, Portage is *way* too reliant on colour, which isn't very helpful
for colourblind or eyesight impaired users/developers.

> -A
> 
>> 
>> The PR doing this is: https://github.com/gentoo/portage/pull/759
>> 
>> Example screenshot:
>> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png

best,
sam


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Fabian Groffen]

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

Hi,

Would it be possible to have some switch (e.g. --style=legacy) that
controls this new vs. the old behaviour?  Would perhaps allow
applications that parse the output to work via setting this in the
global opts.

In addition, much like the colour map, how do you see this change in
light of eclasses, init-scripts, etc. that also use the same scheme as
Portage at the moment?  Would you expect to change those too at some
point?

Final question, am I understanding correctly that normal lines are not
prefixed with something?  Would it be, for consistency, alignment, and
certainty of selecting rows something to use a prefix for those lines
too (assuming they aren't at this point)?

Thanks,
Fabian

On 28-09-2021 17:36:25 +0200, Michał Górny wrote:
> Hi, everyone.
> 
> I know I'm going to regret asking this... but I've prepared a change to
> the Portage output format and I think it asks for a wider discussion
> than internally in Portage team.
> 
> The primary problem with the current output format is that different
> kinds of messages differ only in color.  This makes them
> indistinguishable without colors and hard to grep.  ago's been asking
> for a better way to grep for QA warnings and this is pretty much what
> motivated me to do this.
> 
> The proposed new format distinguished message types both using colors
> and strings.  This is roughly inspired by Xorg logs.  For example,
> instead of:
> 
>  * some message
>  * other message
>  * hell if i know what this is
> 
> You get:
> 
> [WW] some message
> [EE] other message
> [QA] hell if i know what this is
> 
> I've also added more colors to explicitly distinguish einfo from elog,
> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> used by Portage with four-character versions to keep messages aligned. 
> The 'zings' used for merging files remain three-character, so now it's
> easily possible to distinguish messages from installed file list.
> 
> The PR doing this is: https://github.com/gentoo/portage/pull/759
> 
> Example screenshot:
> https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
> 
> -- 
> Best regards,
> Michał Górny
> 
> 
> 

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
> Hi,
> 
> Would it be possible to have some switch (e.g. --style=legacy) that
> controls this new vs. the old behaviour?  Would perhaps allow
> applications that parse the output to work via setting this in the
> global opts.

Patches welcome.  It shouldn't be hard, my commit shows which files need
to be edited to alter the prefixes and how to pass them into ebd.

> 
> In addition, much like the colour map, how do you see this change in
> light of eclasses, init-scripts, etc. that also use the same scheme as
> Portage at the moment?  Would you expect to change those too at some
> point?

Eclasses are supposed to use standard einfo, elog... functions, so they
should just work™.  If someone's reinventing the wheel, it's not my
problem.

Init scripts aren't supposed to be used inside the PM, so that's out of
scope.

> Final question, am I understanding correctly that normal lines are not
> prefixed with something?  Would it be, for consistency, alignment, and
> certainty of selecting rows something to use a prefix for those lines
> too (assuming they aren't at this point)?

I don't know, we've never done that.  I suppose it would be possible but
it is even more controversial and unlike the proposed changes, it would
actually require mangling the process output.


-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Fabian Groffen]

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

On 30-09-2021 08:44:33 +0200, Michał Górny wrote:
> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
> > Hi,
> > 
> > Would it be possible to have some switch (e.g. --style=legacy) that
> > controls this new vs. the old behaviour?  Would perhaps allow
> > applications that parse the output to work via setting this in the
> > global opts.
> 
> Patches welcome.  It shouldn't be hard, my commit shows which files need
> to be edited to alter the prefixes and how to pass them into ebd.

I see.

> > In addition, much like the colour map, how do you see this change in
> > light of eclasses, init-scripts, etc. that also use the same scheme as
> > Portage at the moment?  Would you expect to change those too at some
> > point?
> 
> Eclasses are supposed to use standard einfo, elog... functions, so they
> should just work™.  If someone's reinventing the wheel, it's not my
> problem.
> 
> Init scripts aren't supposed to be used inside the PM, so that's out of
> scope.

I was just referring to the overall "feel" of Gentoo, which your work
changes.  It is ok that you don't plan on doing anything there.

> > Final question, am I understanding correctly that normal lines are not
> > prefixed with something?  Would it be, for consistency, alignment, and
> > certainty of selecting rows something to use a prefix for those lines
> > too (assuming they aren't at this point)?
> 
> I don't know, we've never done that.  I suppose it would be possible but
> it is even more controversial and unlike the proposed changes, it would
> actually require mangling the process output.

If I remember correctly, Portage already does.  In which case, doing
this (even if it were adding leading spaces) would not be that much
work?

Thanks,
Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

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

On 9/29/21 11:44 PM, Michał Górny wrote:
> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
>> Hi,
>>
>> Would it be possible to have some switch (e.g. --style=legacy) that
>> controls this new vs. the old behaviour?  Would perhaps allow
>> applications that parse the output to work via setting this in the
>> global opts.
> Patches welcome.  It shouldn't be hard, my commit shows which files need
> to be edited to alter the prefixes and how to pass them into ebd.

Would it be possible to get this patch in an format that it can be
interacted with with open tools? Per the other branch of this thread,
we'd be happy to make this an opt-in so as to not break existing people.

-A



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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Alec Warner]

On Fri, Oct 1, 2021 at 11:30 AM A Schenck <lane_andrew@hotmail.com> wrote:
>
> On 9/29/21 11:44 PM, Michał Górny wrote:
> > On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
> >> Hi,
> >>
> >> Would it be possible to have some switch (e.g. --style=legacy) that
> >> controls this new vs. the old behaviour?  Would perhaps allow
> >> applications that parse the output to work via setting this in the
> >> global opts.
> > Patches welcome.  It shouldn't be hard, my commit shows which files need
> > to be edited to alter the prefixes and how to pass them into ebd.
>
> Would it be possible to get this patch in an format that it can be
> interacted with with open tools? Per the other branch of this thread,
> we'd be happy to make this an opt-in so as to not break existing people.

I'm not sure what you mean; you can download the PR...

https://github.com/gentoo/portage/pull/759

-A

>
> -A
>
>

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Joshua Kinard]

On 9/30/2021 02:40, Fabian Groffen wrote:
> Hi,
> 
> Would it be possible to have some switch (e.g. --style=legacy) that
> controls this new vs. the old behaviour?  Would perhaps allow
> applications that parse the output to work via setting this in the
> global opts.

Perhaps this would be better as a FEATURE flag?  E.g., 'legacy-output' or
something similar?


> In addition, much like the colour map, how do you see this change in
> light of eclasses, init-scripts, etc. that also use the same scheme as
> Portage at the moment?  Would you expect to change those too at some
> point?
> 
> Final question, am I understanding correctly that normal lines are not
> prefixed with something?  Would it be, for consistency, alignment, and
> certainty of selecting rows something to use a prefix for those lines
> too (assuming they aren't at this point)?
> 
> Thanks,
> Fabian


-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

[-- Attachment #1.1.1: Type: text/plain, Size: 5443 bytes --]

On 9/29/21 3:58 PM, Francesco Riosa wrote:
> Il giorno mer 29 set 2021 alle ore 23:52 A Schenck
> <lane_andrew@hotmail.com <mailto:lane_andrew@hotmail.com>> ha scritto:
>
>     On 9/28/21 8:36 AM, Michał Górny wrote:
>     > Hi, everyone.
>     >
>     > I know I'm going to regret asking this... but I've prepared a
>     change to
>     > the Portage output format and I think it asks for a wider discussion
>     > than internally in Portage team.
>     >
>     > The primary problem with the current output format is that different
>     > kinds of messages differ only in color.  This makes them
>     > indistinguishable without colors and hard to grep.  ago's been
>     asking
>     > for a better way to grep for QA warnings and this is pretty much
>     what
>     > motivated me to do this.
>     >
>     > The proposed new format distinguished message types both using
>     colors
>     > and strings.  This is roughly inspired by Xorg logs.  For example,
>     > instead of:
>     >
>     >  * some message
>     >  * other message
>     >  * hell if i know what this is
>     >
>     > You get:
>     >
>     > [WW] some message
>     > [EE] other message
>     > [QA] hell if i know what this is
>     >
>     > I've also added more colors to explicitly distinguish einfo from
>     elog,
>     > and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
>     > used by Portage with four-character versions to keep messages
>     aligned.
>     > The 'zings' used for merging files remain three-character, so
>     now it's
>     > easily possible to distinguish messages from installed file list.
>
>     Didn't expect to be the only dissenting opinion on something like this
>     but. . . Some applications parse portage output looking for these
>     'zings'. At very least app-portage/kuroo does it this way; there
>     must be
>     others, right? This is obviously not the ideal way to get information
>     out of portage, but it's been stable for the 15 years Kuroo has
>     existed.
>     10-ish years ago dol-sen started some work on building and API for
>     portage, but then got sucked into core portage development to the
>     point
>     of abandoning their GTK+ portage GUI porthole, which was the original
>     impetus for an API, and as far as we know, the API never made it
>     to the
>     point it could replace parsing the output.
>
>     It wouldn't be worth blocking progress for one application that
>     not many
>     people use, but assuming there are others that will also break
>     with this
>     change. Are we sure there's no way to support ago's (very
>     valuable) work
>     without breaking other things?
>
>     -A
>
>
> Kuroo is already a quite complex application that parse portage
> output. A quick grep seems to show that changes needed are quite
> manageable.
> Also the parsing should be more accurate with proposed changes.
> Rather it should be easy for the application to know in advance which
> format the output will be.
> There is also the opportunity to have a flag that enable (or disable)
> the augmented output, but IMHO this should be done only if the added
> complexity is NIL
>
> $ grep -c  -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1  | grep
> -v :0$
> kuroo-1.2.1/TODO:1
> kuroo-1.2.1/src/history/history.cpp:3
> kuroo-1.2.1/src/config/configdialog.h:2
> kuroo-1.2.1/src/queue/queuelistview.cpp:1
> kuroo-1.2.1/src/core/scanupdatesjob.cpp:1
> kuroo-1.2.1/src/core/global.h:2
> kuroo-1.2.1/src/core/packageinspector.cpp:4
> kuroo-1.2.1/src/core/packageversion.h:2
> kuroo-1.2.1/src/core/etcupdate.h:1
> kuroo-1.2.1/src/core/portagedb.cpp:2
> kuroo-1.2.1/src/core/scanhistoryjob.cpp:3
> kuroo-1.2.1/src/core/global.cpp:1
> kuroo-1.2.1/src/core/dependatom.h:2
> kuroo-1.2.1/src/core/emerge.cpp:8
>
Alas and alack, just searching for regular expressions isn't enough,
there are places that use QString::startsWith and contains and mid, &c.
with literal QStrings. Tthere might be "spooky action at a distance" in
some fifteen year old code that used some esoteric method to parse
output because it was hip like -funroll-loops, and that could takes
years to track down and fix despite best efforts to fix all the obvious
QReg(|ular)Ex(|pression)s.

If the idea is to clean up old code that admins haven't looked at in
years because it "just worked"™, that's valid too; treecleaner project
is laudable for that. But if breaking things isn't the goal, then we
should consider if there are options to keep things working. Regarding
"added complexity": it would probably mean parsing one additional
optional command line argument or make.conf / environment variable, then
initialize format strings in elog/messages.py or output.py or something.
It would be a lot easier to figure out how if the patch was available on
free infrastructure rather than just looking randomly at portage code.

>
>  
>
>
>     >
>     > The PR doing this is: https://github.com/gentoo/portage/pull/759
>     <https://github.com/gentoo/portage/pull/759>
>     >
>     > Example screenshot:
>     >
>     https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
>     <https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png>
>     >
>

[-- Attachment #1.1.2: Type: text/html, Size: 8693 bytes --]

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

On Fri, 2021-10-01 at 18:00 -0400, Joshua Kinard wrote:
> On 9/30/2021 02:40, Fabian Groffen wrote:
> > Hi,
> > 
> > Would it be possible to have some switch (e.g. --style=legacy) that
> > controls this new vs. the old behaviour?  Would perhaps allow
> > applications that parse the output to work via setting this in the
> > global opts.
> 
> Perhaps this would be better as a FEATURE flag?  E.g., 'legacy-output' or
> something similar?
> 

No.  FEATURES is just a horrible historical mistake.  Proper
configuration uses separate keys for separate options.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ulrich Mueller]

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

>>>>> On Wed, 29 Sep 2021, A Schenck wrote:

> On 9/28/21 8:36 AM, Michał Górny wrote:
>> [WW] some message
>> [EE] other message
>> [QA] hell if i know what this is
>> 
>> I've also added more colors to explicitly distinguish einfo from elog,
>> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
>> used by Portage with four-character versions to keep messages aligned. 
>> The 'zings' used for merging files remain three-character, so now it's
>> easily possible to distinguish messages from installed file list.

> Didn't expect to be the only dissenting opinion on something like this
> but. . . Some applications parse portage output looking for these
> 'zings'. At very least app-portage/kuroo does it this way; there must be
> others, right? This is obviously not the ideal way to get information
> out of portage, but it's been stable for the 15 years Kuroo has existed.
> 10-ish years ago dol-sen started some work on building and API for
> portage, but then got sucked into core portage development to the point
> of abandoning their GTK+ portage GUI porthole, which was the original
> impetus for an API, and as far as we know, the API never made it to the
> point it could replace parsing the output.

If only the length of the >>> and !!! strings is a problem, then why not
leave them alone and go for single-letter tags instead? Like this:

   [.] einfo
   [I] elog
   [W] ewarn
   [E] eerror
   [Q] eqawarn

The only problematic one is [Q] instead of [QA] which is no longer
self-explanatory. Then again, only devs and experienced users should see
eqawarn messages.

Ulrich

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

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

On 10/1/21 11:32 AM, Alec Warner wrote:
> On Fri, Oct 1, 2021 at 11:30 AM A Schenck <lane_andrew@hotmail.com> wrote:
>> On 9/29/21 11:44 PM, Michał Górny wrote:
>>> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
>>>> Hi,
>>>>
>>>> Would it be possible to have some switch (e.g. --style=legacy) that
>>>> controls this new vs. the old behaviour?  Would perhaps allow
>>>> applications that parse the output to work via setting this in the
>>>> global opts.
>>> Patches welcome.  It shouldn't be hard, my commit shows which files need
>>> to be edited to alter the prefixes and how to pass them into ebd.
>> Would it be possible to get this patch in an format that it can be
>> interacted with with open tools? Per the other branch of this thread,
>> we'd be happy to make this an opt-in so as to not break existing people.
> I'm not sure what you mean; you can download the PR...
>
> https://github.com/gentoo/portage/pull/759
>
> -A

This isn't really the place to rehash the whole discussion of free
speech vs. free beer: http://www.gnu.org/philosophy/free-sw-en.html .
Suffice to say the Gentoo Social Contract
(https://www.gentoo.org/get-started/philosophy/social-contract.html#gentoo-is-and-will-remain-free-software)
states: "Gentoo will never depend upon a piece of software or metadata
unless it conforms to the GNU General Public License, the GNU Lesser
General Public License, the Creative Commons - Attribution/Share Alike
or some other license approved by the Open Source Initiative"; which
GitHub does not conform to:
https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub .
Further reading (linked from gnu.org) at
https://sanctum.geek.nz/why-not-github.html , and of course we all know
that Microsoft acquired GitHub, and of course Microsoft has a history of
suing Free / Libre / Open Source Software creators and users.

Further discussion belongs on a different list, but the link provided by
mgorny and repeated by you does not allow collaborating in compliance
with the Gentoo Social Contract.

-A

>> -A
>>
>>


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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Mike Gilbert]

On Sat, Oct 2, 2021 at 1:25 PM A Schenck <lane_andrew@hotmail.com> wrote:
> Further discussion belongs on a different list, but the link provided by
> mgorny and repeated by you does not allow collaborating in compliance
> with the Gentoo Social Contract.

The patches were also posted for review on the gentoo-portage-dev mailing list.

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ionen Wolkens]

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

On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote:
> >>>>> On Wed, 29 Sep 2021, A Schenck wrote:
> 
> > On 9/28/21 8:36 AM, Michał Górny wrote:
> >> [WW] some message
> >> [EE] other message
> >> [QA] hell if i know what this is
> >> 
> >> I've also added more colors to explicitly distinguish einfo from elog,
> >> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> >> used by Portage with four-character versions to keep messages aligned. 
> >> The 'zings' used for merging files remain three-character, so now it's
> >> easily possible to distinguish messages from installed file list.
> 
> > Didn't expect to be the only dissenting opinion on something like this
> > but. . . Some applications parse portage output looking for these
> > 'zings'. At very least app-portage/kuroo does it this way; there must be
> > others, right? This is obviously not the ideal way to get information
> > out of portage, but it's been stable for the 15 years Kuroo has existed.
> > 10-ish years ago dol-sen started some work on building and API for
> > portage, but then got sucked into core portage development to the point
> > of abandoning their GTK+ portage GUI porthole, which was the original
> > impetus for an API, and as far as we know, the API never made it to the
> > point it could replace parsing the output.
> 
> If only the length of the >>> and !!! strings is a problem, then why not
> leave them alone and go for single-letter tags instead? Like this:
> 
>    [.] einfo
>    [I] elog
>    [W] ewarn
>    [E] eerror
>    [Q] eqawarn
> 
> The only problematic one is [Q] instead of [QA] which is no longer
> self-explanatory. Then again, only devs and experienced users should see
> eqawarn messages.

fwiw eqawarn is currently displayed for everyone in a similar manner
as einfo, just not post-emerge/elog without adding to ELOG classes.

If users aren't hiding build logs entirely, they may notice those
done at the end (often shown after size report) -- and possibly
think it's a problem.

Not to say whether [Q] vs [QA] would help with this much so I have
no strong opinion here.
-- 
ionen

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ionen Wolkens]

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

On Sat, Oct 02, 2021 at 06:04:36PM -0400, Ionen Wolkens wrote:
> On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote:
> > >>>>> On Wed, 29 Sep 2021, A Schenck wrote:
> > 
> > > On 9/28/21 8:36 AM, Michał Górny wrote:
> > >> [WW] some message
> > >> [EE] other message
> > >> [QA] hell if i know what this is
> > >> 
> > >> I've also added more colors to explicitly distinguish einfo from elog,
> > >> and ewarn from eqawarn.  Then, I've replaced most of '>>>' and '!!!'
> > >> used by Portage with four-character versions to keep messages aligned. 
> > >> The 'zings' used for merging files remain three-character, so now it's
> > >> easily possible to distinguish messages from installed file list.
> > 
> > > Didn't expect to be the only dissenting opinion on something like this
> > > but. . . Some applications parse portage output looking for these
> > > 'zings'. At very least app-portage/kuroo does it this way; there must be
> > > others, right? This is obviously not the ideal way to get information
> > > out of portage, but it's been stable for the 15 years Kuroo has existed.
> > > 10-ish years ago dol-sen started some work on building and API for
> > > portage, but then got sucked into core portage development to the point
> > > of abandoning their GTK+ portage GUI porthole, which was the original
> > > impetus for an API, and as far as we know, the API never made it to the
> > > point it could replace parsing the output.
> > 
> > If only the length of the >>> and !!! strings is a problem, then why not
> > leave them alone and go for single-letter tags instead? Like this:
> > 
> >    [.] einfo
> >    [I] elog
> >    [W] ewarn
> >    [E] eerror
> >    [Q] eqawarn
> > 
> > The only problematic one is [Q] instead of [QA] which is no longer
> > self-explanatory. Then again, only devs and experienced users should see
> > eqawarn messages.
> 
> fwiw eqawarn is currently displayed for everyone in a similar manner
> as einfo, just not post-emerge/elog without adding to ELOG classes.
> 
> If users aren't hiding build logs entirely, they may notice those
> done at the end (often shown after size report) -- and possibly
> think it's a problem.
> 
> Not to say whether [Q] vs [QA] would help with this much so I have
> no strong opinion here.

Guess there's a lot of other options that could be considered as well.

--- files
>>> text
 * current, it wasn't aligned now that I look at it again
(relying only on color to convey type feels clearly wrong to me)

--- files
>>>> text
[QA] new based on current PR

>>> text
[QA] aligned 1 character further, maybe skipping changing >>> is fine?
(then again that it's further is what threw me off at first)

>>> text
QA* similar to before, but aligned using only 3 chars

>>> text
[Q] kinda more obscure but it can work

>>>> text
QA* probably closest to how it was before alignment-wise, but meh at 4 >

>>> message
QA> not convinced about this one, but throwing it here anyway
(other characters could be considered as well)

Maybe a poll of some kind may help, personally undecided on what I
like better beside agreeing that a change is needed.

-- 
ionen

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ionen Wolkens]

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

On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote:
> Guess there's a lot of other options that could be considered as well.
> 
> --- files
> >>> text
>  * current, it wasn't aligned now that I look at it again
> (relying only on color to convey type feels clearly wrong to me)
> 
> --- files
> >>>> text
> [QA] new based on current PR
> 
> >>> text
> [QA] aligned 1 character further, maybe skipping changing >>> is fine?
> (then again that it's further is what threw me off at first)
> 
> >>> text
> QA* similar to before, but aligned using only 3 chars
> 
> >>> text
> [Q] kinda more obscure but it can work
> 

Guess should also add these:
>>> text
Q* Notice:
E* Some error happened
(closest to before by making use of the former leading space, thus
 no alignment changes)

>>> text
QA Notice:
EE Some error happened
(at least clearer than Q* Notice, but unsure about no separator.. guess
it could work?)

> >>>> text
> QA* probably closest to how it was before alignment-wise, but meh at 4 >
> 
> >>> message
> QA> not convinced about this one, but throwing it here anyway
> (other characters could be considered as well)
> 
> Maybe a poll of some kind may help, personally undecided on what I
> like better beside agreeing that a change is needed.


-- 
ionen

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Fabian Groffen]

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

On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote:
> On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote:
> > Guess there's a lot of other options that could be considered as well.
> > 
> > --- files
> > >>> text
> >  * current, it wasn't aligned now that I look at it again
> > (relying only on color to convey type feels clearly wrong to me)
> > 
> > --- files
> > >>>> text
> > [QA] new based on current PR
> > 
> > >>> text
> > [QA] aligned 1 character further, maybe skipping changing >>> is fine?
> > (then again that it's further is what threw me off at first)
> > 
> > >>> text
> > QA* similar to before, but aligned using only 3 chars
> > 
> > >>> text
> > [Q] kinda more obscure but it can work
> > 
> 
> Guess should also add these:
> >>> text
> Q* Notice:
> E* Some error happened
> (closest to before by making use of the former leading space, thus
>  no alignment changes)

FWIW, I like this one.  Perhaps even with lowercase

make[4]: leaving directory src
q* soname lacks version
e* failed to die

Fabian

> 
> >>> text
> QA Notice:
> EE Some error happened
> (at least clearer than Q* Notice, but unsure about no separator.. guess
> it could work?)
> 
> > >>>> text
> > QA* probably closest to how it was before alignment-wise, but meh at 4 >
> > 
> > >>> message
> > QA> not convinced about this one, but throwing it here anyway
> > (other characters could be considered as well)
> > 
> > Maybe a poll of some kind may help, personally undecided on what I
> > like better beside agreeing that a change is needed.
> 
> 
> -- 
> ionen



-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Ionen Wolkens]

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

On Sun, Oct 03, 2021 at 08:58:00AM +0200, Fabian Groffen wrote:
> On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote:
> > On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote:
> > > Guess there's a lot of other options that could be considered as well.
> > > 
> > > --- files
> > > >>> text
> > >  * current, it wasn't aligned now that I look at it again
> > > (relying only on color to convey type feels clearly wrong to me)
> > > 
> > > --- files
> > > >>>> text
> > > [QA] new based on current PR
> > > 
> > > >>> text
> > > [QA] aligned 1 character further, maybe skipping changing >>> is fine?
> > > (then again that it's further is what threw me off at first)
> > > 
> > > >>> text
> > > QA* similar to before, but aligned using only 3 chars
> > > 
> > > >>> text
> > > [Q] kinda more obscure but it can work
> > > 
> > 
> > Guess should also add these:
> > >>> text
> > Q* Notice:
> > E* Some error happened
> > (closest to before by making use of the former leading space, thus
> >  no alignment changes)
> 
> FWIW, I like this one.  Perhaps even with lowercase
> 
> make[4]: leaving directory src
> q* soname lacks version
> e* failed to die

Also I guess it provides some degree of compatibility with external
scripts/tools that adopted the ` * ` format to copy portage.
i.e. could actually keep ` * ` for einfo, no need for `.* ` here.

Lowercase might be a good idea too, albeit I'm still undecided on
what I like best in general.

> 
> Fabian
> 
> > 
> > >>> text
> > QA Notice:
> > EE Some error happened
> > (at least clearer than Q* Notice, but unsure about no separator.. guess
> > it could work?)
> > 
> > > >>>> text
> > > QA* probably closest to how it was before alignment-wise, but meh at 4 >
> > > 
> > > >>> message
> > > QA> not convinced about this one, but throwing it here anyway
> > > (other characters could be considered as well)
> > > 
> > > Maybe a poll of some kind may help, personally undecided on what I
> > > like better beside agreeing that a change is needed.
> > 
> > 
> > -- 
> > ionen
> 
> 
> 
> -- 
> Fabian Groffen
> Gentoo on a different level



-- 
ionen

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Alexey Sokolov]

03.10.2021 07:58, Fabian Groffen пишет:
> 
> FWIW, I like this one.  Perhaps even with lowercase
> 
> make[4]: leaving directory src
> q* soname lacks version
> e* failed to die
> 

For me this reads as some kind of censorship to remove profanities from
the output; and my mind is trying to reconstruct what profanity it was...


-- 
Best regards,
Alexey "DarthGandalf" Sokolov

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

On Tue, 2021-09-28 at 17:36 +0200, Michał Górny wrote:
> I know I'm going to regret asking this... but I've prepared a change to
> the Portage output format and I think it asks for a wider discussion
> than internally in Portage team.

As I suspected, I truly regret sending this mail.  I'm dangerously close
to burning out, so I'm going to retract these patches.  When you decide
what you want and make patches for it, feel free to send them to
Portage.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Michał Górny]

On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote:
> > > Final question, am I understanding correctly that normal lines are not
> > > prefixed with something?  Would it be, for consistency, alignment, and
> > > certainty of selecting rows something to use a prefix for those lines
> > > too (assuming they aren't at this point)?
> > 
> > I don't know, we've never done that.  I suppose it would be possible but
> > it is even more controversial and unlike the proposed changes, it would
> > actually require mangling the process output.
> 
> If I remember correctly, Portage already does.  In which case, doing
> this (even if it were adding leading spaces) would not be that much
> work?
> 

I'm afraid this is not that simple.  You need to account for all escape
sequences that can affect editing already output data including clean
handling of line wrapping.  In the end, we'd have to have a complete
detachtty-class terminal emulator inside Portage.

-- 
Best regards,
Michał Górny

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Fabian Groffen]

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

On 05-10-2021 09:35:32 +0200, Michał Górny wrote:
> On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote:
> > > > Final question, am I understanding correctly that normal lines are not
> > > > prefixed with something?  Would it be, for consistency, alignment, and
> > > > certainty of selecting rows something to use a prefix for those lines
> > > > too (assuming they aren't at this point)?
> > > 
> > > I don't know, we've never done that.  I suppose it would be possible but
> > > it is even more controversial and unlike the proposed changes, it would
> > > actually require mangling the process output.
> > 
> > If I remember correctly, Portage already does.  In which case, doing
> > this (even if it were adding leading spaces) would not be that much
> > work?
> > 
> 
> I'm afraid this is not that simple.  You need to account for all escape
> sequences that can affect editing already output data including clean
> handling of line wrapping.  In the end, we'd have to have a complete
> detachtty-class terminal emulator inside Portage.

Fair enough, thanks for looking into it.

Fabian

-- 
Fabian Groffen
Gentoo on a different level

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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[A Schenck]

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

On 10/2/21 10:51 AM, Mike Gilbert wrote:
> On Sat, Oct 2, 2021 at 1:25 PM A Schenck <lane_andrew@hotmail.com> wrote:
>> Further discussion belongs on a different list, but the link provided by
>> mgorny and repeated by you does not allow collaborating in compliance
>> with the Gentoo Social Contract.
> The patches were also posted for review on the gentoo-portage-dev mailing list.
Thanks. The patch is a bit messier than hoped but it's a starting point.


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

Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change

[Rich Freeman]

On Mon, Oct 4, 2021 at 2:48 AM Michał Górny <mgorny@gentoo.org> wrote:
>
> On Tue, 2021-09-28 at 17:36 +0200, Michał Górny wrote:
> > I know I'm going to regret asking this... but I've prepared a change to
> > the Portage output format and I think it asks for a wider discussion
> > than internally in Portage team.
>
> As I suspected, I truly regret sending this mail.  I'm dangerously close
> to burning out, so I'm going to retract these patches.  When you decide
> what you want and make patches for it, feel free to send them to
> Portage.

Keep in mind that while distributing patches and soliciting comments
is a good practice, I don't believe any of our policies REQUIRE that
you:

1.  Reply to anybody who comments.
2.  Address any comments.
3.  Wait until anybody (let alone everybody) agrees before proceeding.

I think that we sometimes let the requirement to communicate somehow
stifle the desire to get things done.  While I don't recommend it, you
can technically satisfy any communications requirements by posting
your patch and literally never checking your email before committing
it.  Obviously if you mess something up in doing so you'll look dumb,
but it isn't intended to be a bureaucratic requirement.

I suggest just skimming the comments to see if there is anything that
seems like a good idea, then implementing those ideas (which you'll
probably want to do anyway), and ignore the rest without comment.  If
somebody has a problem with what you're doing, the onus is on them to
go find somebody to complain to in order to stop you.  If you're the
maintainer then you don't need permission to commit.

In my experience the Council is fairly resistant to requests to meddle
for things that aren't super-critical, so I'd be shocked if they
didn't just ack and dismiss any request to bikeshed exactly what
prefix your elog output uses.

Open to contrary opinions, but IMO I think maintainers perceive that
the distro is more consensus-driven than it actually is.  You don't
have to "win" the email battle.

-- 
Rich