Discussions about non-technical issues in the Gentoo project ()

Thomas Sachau | 4 Dec 2011 15:17

Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Fabian Groffen schrieb:
> All,
> 
> Apologies for the short notice in advance.
> 
> In a little more than one week, the council will meet again.  This is
> the time to raise and prepare items that the council should put on the
> agenda to vote on.
> 
> Please respond to this email with agenda items.  Please do not hestitate
> to repeat your agenda item here with a pointer if you previously
> suggested one (since the last meeting).
> 
> The agenda for the next meeting will be sent out on Tuesday 6th of
> December 2011.
> 
> Please respond to gentoo-project list, if possible.
> 
> 

1. Should the change of quiet build default in recent portage versions
be reverted?

The timeframe between suggestion and implementation was less than 14
hours, so way too less time for a real discussion. Additionally, the
discussion following the change has shown, that there is no consensus
about this change neither for developers nor for users. So i would like
to see this reverted, at least until we get to a consensus at this topic
in which case the consensus result should be implemented.

(Continue reading)

headers

Fabian Groffen | 4 Dec 2011 16:22

Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On 04-12-2011 15:17:28 +0100, Thomas Sachau wrote:
> 1. Should the change of quiet build default in recent portage versions
> be reverted?
> 
> The timeframe between suggestion and implementation was less than 14
> hours, so way too less time for a real discussion. Additionally, the
> discussion following the change has shown, that there is no consensus
> about this change neither for developers nor for users. So i would like
> to see this reverted, at least until we get to a consensus at this topic
> in which case the consensus result should be implemented.

Ok, you mean the --quiet-build=y default that most recent Portage uses,
right?  Also known to some as the parallel build output.

> 2. Should the default output of portage be changed to quiet?
> 
> If yes, is a simple portage message for 2.1.* users enough to inform
> users about this highly visible change? Especially in the context in
> mind, that a good amount of packages have elog messages, so it is pretty
> easy to miss this hint for a change in portage behaviour.

