Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Petteri Räty
 On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
 
Currently there are quite a few ebuilds in the tree that execute dodoc
or dohtml for files that do not exist. I think it would be nice to have
ebuilds die if this is the case. To not break current ebuilds this would
only happen with FEATURES=stricter. This is what I currently do in my
bashrc. Obviously when integreted to portage one can use helper
functions like hasq which are not available in bashrc.



Well some people opposed this idea so what do everyone think about
making portage output stuff like this to a qa-warnings (or whatever)
file that developers can use? This would have the added benefit that
users would not normally see this stuff and report stuff so easily but
developers would still have easy access to it. Portage could even output
a header to this file saying not to file bug reports unless you know
what you are doing?

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Mike Frysinger
On Tuesday 27 December 2005 14:41, Petteri Räty wrote:
  On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
 Currently there are quite a few ebuilds in the tree that execute dodoc
 or dohtml for files that do not exist. I think it would be nice to have
 ebuilds die if this is the case. To not break current ebuilds this would
 only happen with FEATURES=stricter. This is what I currently do in my
 bashrc. Obviously when integreted to portage one can use helper
 functions like hasq which are not available in bashrc.

 Well some people opposed this idea so what do everyone think about
 making portage output stuff like this to a qa-warnings (or whatever)
 file that developers can use? This would have the added benefit that
 users would not normally see this stuff and report stuff so easily but
 developers would still have easy access to it. Portage could even output
 a header to this file saying not to file bug reports unless you know
 what you are doing?

if we start hiding the output like that then most people will ignore them
-mike

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Lares Moreau
On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote:
  On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:
  
 Currently there are quite a few ebuilds in the tree that execute dodoc
 or dohtml for files that do not exist. I think it would be nice to have
 ebuilds die if this is the case. To not break current ebuilds this would
 only happen with FEATURES=stricter. This is what I currently do in my
 bashrc. Obviously when integreted to portage one can use helper
 functions like hasq which are not available in bashrc.
 
 
 
 Well some people opposed this idea so what do everyone think about
 making portage output stuff like this to a qa-warnings (or whatever)
 file that developers can use? This would have the added benefit that
 users would not normally see this stuff and report stuff so easily but
 developers would still have easy access to it. Portage could even output
 a header to this file saying not to file bug reports unless you know
 what you are doing?

I see the point about not showing all the QA stuff to the 'regluar'
user.  Maybe only show this info on screen with --verbose set. As for
the QA-warnings file, how does this differ from parsing the files in
PORTLOG_DIR?

Later Days,
-Lares

-- 
Lares Moreau [EMAIL PROTECTED]  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net |
Gentoo x86 Arch Tester |   ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |  Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Petteri Räty


Lares Moreau wrote:
 On Tue, 2005-12-27 at 21:41 +0200, Petteri Räty wrote:
 
On Mon, Dec 26, 2005 at 12:54:04AM +0200, Petteri Räty wrote:


Currently there are quite a few ebuilds in the tree that execute dodoc
or dohtml for files that do not exist. I think it would be nice to have
ebuilds die if this is the case. To not break current ebuilds this would
only happen with FEATURES=stricter. This is what I currently do in my
bashrc. Obviously when integreted to portage one can use helper
functions like hasq which are not available in bashrc.



Well some people opposed this idea so what do everyone think about
making portage output stuff like this to a qa-warnings (or whatever)
file that developers can use? This would have the added benefit that
users would not normally see this stuff and report stuff so easily but
developers would still have easy access to it. Portage could even output
a header to this file saying not to file bug reports unless you know
what you are doing?
 
 
 I see the point about not showing all the QA stuff to the 'regluar'
 user.  Maybe only show this info on screen with --verbose set. As for
 the QA-warnings file, how does this differ from parsing the files in
 PORTLOG_DIR?
 

Stuff that goes to PORT_LOGDIR is also shown to the user.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Lares Moreau
On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote:
  I see the point about not showing all the QA stuff to the 'regluar'
  user.  Maybe only show this info on screen with --verbose set. As for
  the QA-warnings file, how does this differ from parsing the files in
  PORTLOG_DIR?
  
 
 Stuff that goes to PORT_LOGDIR is also shown to the user.

Could it be split? Have the QA stuff shown on screen only when --verbose
is set, but have all the information written to PORT_LOGDIR no matter
the flag.

In my experience most users don't use PORT_LOGDIR in the first place.
People who want the information define PORT_LOGDIR and have the
information. Why add files containing duplicate information?