You suggest a news item here?  Or do you want Portage in quiet mode to
print elog messages?  (If I'm not mistaken, it already does.)

--

-- 
Fabian Groffen
Gentoo on a different level

headers

Thomas Sachau | 4 Dec 2011 16:42

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Fabian Groffen schrieb:
> On 04-12-2011 15:17:28 +0100, Thomas Sachau wrote:
>> 1. Should the change of quiet build default in recent portage versions
>> be reverted?
>>
>> The timeframe between suggestion and implementation was less than 14
>> hours, so way too less time for a real discussion. Additionally, the
>> discussion following the change has shown, that there is no consensus
>> about this change neither for developers nor for users. So i would like
>> to see this reverted, at least until we get to a consensus at this topic
>> in which case the consensus result should be implemented.
> 
> Ok, you mean the --quiet-build=y default that most recent Portage uses,
> right?  Also known to some as the parallel build output.

Yes

> 
>> 2. Should the default output of portage be changed to quiet?
>>
>> If yes, is a simple portage message for 2.1.* users enough to inform
>> users about this highly visible change? Especially in the context in
>> mind, that a good amount of packages have elog messages, so it is pretty
>> easy to miss this hint for a change in portage behaviour.
> 
> You suggest a news item here?  Or do you want Portage in quiet mode to
> print elog messages?  (If I'm not mistaken, it already does.)
> 
>

(Continue reading)

headers

Markos Chandras | 4 Dec 2011 17:26

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13


On 12/04/2011 03:42 PM, Thomas Sachau wrote:
> Fabian Groffen schrieb:
>> Ok, you mean the --quiet-build=y default that most recent Portage
>> uses, right?  Also known to some as the parallel build output.
> 
> Yes
I agree that the decision was made too fast but reverting seems like a
joke to me. People will think that we are making fun of them by
changing the defaults all the time. Imho it is too late to go back.

> 
> If this does not get reverted and if it gets accepted to be the
> default, i would request a news item, when it goes into a stable
> version of portage, since a good amount of people wondered, why the
> portage output changed (default for --quiet-build was changed), why
> it was done and how they could change that behaviour.
> 
I certainly agree with that. People keep wondering why portage is so
quiet.

In any case I believe the council should discuss these problems in the
upcoming meeting

--

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

headers

Mike Gilbert | 4 Dec 2011 18:37

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On 12/04/2011 11:26 AM, Markos Chandras wrote:
> On 12/04/2011 03:42 PM, Thomas Sachau wrote:
>> Fabian Groffen schrieb:
>>> Ok, you mean the --quiet-build=y default that most recent Portage
>>> uses, right?  Also known to some as the parallel build output.
> 
>> Yes
> I agree that the decision was made too fast but reverting seems like a
> joke to me. People will think that we are making fun of them by
> changing the defaults all the time. Imho it is too late to go back.

Hopefully the meeting will result in an actual answer (yes/no to quiet
by default). It would be a shame if nothing is done simply because the
council does not meet often enough to make changes until it is "too late".

headers

Thomas Sachau | 4 Dec 2011 18:55

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Markos Chandras schrieb:
> On 12/04/2011 03:42 PM, Thomas Sachau wrote:
>> Fabian Groffen schrieb:
>>> Ok, you mean the --quiet-build=y default that most recent Portage
>>> uses, right?  Also known to some as the parallel build output.
> 
>> Yes
> I agree that the decision was made too fast but reverting seems like a
> joke to me. People will think that we are making fun of them by
> changing the defaults all the time. Imho it is too late to go back.

Such a decision would surely not be a joke. We are talking about the
testing version of portage here, not the stable one. While people might
wonder, why it was changed back, something like that should be expected,
if you dont use stable keywords.
Additionally, everyone could do whatever he wants with the "too late to
go back" - "argument". Just wait until after council meeting, do your
changes and claim "too late to go back", so effectively removing the
ability to decide about a question for the council?

headers

Markos Chandras | 4 Dec 2011 19:12

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13


On 12/04/2011 05:55 PM, Thomas Sachau wrote:
> Markos Chandras schrieb:
>> On 12/04/2011 03:42 PM, Thomas Sachau wrote:
>>> Fabian Groffen schrieb:
>>>> Ok, you mean the --quiet-build=y default that most recent
>>>> Portage uses, right?  Also known to some as the parallel
>>>> build output.
>> 
>>> Yes
>> I agree that the decision was made too fast but reverting seems
>> like a joke to me. People will think that we are making fun of
>> them by changing the defaults all the time. Imho it is too late
>> to go back.
> 
> Such a decision would surely not be a joke. We are talking about
> the testing version of portage here, not the stable one. While
> people might wonder, why it was changed back, something like that
> should be expected, if you dont use stable keywords. Additionally,
> everyone could do whatever he wants with the "too late to go back"
> - "argument". Just wait until after council meeting, do your 
> changes and claim "too late to go back", so effectively removing
> the ability to decide about a question for the council? 
> 
All I am saying is that the change is there for more than 2 weeks.
Imho it seems suboptimal (from user's experience perspective) to go
back to the old behavior without causing extra frustration.

--

-- 
Regards,

(Continue reading)

headers

Chí-Thanh Christopher Nguyễn | 4 Dec 2011 20:15

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Markos Chandras schrieb:
> All I am saying is that the change is there for more than 2 weeks.
> Imho it seems suboptimal (from user's experience perspective) to go
> back to the old behavior without causing extra frustration.

You can check the forums thread and poll for an indication how much
frustration this would create. Also the question is whether stabilizing
a quiet-build portage causes more frustration than reverting the change
in unstable.

https://forums.gentoo.org/viewtopic-t-901858.html
The poll has an unusually high number of respondents, maybe an
indication of how controversial that topic is.

Best regards,
Chí-Thanh Christopher Nguyễn

headers

Dale | 5 Dec 2011 01:11

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Chí-Thanh Christopher Nguyễn wrote:
> Markos Chandras schrieb:
>> All I am saying is that the change is there for more than 2 weeks.
>> Imho it seems suboptimal (from user's experience perspective) to go
>> back to the old behavior without causing extra frustration.
> You can check the forums thread and poll for an indication how much
> frustration this would create. Also the question is whether stabilizing
> a quiet-build portage causes more frustration than reverting the change
> in unstable.
>
> https://forums.gentoo.org/viewtopic-t-901858.html
> The poll has an unusually high number of respondents, maybe an
> indication of how controversial that topic is.
>
>
> Best regards,
> Chí-Thanh Christopher Nguyễn
>
>

I might also add, there have already been a couple people on the mailing 
lists wanting it back to the old way and thinking something in portage 
got broken.  Once it hits stable, there will likely be a lot of those 
threads both on the mailing lists and forums.  I actually added the 
option to my sig hoping people will see it and not have to ask.

I know there is plans for a news item but I have to also wonder if 
people are going to read and actually realize what the change was.

Dale

(Continue reading)

headers

Patrick Lauer | 5 Dec 2011 03:18

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On 12/05/11 00:26, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 12/04/2011 03:42 PM, Thomas Sachau wrote:
>> Fabian Groffen schrieb:
>>> Ok, you mean the --quiet-build=y default that most recent Portage
>>> uses, right?  Also known to some as the parallel build output.
>> Yes
> I agree that the decision was made too fast but reverting seems like a
> joke to me. People will think that we are making fun of them by
> changing the defaults all the time. Imho it is too late to go back.

Great, so if I just patch stuff I can also claim that now it's too late 
to revert?
That's a nice non-sequitur :)
>
>> If this does not get reverted and if it gets accepted to be the
>> default, i would request a news item, when it goes into a stable
>> version of portage, since a good amount of people wondered, why the
>> portage output changed (default for --quiet-build was changed), why
>> it was done and how they could change that behaviour.
>>
> I certainly agree with that. People keep wondering why portage is so
> quiet.
And spend much more time trying to find them silly logfiles now that we 
hide the output. I really enjoy having to fix yet another bad default 
everywhere just so I see *why* things fail ...

>

(Continue reading)

headers

Rich Freeman | 5 Dec 2011 03:49

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer <patrick <at> gentoo.org> wrote:
> And spend much more time trying to find them silly logfiles now that we hide
> the output. I really enjoy having to fix yet another bad default everywhere
> just so I see *why* things fail ...

Unless something has changed the logfile name including full path is
printed when there is an error.  So, it is just a matter of copy/paste
into a cat and you can watch the whole thing scroll by and even
pretend it is compiling really fast while it is doing it.  :)

It seems like a pretty sane default to assume that most packaged build
without issues - after all, that is basically the goal, right?

That is probably why the forum post is at 52-48 - it really isn't that
obvious a call one way or the other.  In any case, it doesn't affect
me anyway since I use parallel build and I trust the Council to at
least provide some kind of closure...

Rich

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 04:07

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Rich Freeman schrieb:
> That is probably why the forum post is at 52-48 - it really isn't that
> obvious a call one way or the other.  In any case, it doesn't affect
> me anyway since I use parallel build and I trust the Council to at
> least provide some kind of closure...

I don't know which forum post you are referring to, but in the linked
forums.g.o poll[1] the old vs. the new default is currently at 52-28
with the rest opting for the compromise or something else.

Note: It was already pointed out that this number is probably not
representative and may be skewed in one direction or the other due to
the "vocal minority" effect. It is just a small piece of data.

Best regards,
Chí-Thanh Christopher Nguyễn

[1] https://forums.gentoo.org/viewtopic-t-901858.html

headers

Rich Freeman | 5 Dec 2011 04:22

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh <at> gentoo.org>:
> I don't know which forum post you are referring to, but in the linked
> forums.g.o poll[1] the old vs. the new default is currently at 52-28
> with the rest opting for the compromise or something else.

-v is not itself a default, so if it controls the quiet output then
essentially a stock gentoo emerge command will be quiet.  I'd consider
that just another variance on quiet-by-default.

Otherwise the poll is like asking Americans whether they prefer the
Republicans, Democracts, Greens, Communists, Socialists, Moderate
Democrats, Conservative Democrats, Liberal Democrats, Ordinary
Democrats, Good-looking Democrats, or Reformed Democrats, and then
pronouncing that Republicans outnumber Democrats 48%-10%.

I won't dispute that a majority seem to prefer the old way - but 52-28
isn't really a clear depiction of this.  And no, this shouldn't
warrant having the elections team run a Condorcent vote (which should
handle issues like this).

Rich

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 04:54

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Rich Freeman schrieb:

> -v is not itself a default, so if it controls the quiet output then
> essentially a stock gentoo emerge command will be quiet.  I'd consider
> that just another variance on quiet-by-default.

If you take it like this:
69% of respondents want to see build output when -v is given (52+17).
28% disagree with that.

45% don't want to see build output when -v is not given (28+17). 52%
disagree with that.

Among the people preferring to see build output, making -v control the
default seems to be considered an acceptable compromise. So wouldn't
that be great? Hiding build output by default, while still satisfying
most critics of this idea.

> And no, this shouldn't
> warrant having the elections team run a Condorcent vote (which should
> handle issues like this).

I already stated that I would leave the call to zmedico as lead
developer of portage. Giving him the arguments and the data to make the
decision, but watching whether his reasoning is sound. That means
clearly saying where it is based on fact and where it is based on opinion.
(I wouldn't mind if he made an entirely opinion based decision, as long
as he didn't claim it to be fact-based)

Best regards,

(Continue reading)

headers

Rich Freeman | 5 Dec 2011 14:25

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh <at> gentoo.org>:
> Among the people preferring to see build output, making -v control the
> default seems to be considered an acceptable compromise. So wouldn't
> that be great? Hiding build output by default, while still satisfying
> most critics of this idea.

I don't care that strongly about the defaults since I can change them
(though I'd like them to be reasonably sane so that people take us
seriously).

However, making -v control the output seems like a problem, unless
there is some way to undo this.  A typical workflow for me is to run
emerge -auDNv world to see what is going to build, and then hitting
enter to accept it.  I want to get the verbose USE info with -a/p, but
I don't really care to see build logs flying across the screen.  So,
overloading a single flag to do both sounds problematic unless you
also allow the quiet flag to override it back.  That seems complicated
to me.

That raises another portage flags issue - the fact that we need so
many options to do "the right thing."  Now, I'll argue the right thing
is subjective so we do need to be able to control it.  However, it
seems like we should be able to agree on the best setting for
general-purpose updates is, and make that a single setting.

As far as opinions vs facts go - in software design the only real
facts are whether a particular design satisfies or does not satisfy a
particular requirements specification, or dry measures like
benchmarks/scalability/etc.  Whether a particular design is "better"
is always a matter of opinion, unless better simply means satisfying

(Continue reading)

headers

Roy Bamford | 5 Dec 2011 19:23

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On 2011.12.05 13:25, Rich Freeman wrote:
> 2011/12/4 Chí-Thanh Christopher Nguyễn <chithanh <at> gentoo.org>:
> > Among the people preferring to see build output, making -v control
> the
> > default seems to be considered an acceptable compromise. So 
> wouldn't
> > that be great? Hiding build output by default, while still
> satisfying
> > most critics of this idea.
> 
> I don't care that strongly about the defaults since I can change them
> (though I'd like them to be reasonably sane so that people take us
> seriously).
> 
> However, making -v control the output seems like a problem, unless
> there is some way to undo this.  A typical workflow for me is to run
> emerge -auDNv world to see what is going to build, and then hitting
> enter to accept it.  I want to get the verbose USE info with -a/p, 
> but
> I don't really care to see build logs flying across the screen.  So,
> overloading a single flag to do both sounds problematic unless you
> also allow the quiet flag to override it back.  That seems 
> complicated
> to me.
> 
> That raises another portage flags issue - the fact that we need so
> many options to do "the right thing."  Now, I'll argue the right 
> thing
> is subjective so we do need to be able to control it.  However, it
> seems like we should be able to agree on the best setting for

(Continue reading)

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 23:13

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Rich Freeman schrieb:
> However, making -v control the output seems like a problem, unless
> there is some way to undo this.  A typical workflow for me is to run
> emerge -auDNv world to see what is going to build, and then hitting
> enter to accept it.  I want to get the verbose USE info with -a/p, but
> I don't really care to see build logs flying across the screen.  So,
> overloading a single flag to do both sounds problematic unless you
> also allow the quiet flag to override it back.  That seems complicated
> to me.

In the compromise proposal, -v would only set the default for
--quiet-build, not override it.

But overloading -v is indeed an issue that has already be mentioned by
zmedico. What do you think of the following proposal:
--verbose-build[=n]
--verbose-install[=n]
--verbose-use[=n]
--verbose-downloadsize[=n]
...
with -v setting the default to y for them all, but still allowing to
override a particular verbose output with its specific option.

Best regards,
Chí-Thanh Christopher Nguyễn

headers

Mike Frysinger | 5 Dec 2011 04:34

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On Sunday 04 December 2011 22:07:54 Chí-Thanh Christopher Nguyễn wrote:
> Rich Freeman schrieb:
> > That is probably why the forum post is at 52-48 - it really isn't that
> > obvious a call one way or the other.  In any case, it doesn't affect
> > me anyway since I use parallel build and I trust the Council to at
> > least provide some kind of closure...
> 
> I don't know which forum post you are referring to, but in the linked
> forums.g.o poll[1] the old vs. the new default is currently at 52-28
> with the rest opting for the compromise or something else.

can't really say "currently" as the poll is closed ;)
-mike

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 04:55

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

Mike Frysinger schrieb:
>> I don't know which forum post you are referring to, but in the linked
>> forums.g.o poll[1] the old vs. the new default is currently at 52-28
>> with the rest opting for the compromise or something else.
> 
> can't really say "currently" as the poll is closed ;)

The poll is not closed, you have to be logged in to vote.

Best regards,
Chí-Thanh Christopher Nguyễn

headers

Mike Frysinger | 5 Dec 2011 07:32

Re: Call for agenda items -- Council meeting 2011-12-13

On Sunday 04 December 2011 22:55:55 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> >> I don't know which forum post you are referring to, but in the linked
> >> forums.g.o poll[1] the old vs. the new default is currently at 52-28
> >> with the rest opting for the compromise or something else.
> > 
> > can't really say "currently" as the poll is closed ;)
> 
> The poll is not closed, you have to be logged in to vote.

i did login ... but i was viewing a cached page afterwards.  thx.
-mike

headers

Patrick Lauer | 5 Dec 2011 04:42

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On 12/05/11 10:49, Rich Freeman wrote:
> On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer<patrick <at> gentoo.org>  wrote:
>> And spend much more time trying to find them silly logfiles now that we hide
>> the output. I really enjoy having to fix yet another bad default everywhere
>> just so I see *why* things fail ...
> Unless something has changed the logfile name including full path is
> printed when there is an error.  So, it is just a matter of copy/paste
> into a cat and you can watch the whole thing scroll by and even
> pretend it is compiling really fast while it is doing it.  :)
So one useless step added, which might give extra funny output because 
of escaped escape sequences and such funnies, with no benefit for me
>
> It seems like a pretty sane default to assume that most packaged build
> without issues - after all, that is basically the goal, right?
And for those I don't care about the output at all, but when things fail 
I want to see it.
So for me the proper default is "show everything, let me ignore what I 
don't want"

(Plus there are funny cases with clock skew putting builds into a loop 
that are obvious when you see the output, but impossible to catch with 
supressed output. Yey riddles!)
>
> That is probably why the forum post is at 52-48 - it really isn't that
> obvious a call one way or the other.  In any case, it doesn't affect
> me anyway since I use parallel build and I trust the Council to at
> least provide some kind of closure...
>
> Rich
>

(Continue reading)

headers

Mike Frysinger | 5 Dec 2011 04:52

Re: Call for agenda items -- Council meeting 2011-12-13

On Sunday 04 December 2011 22:42:46 Patrick Lauer wrote:
> On 12/05/11 10:49, Rich Freeman wrote:
> > On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer wrote:
> >> And spend much more time trying to find them silly logfiles now that we
> >> hide the output. I really enjoy having to fix yet another bad default
> >> everywhere just so I see *why* things fail ...
> > 
> > Unless something has changed the logfile name including full path is
> > printed when there is an error.  So, it is just a matter of copy/paste
> > into a cat and you can watch the whole thing scroll by and even
> > pretend it is compiling really fast while it is doing it.  :)
> 
> So one useless step added, which might give extra funny output because
> of escaped escape sequences and such funnies, with no benefit for me

uhh, no.  cat on the log files works perfectly fine in any sane terminal.

> > It seems like a pretty sane default to assume that most packaged build
> > without issues - after all, that is basically the goal, right?
> 
> And for those I don't care about the output at all, but when things fail
> I want to see it.

it's hard to have a conversation when you don't even verify your statements.  
when a build fails, it outputs the entire log.  thus your statement here makes 
no sense at all.

> So for me the proper default is "show everything, let me ignore what I
> don't want"

(Continue reading)

headers

Patrick Lauer | 5 Dec 2011 05:17

Re: Call for agenda items -- Council meeting 2011-12-13

On 12/05/11 11:52, Mike Frysinger wrote:
> On Sunday 04 December 2011 22:42:46 Patrick Lauer wrote:
>> On 12/05/11 10:49, Rich Freeman wrote:
>>> On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer wrote:
>>>> And spend much more time trying to find them silly logfiles now that we
>>>> hide the output. I really enjoy having to fix yet another bad default
>>>> everywhere just so I see *why* things fail ...
>>> Unless something has changed the logfile name including full path is
>>> printed when there is an error.  So, it is just a matter of copy/paste
>>> into a cat and you can watch the whole thing scroll by and even
>>> pretend it is compiling really fast while it is doing it.  :)
>> So one useless step added, which might give extra funny output because
>> of escaped escape sequences and such funnies, with no benefit for me
> uhh, no.  cat on the log files works perfectly fine in any sane terminal.
Unless the build system became extra happy ...
>
>>> It seems like a pretty sane default to assume that most packaged build
>>> without issues - after all, that is basically the goal, right?
>> And for those I don't care about the output at all, but when things fail
>> I want to see it.
> it's hard to have a conversation when you don't even verify your statements.
> when a build fails, it outputs the entire log.  thus your statement here makes
> no sense at all.
Not all failures are errors, only errors are shown

So I'm still left wondering why things didn't go as planned, but at that 
point the log has already been removed and I have to rebuild things 
after remembering to change defaults ... not that this happened to me or 
anything like that, just that it has happened to me twice now and I'm 
getting tired of spending time on changing defaults that should be sane.

(Continue reading)

headers

Mike Frysinger | 5 Dec 2011 07:48

Re: Call for agenda items -- Council meeting 2011-12-13

On Sunday 04 December 2011 23:17:55 Patrick Lauer wrote:
> On 12/05/11 11:52, Mike Frysinger wrote:
> > On Sunday 04 December 2011 22:42:46 Patrick Lauer wrote:
> >> On 12/05/11 10:49, Rich Freeman wrote:
> >>> On Sun, Dec 4, 2011 at 9:18 PM, Patrick Lauer wrote:
> >>>> And spend much more time trying to find them silly logfiles now that
> >>>> we hide the output. I really enjoy having to fix yet another bad
> >>>> default everywhere just so I see *why* things fail ...
> >>> 
> >>> Unless something has changed the logfile name including full path is
> >>> printed when there is an error.  So, it is just a matter of copy/paste
> >>> into a cat and you can watch the whole thing scroll by and even
> >>> pretend it is compiling really fast while it is doing it.  :)
> >> 
> >> So one useless step added, which might give extra funny output because
> >> of escaped escape sequences and such funnies, with no benefit for me
> > 
> > uhh, no.  cat on the log files works perfectly fine in any sane terminal.
> 
> Unless the build system became extra happy ...

i have no idea wtf you're talking about.  i'm just going to go with "you have 
no real examples".

> >>> It seems like a pretty sane default to assume that most packaged build
> >>> without issues - after all, that is basically the goal, right?
> >> 
> >> And for those I don't care about the output at all, but when things fail
> >> I want to see it.
> >

(Continue reading)

headers

Zac Medico | 5 Dec 2011 07:48

Re: Call for agenda items -- Council meeting 2011-12-13

On 12/04/2011 10:48 PM, Mike Frysinger wrote:
> all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc on 
> missing file) will get "missed".  many of those are logged as QA warnings, but 
> it seems default --quiet-build=y will not include these in the log summary.  
> this might be useful to fix -- i'll poke Zac about it if he doesn't see this e-
> mail.

This is due to the default PORTAGE_ELOG_CLASSES="log warn error" in
make.globals. The developer profile sets
:PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", so anyone running
that profile gets the QA warnings automatically.

Maybe it would be fine to enable the QA warnings by default for all
users. I don't feel strongly either way.
--

-- 
Thanks,
Zac

headers

Mike Frysinger | 5 Dec 2011 17:07

Re: Call for agenda items -- Council meeting 2011-12-13

On Monday 05 December 2011 01:48:34 Zac Medico wrote:
> On 12/04/2011 10:48 PM, Mike Frysinger wrote:
> > all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc
> > on missing file) will get "missed".  many of those are logged as QA
> > warnings, but it seems default --quiet-build=y will not include these in
> > the log summary. this might be useful to fix -- i'll poke Zac about it
> > if he doesn't see this e- mail.
> 
> This is due to the default PORTAGE_ELOG_CLASSES="log warn error" in
> make.globals. The developer profile sets
> 
> :PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", so anyone running
> 
> that profile gets the QA warnings automatically.
> 
> Maybe it would be fine to enable the QA warnings by default for all
> users. I don't feel strongly either way.

hrm.  there's some QA messages i think we should have all our users see by 
default (so they'll report bugs), and there's some i think should be in the 
developer profiles.  although, i think most are in the former category, so 
maybe we shouldn't sweat it for now ?

specifically, i'm thinking of the build type warnings that we label as upstream 
should be shown to devs and not users ...
-mike

headers

Zac Medico | 5 Dec 2011 18:06

Re: Call for agenda items -- Council meeting 2011-12-13

On 12/05/2011 08:07 AM, Mike Frysinger wrote:
> On Monday 05 December 2011 01:48:34 Zac Medico wrote:
>> On 12/04/2011 10:48 PM, Mike Frysinger wrote:
>>> all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc
>>> on missing file) will get "missed".  many of those are logged as QA
>>> warnings, but it seems default --quiet-build=y will not include these in
>>> the log summary. this might be useful to fix -- i'll poke Zac about it
>>> if he doesn't see this e- mail.
>>
>> This is due to the default PORTAGE_ELOG_CLASSES="log warn error" in
>> make.globals. The developer profile sets
>>
>> :PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", so anyone running
>>
>> that profile gets the QA warnings automatically.
>>
>> Maybe it would be fine to enable the QA warnings by default for all
>> users. I don't feel strongly either way.
> 
> hrm.  there's some QA messages i think we should have all our users see by 
> default (so they'll report bugs), and there's some i think should be in the 
> developer profiles.  although, i think most are in the former category, so 
> maybe we shouldn't sweat it for now ?

Yeah, I don't think it's a major problem. Developers should be setting
PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa" manually if they don't
use the developer profile.

> specifically, i'm thinking of the build type warnings that we label as upstream 
> should be shown to devs and not users ...

(Continue reading)

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 23:13

Re: Call for agenda items -- Council meeting 2011-12-13

Mike Frysinger schrieb:
>> Not all failures are errors, only errors are shown
> 
> all failures as characterized by "ebuild called `die`" get shown -- portage 
> dumps the entire log, thus your need to copy & paste the log file to `cat` is 
> garbage.
> 
> all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc on 
> missing file) will get "missed".  many of those are logged as QA warnings, but 
> it seems default --quiet-build=y will not include these in the log summary.  
> this might be useful to fix -- i'll poke Zac about it if he doesn't see this e-
> mail.
> 
> otherwise, your statement is really way too zen to get anything meaningful out 
> of it.  post actual examples of what you're talking about.