-Lares

-- 
Lares Moreau [EMAIL PROTECTED]  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net |
Gentoo x86 Arch Tester |   ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |  Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Kalin KOZHUHAROV
Lares Moreau wrote:
 On Tue, 2005-12-27 at 22:10 +0200, Petteri Räty wrote:
 
I see the point about not showing all the QA stuff to the 'regluar'
user.  Maybe only show this info on screen with --verbose set. As for
the QA-warnings file, how does this differ from parsing the files in
PORTLOG_DIR?


Stuff that goes to PORT_LOGDIR is also shown to the user.
 
 
 Could it be split? Have the QA stuff shown on screen only when --verbose
 is set, but have all the information written to PORT_LOGDIR no matter
 the flag.

That will be difficult to explain as a behaviour, not logical to me.


 In my experience most users don't use PORT_LOGDIR in the first place.
 People who want the information define PORT_LOGDIR and have the
 information. Why add files containing duplicate information?

ditto.

Imagine a world where every (Gentoo) user is a developer... dream... more!
You are right - impossible. However, by bitching about problems, there are some 
users that decide to
check WTF is this warning, in turn they urge devs to fix it (and that is the 
main point of QA,
right?), they report it with their bug reports and so on. In other words, the 
problem gets _NOTICED_
by everybody.

IMHO, leave it as it is now and don't bother. It is not that much of an output, 
compared to the
compile output anyway.

I'd prefer even having it red/bold/whatever for easy spotting. And for the 
future, what about
defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru 
in make.conf? And
act acording to this, but trying to move the user up a level or two most of the 
time.

Kalin.
/know_how -master --dev/

-- 
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Lares Moreau
On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote:
  what about
 defining something like 
 GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in make.conf? And
 act acording to this, but trying to move the user up a level or two most of 
 the time.

This is what happens anyway, but it is called FEATURES :)

-Lares

-- 
Lares Moreau [EMAIL PROTECTED]  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net |
Gentoo x86 Arch Tester |   ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |  Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Kalin KOZHUHAROV
Lares Moreau wrote:
 On Wed, 2005-12-28 at 10:34 +0900, Kalin KOZHUHAROV wrote:
 
 what about defining something like 
 GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru in
 make.conf? And act acording to this, but trying to move the user up a level 
 or two most of the
 time.
 
 
 This is what happens anyway, but it is called FEATURES :)

From `man make.conf`
   FEATURES = sandbox ccache autoaddcvs
  Defines actions portage takes by default.  These options should 
not be changed by
anyone but developers and/or maintainers.  'sandbox' is an  important  part  of 
FEATURES and should
not be disabled by default.  This is an incremental variable.

So I guess I am close to developers and/or maintainers as I change that on 
day 0 on any Gentoo box
I install :-)

s/'sandbox' is an  important  part  of FEATURES and should not be disabled by 
default/
'sandbox' is an  important  part  of FEATURES and should not be disabled by 
default (but disabled on
`emerge perl`)/g or die;

I still think, GENTOO_LEVEL is a better one though.

Kalin.

-- 
|[ ~~ ]|
+- http://ThinRope.net/ -+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list



Re: [gentoo-dev] Putting qa warnings to a text file instead of showing them to the world

2005-12-27 Thread Ryan Tandy

snip


However, by bitching about problems, there are some users that decide to
check WTF is this warning, in turn they urge devs to fix it (and that is the 
main point of QA,
right?), they report it with their bug reports and so on. In other words, the 
problem gets _NOTICED_
by everybody.

IMHO, leave it as it is now and don't bother. It is not that much of an output, 
compared to the
compile output anyway.
I'd prefer even having it red/bold/whatever for easy spotting. 

I agree - hiding QA stuff just makes it be there longer.  The more 
people notice it, the more likely it is to get fixed, which is the best 
way of making it not show up (IMHO anyway).



And for the future, what about
defining something like GENTOO_LEVEL=n00b|user|know_how|master|admin|dev|guru 
in make.conf? And
act acording to this, but trying to move the user up a level or two most of the 
time.

I don't think many people would enjoy having a system that made it its 
business to tell them what they should know about.  Different people 
have different learning rates and learn in different ways about 
different things.  People who want to learn to solve their own problems 
will; those who don't aren't likely to want their computer to try to 
force them to (although I'll admit that Gentoo doesn't exactly attract 
loads of the latter type).

--
gentoo-dev@gentoo.org mailing list