Attached you will find a build.log of trying to build cdrtools on
sparc-solaris prefix. Admittedly a bit exotic, but far from unique incident.

A moderately knowledgeable user would notice that something is wrong
from watching the build output for a couple of seconds. Portage however
proceeds happily because make returns exit status 0.

Best regards,
Chí-Thanh Christopher Nguyễn

Attachment (build.log.gz): application/x-gzip, 99 KiB

headers

Mike Frysinger | 5 Dec 2011 23:46

Re: Call for agenda items -- Council meeting 2011-12-13

On Monday 05 December 2011 17:13:26 Chí-Thanh Christopher Nguyễn wrote:
> Mike Frysinger schrieb:
> >> Not all failures are errors, only errors are shown
> > 
> > all failures as characterized by "ebuild called `die`" get shown --
> > portage dumps the entire log, thus your need to copy & paste the log
> > file to `cat` is garbage.
> > 
> > all "failures" that don't result in an aborted build (e.g. EAPI=0 dodoc
> > on missing file) will get "missed".  many of those are logged as QA
> > warnings, but it seems default --quiet-build=y will not include these in
> > the log summary. this might be useful to fix -- i'll poke Zac about it
> > if he doesn't see this e- mail.
> > 
> > otherwise, your statement is really way too zen to get anything
> > meaningful out of it.  post actual examples of what you're talking
> > about.
> 
> Attached you will find a build.log of trying to build cdrtools on
> sparc-solaris prefix. Admittedly a bit exotic, but far from unique
> incident.
> 
> A moderately knowledgeable user would notice that something is wrong
> from watching the build output for a couple of seconds. Portage however
> proceeds happily because make returns exit status 0.

portage would always proceed.  the only thing that would stop it is the user 
hitting CTRL+C.  and that requires the user actually be watching the build 
output.  perhaps they would be for a single package, but for general upgrades, 
i doubt you can rely on that.  what would be more likely is they try to run

(Continue reading)

headers

Chí-Thanh Christopher Nguyễn | 5 Dec 2011 23:55

Re: Call for agenda items -- Council meeting 2011-12-13

Mike Frysinger schrieb:
>> A moderately knowledgeable user would notice that something is wrong
>> from watching the build output for a couple of seconds. Portage however
>> proceeds happily because make returns exit status 0.
> 
> portage would always proceed.  the only thing that would stop it is the user 
> hitting CTRL+C.  and that requires the user actually be watching the build 
> output.  perhaps they would be for a single package, but for general upgrades, 
> i doubt you can rely on that.  what would be more likely is they try to run 
> `cdrecord`, find it missing, find the build failed, and then file a bug.  that 
> workflow really isn't affected by the defaults here.
> -mike

In versions prior to cdrecord-3.00 it was actually the case that nothing
at all was installed. That would cause patrick to notice and scroll back
up in his terminal buffer now to see wtf went wrong.

Since 3.00 it installs a cdrecord binary that runs but doesn't actually
talk to hardware. Fun.

Best regards,
Chí-Thanh Christopher Nguyen

headers

Chí-Thanh Christopher Nguyễn | 6 Dec 2011 00:04

Re: Call for agenda items -- Council meeting 2011-12-13

Chí-Thanh Christopher Nguyễn schrieb:
> Mike Frysinger schrieb:
>> what would be more likely is they try to run 
>> `cdrecord`, find it missing, find the build failed, and then file a bug.  that 
>> workflow really isn't affected by the defaults here.
>> -mike
> 
> In versions prior to cdrecord-3.00 it was actually the case that nothing
> at all was installed. That would cause patrick to notice and scroll back
> up in his terminal buffer now to see wtf went wrong.
> 
> Since 3.00 it installs a cdrecord binary that runs but doesn't actually
> talk to hardware. Fun.

Oh nevermind, I noticed it doesn't install cdrecord after all, and
prefix uses system-installed one.

Best regards,
Chí-Thanh Christopher Nguyễn

headers

Zac Medico | 4 Dec 2011 19:13

Re: Re: [gentoo-dev-announce] Call for agenda items -- Council meeting 2011-12-13

On Sun, Dec 4, 2011 at 6:17 AM, Thomas Sachau <tommy <at> gentoo.org> wrote:
> 2. Should the default output of portage be changed to quiet?
>
> If yes, is a simple portage message for 2.1.* users enough to inform
> users about this highly visible change? Especially in the context in
> mind, that a good amount of packages have elog messages, so it is pretty
> easy to miss this hint for a change in portage behaviour.

I'm already planning to send out a GLEP 42 news item for this before it
goes to stable. It will include a description of --quiet-build behavior
(including automatic display of build output when a build fails), how to
use EMERGE_DEFAULT_OPTS to customize the local default, and how the
default PORTAGE_ELOG_SYSTEM/PORTAGE_ELOG_CLASSES settings ensure that
elog messages are displayed regardless of the --quiet-build setting.
--

-- 
Thanks,
Zac