Re: [gentoo-dev] New Bugzilla HOWTO

Re: [gentoo-dev] New Bugzilla HOWTO

[Simon Stelling]

Hi,

Chris White wrote:

> <jforman>
> EBUILD BUGS GO IN GENTOO LINUX PRODUCT
> STOP MARKING EVERY BUG AS A BLOCKER
> </jforman>

What about changing the description for the severity field rather than
jelling at users? Honestly, if a bug prevents you from using your
favourite app, wouldn't you select

"Blocker: This bug prevents a software application from testing and use."?

Or what about "Critical: The software crashes, hangs, or causes you to
lose data."?

Perhaps I should file a blocker bug about this ;)

Regards,

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: New Bugzilla HOWTO

[Duncan]

Simon Stelling posted <42CD7920.7060305@gentoo.org>, excerpted below,  on
Thu, 07 Jul 2005 20:49:04 +0200:

> Hi,
> 
> Chris White wrote:
> 
>> <jforman>
>> EBUILD BUGS GO IN GENTOO LINUX PRODUCT STOP MARKING EVERY BUG AS A
>> BLOCKER
>> </jforman>
> 
> What about changing the description for the severity field rather than
> jelling at users? Honestly, if a bug prevents you from using your
> favourite app, wouldn't you select
> 
> "Blocker: This bug prevents a software application from testing and use."?
> 
> Or what about "Critical: The software crashes, hangs, or causes you to
> lose data."?
> 
> Perhaps I should file a blocker bug about this ;)

Well, not blocker <g>, but ...
http://bugs.gentoo.org/show_bug.cgi?id=73181

As mentioned there, this isn't the first time the inappropriate severity
descriptions issue has been pointed out on this list.  Can anyone blame
folks for using the severity descriptions as a guide?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Bugzilla HOWTO

[Robin H. Johnson]

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

On Fri, Jul 08, 2005 at 11:08:20AM +0900, Chris White wrote:
> After seeing the strange and unusual postings that we get sometimes in
> bugzilla.. We've had it!
Some comments after reading it.

Flags:
------
Please provide an example of CFLAGS/CXXFLAGS for users, possibly in the
code listing of 'Re-emergeing a package with debugging'.

FEATURES="nostrip" CFLAGS="-O2 -pipe -ggdb3" CXXFLAGS="-O2 -pipe -ggdb3" emerge package

-ggdb3 is more useful that just plain -g (-g expands to -ggdb1 on most
arches), as it includes #define stuff and some C++ things that can
be very hard to decipher with just plain -g.

Core dumps:
-----------
Also, please point out the value of setting the core-dump ulimit to a
reasonable size, and backtracing a core-dump instead of the application
directly. This is esp. applicable for things like mod_php where you
can't really run the binary directly under gdb.

Just basically set the core-dump ulimit (either commandline or via the
ulimit configurations), and then run the application, and afterwards do:
gdb ./bad_core COREFILE

Emerge errors:
--------------
Some builds, esp. PHP include a message in the final emerge message
(prefixed with !!) telling you to include a specific file (config.log
most often) with your bug report. Please mention this, and remind users
it is important!

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

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

Re: [gentoo-dev] Re: New Bugzilla HOWTO

[Gregorio Guidi]

On Thursday 07 July 2005 22:15, Duncan wrote:
> Simon Stelling posted <42CD7920.7060305@gentoo.org>, excerpted below,  on
>
> Thu, 07 Jul 2005 20:49:04 +0200:
> > Hi,
> >
> > Chris White wrote:
> >> <jforman>
> >> EBUILD BUGS GO IN GENTOO LINUX PRODUCT STOP MARKING EVERY BUG AS A
> >> BLOCKER
> >> </jforman>
> >
> > What about changing the description for the severity field rather than
> > jelling at users? Honestly, if a bug prevents you from using your
> > favourite app, wouldn't you select
> >
> > "Blocker: This bug prevents a software application from testing and
> > use."?
> >
> > Or what about "Critical: The software crashes, hangs, or causes you to
> > lose data."?
> >
> > Perhaps I should file a blocker bug about this ;)
>
> Well, not blocker <g>, but ...
> http://bugs.gentoo.org/show_bug.cgi?id=73181

I must add:
http://bugs.gentoo.org/show_bug.cgi?id=92492

Also, it would be easier for user to avoid selecting Bugzilla as product if 
the form was a bit friendlier, something like this...
http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-report.html
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New Bugzilla HOWTO

[Chris White]

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

After seeing the strange and unusual postings that we get sometimes in bugzilla.. We've had it!

please consult here:

http://www.gentoo.org/doc/en/bugzilla-howto.xml

Going to this page now ensures that hitman are not sent to your home right away.  However, if you read this doc and still messup, we'll send DOUBLE the hitmen to you location.  And now, a friendly word from our local infra:

<jforman>
EBUILD BUGS GO IN GENTOO LINUX PRODUCT
STOP MARKING EVERY BUG AS A BLOCKER
</jforman>

also, we've setup a crack team of hackers to remove your account transparently on top of the hitmen.  It's like you NEVER EXISTED!

kthxbye
Chris White

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

[gentoo-dev] Re: Re: New Bugzilla HOWTO

[Duncan]

Gregorio Guidi posted <200507072305.54276.greg_g@gentoo.org>, excerpted
below,  on Thu, 07 Jul 2005 23:05:53 +0200:

> On Thursday 07 July 2005 22:15, Duncan wrote:
>> Simon Stelling posted <42CD7920.7060305@gentoo.org>, excerpted below,  on
>>
>> Thu, 07 Jul 2005 20:49:04 +0200:
>> >
>> > What about changing the description for the severity field rather than
>> > jelling at users? Honestly, if a bug prevents you from using your
>> > favourite app, wouldn't you select
>> >
>> > "Blocker: This bug prevents a software application from testing and
>> > use."?
>> >
>> > Or what about "Critical: The software crashes, hangs, or causes you to
>> > lose data."?
>> >
>> > Perhaps I should file a blocker bug about this ;)
>>
>> Well, not blocker <g>, but ...
>> http://bugs.gentoo.org/show_bug.cgi?id=73181
> 
> I must add:
> http://bugs.gentoo.org/show_bug.cgi?id=92492
> 
> Also, it would be easier for user to avoid selecting Bugzilla as product if 
> the form was a bit friendlier, something like this...
> http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-report.html

I /like/ the new product selector page!  MUCH, MUCH easier to use!  The
only nag I have on it now is the note at the top:
 
GENTOO LINUX IS WHERE YOU PUT EBUILD BUGS.

To a me as a new bugzilla user, that would cause me to think I somehow got
the wrong page, and I needed to find another one to file the Gentoo Linux
bugs.  What about this:

Use the GENTOO LINUX section, below, to file EBUILD BUGS.

Or:

The GENTOO LINUX section, below, is where EBUILD BUGS go.

Or:

File EBUILD BUGS in the GENTOO LINUX section, below.

Hmm... I think that last one sounds best to me.  In all three cases,
however, it's apparent that the GENTOO LINUX choice is below, so the user
doesn't get confused and think he's on the wrong page.

Other than that, as I said, I LIKE it!  The HUGE TYPED description for the
Gentoo Linux section is /perfect/.  Likewise with the pointers in the
other sections to it  Altho I suppose /some/ might argue it's a bit
overdone, now, and I could see their point, that's NOT an argument I'm
willing to make, as I /do/ see their point, I just don't agree.  <g>

The only other consideration is how it looks in links/lynx.  Text size
won't show up there.

I just loaded it in lynx, and the BOLD stuff shows up in red, so it's
noticed.  That means the "Bugs related to ebuilds belong in 'Gentoo
Linux'" things are in red, and look the same as the "If you're unsure
where your bugs go, then file them here." note.  I'd suggest BOLDing the
entire description, and putting a *** in front of it, which will make it
stand off from the others in lynx.

Links puts bold in brite-white, not color.  Again, it does stand out, but
there's nothing making the Gentoo Linux selection particularly stand out. 
Again, the *** in front and/or bolding the entire description for that one
would probably do it.

....

On the severity thing...  Note that both links and lynx show only the
single-word severity, not the description that goes with it.  For that,
one follows the link to the general descriptions (A Bug's Live Cycle) page.

BTW, note that the life cycle severity descriptions are about as
short as, but do not match, the descriptive labels shown in graphical
browsers.  I'd suggest they either match, or a longer description be used
on the life cycle page.

Also note that the "blocker" label-description  

"This bug prevents a software application from testing and use." 

doesn't seem to me to be proper English.  I'm not an English major or
professor, so I'm not going to describe what's wrong, but it just doesn't
sound quite right to me. Perhaps 

"This bug prevents a software application from /being/ tested our used."

Or:

"This bug prevents testing and use of the software application."

However, if the intent is for "blocker" to apply to the entire product
(Gentoo Linux in this case), not just the application/ebuild in question,
then as both bugs suggest, something about the system left unusable or
unbootable might be better than current wording in either location (the
label descriptions and the life cycle page).  OTOH, if the intent is for
"blocker" to apply to that individual package, then current wording is
usable, but /will/ result in more "blocker" bugs being filed, because if
it can't be emerged, it's certainly blocking that package, particularly if
there's no indication it's a special case.  IOW, I believe the confusion
here is on what the labels apply to, the entire distribution, or the
individual package.  If that can be cleared up in as effective a way as
was done with the product selector page, it'll go a /long/ way toward
straightening out the confusion surrounding Gentoo bugzilla in the present
and past.

I'm VERY glad this is being worked on, tho.  It's certainly needed it for
awhile, and while I've always fought a bit with any Bugzilla I've had to
use, Gentoo's was DEFINITELY the worst in terms of usability, I've EVER
come across, when I started.  If the product selector changes are anything
to go by, however, that situation is finally changing for the better, so
keep up the good work!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> 
> Well, not blocker <g>, but ...
> http://bugs.gentoo.org/show_bug.cgi?id=73181
> 

This brings up a point that really irks me. In the bug, I believe the
dev implies that the reported bug has merit /yet he closes the bug
before actually doing something about it/. And I don't mean to pick on
Jeffrey; this seems to be a common habit among Gentoo devs.

If a bug is opened and it is a valid bug, the bug should not be closed
until it is actually squashed and the product ships (of course, if its a
valid bug that just won't get fixed for some reason, you can always mark
it WONTFIX):

http://bugs.gentoo.org/page.cgi?id=fields.html#status

I won't even go into the fact that the VERIFIED state* does not seemed
to be used or the fact that the person ASSIGNED to the bug is allowed to
close [his|her] own bugs! ;)

Nathan

* This would seem to be a perfect job for Team Leads, but it would need
to be enforced by Bugzilla, and the ASSIGNED engineer must not be the
same person as the VERIFIED(er) engineer for a particular bug.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzmaf2QTTR4CNEQARArnwAKCSvsTZJuOGEswyResK3mNoTWlmFgCfbp2s
T0h/txCaKzqjGrCdbW1pOqg=
=U+ib
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New Bugzilla HOWTO

[Gregorio Guidi]

On Thursday 07 July 2005 23:05, Gregorio Guidi wrote:
> Also, it would be easier for user to avoid selecting Bugzilla as product if
> the form was a bit friendlier, something like this...
> http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-report.html

Mmm... it should have been 
http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-main.html
sorry.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: New Bugzilla HOWTO

[Henrik Brix Andersen]

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

On Fri, 2005-07-08 at 14:49 +0200, Gregorio Guidi wrote:
> Mmm... it should have been 
> http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-main.html
> sorry.

Looks awesome.

./Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Duncan]

Nathan L. Adams posted <42CE669F.6020502@ieee.org>, excerpted below,  on
Fri, 08 Jul 2005 07:42:23 -0400:

> Duncan wrote:
>> 
>> Well, not blocker <g>, but ...
>> http://bugs.gentoo.org/show_bug.cgi?id=73181
>> 
>> 
> This brings up a point that really irks me. In the bug, I believe the dev
> implies that the reported bug has merit /yet he closes the bug before
> actually doing something about it/. And I don't mean to pick on Jeffrey;
> this seems to be a common habit among Gentoo devs.

OK... as the one that filed the bug...

I agree with how this was handled.  resolved-remind was appropriate.  The
bug had been open for some months (IIRC), and it /was/ a long-term bug, I
knew that when I filed it.  resolved-remind is IMO an appropriate
resolution for that, getting it off the immediate list, acknowledging it
needs investigated further, but indicating "not now".

Also note that the bug is NOT "closed", only /resolved/.  There /is/ a
not insignificant technical difference, altho it /does/ seem Gentoo
doesn't seem to actually close bugs that often.  "Resolved" is technically
(as I understand it) that state at which the resolution is there (or put
off, if status remind), but not yet "shipping".  With conventional
resolutions, that would roughly coincide with resolved-inCVS.  "Closed"
indicates not only that a solution has been found, but that it has been
verified to work, and shipped, which in Gentoo parlance would mean there
has been an official release either incorporating it or since it was put
in the tree.  Perhaps unfortunately, Gentoo QA doesn't always extend to
that degree and it seems resolved==closed for all intents and purposes to
us.  However, given that Gentoo is a community based distribution, that
may be practical reality -- it may not be practical to enforce rigid
"closed" QA standards and definitions on us, if there isn't the necessary
QA resources to actually follow up on all those "resolved" bugs and close
them or re-open them to full-open status, if necessary.

Anyway, I'm basically satisfied with resolved-remind, which is of course
exactly what I did, when the issue came up once again, and there was focus
on it.  

My remaining question, of course, would be whether it's appropriate to
re-open the bug at this point now that it's being worked on, or not. 
Technically, I'd say yes, "remind" at this point is exactly what should be
done. However, socially/practically may be a different matter,
particularly with another bug on the same thing, now. With work on it
already underway, it's possible reopening the bug now would just
complicate things needlessly, and/or even insult the poor dev working on
it, who could interpret the reopening as if I don't like his efforts --
VERY far from the truth, I have been VERY impressed with the work to the
product selection page! Opinions?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: New Bugzilla HOWTO

[Duncan]

Henrik Brix Andersen posted <1120827597.12808.6.camel@sponge.fungus>,
excerpted below,  on Fri, 08 Jul 2005 14:59:57 +0200:

> On Fri, 2005-07-08 at 14:49 +0200, Gregorio Guidi wrote:
>> Mmm... it should have been
>> http://dev.gentoo.org/~greg_g/enter_bug/enter_bug-main.html sorry.
> 
> Looks awesome.

Absolutely!  The current "live" changes are good, but this takes things in
a bit different direction, more toward a multi-page "wizard" guide.  The
wizard approach has quite some usability testing behind it, as long as
there's an "advanced" alternative, for those that have gotten beyond the
single choice on a single page at a time, approach (and there is).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Mike Frysinger]

> > This brings up a point that really irks me. In the bug, I believe the dev
> > implies that the reported bug has merit /yet he closes the bug before
> > actually doing something about it/. And I don't mean to pick on Jeffrey;
> > this seems to be a common habit among Gentoo devs.

that's because we got tired of asking for more info/whatever and never getting 
anything back ... so we close the bug, get it off our 'todo' lists, and wait 
for the user to get back to us (not all do)

this is the biggest reason NEEDINFO was created

> Also note that the bug is NOT "closed", only /resolved/.  There /is/ a
> not insignificant technical difference, altho it /does/ seem Gentoo
> doesn't seem to actually close bugs that often.

thats because very few (if any) think or care about the difference
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Frysinger wrote:
>>>This brings up a point that really irks me. In the bug, I believe the dev
>>>implies that the reported bug has merit /yet he closes the bug before
>>>actually doing something about it/. And I don't mean to pick on Jeffrey;
>>>this seems to be a common habit among Gentoo devs.
> 
> 
> that's because we got tired of asking for more info/whatever and never getting 
> anything back ... so we close the bug, get it off our 'todo' lists, and wait 
> for the user to get back to us (not all do)
> 
> this is the biggest reason NEEDINFO was created

Having the reporter be the verifier is a great idea (probably ideal),
but again, you could assign the verification to the Team Lead. If the
Team Lead can get the user to respond, great, otherwise they could do
the QA themselves.

>>Also note that the bug is NOT "closed", only /resolved/.  There /is/ a
>>not insignificant technical difference, altho it /does/ seem Gentoo
>>doesn't seem to actually close bugs that often.

Ah, my bad. For some reason I thought it had been closed. But I know
that if you looked (not too hard) you could find bugs that were closed
by the person assigned to resolve it and/or that were closed before the
'fix' was marked stable.

> 
> thats because very few (if any) think or care about the difference

You could make bugzilla try to enforce the process; that would get dev's
thinking and caring! Just think: The Great QA Rebellion of 2005 ;)

Anyway, this stuff is important to me 1) because I do systems
integration for a living and deal with this sort of stuff daily 2) good
QA is an 'enterprise characteristic' if you will, and 3) good QA
benefits everyone (although it annoys some developers to no end).

Nathan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz0ij2QTTR4CNEQARAitWAKCXfs0tTNRo3eOPvuZ+VJYUG13GKACgkalh
7eRv7Aj61BNfMnFSN/I76oI=
=N7XG
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Martin Schlemmer]

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

On Fri, 2005-07-08 at 23:46 -0400, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mike Frysinger wrote:
> >>>This brings up a point that really irks me. In the bug, I believe the dev
> >>>implies that the reported bug has merit /yet he closes the bug before
> >>>actually doing something about it/. And I don't mean to pick on Jeffrey;
> >>>this seems to be a common habit among Gentoo devs.

> >>Also note that the bug is NOT "closed", only /resolved/.  There /is/ a
> >>not insignificant technical difference, altho it /does/ seem Gentoo
> >>doesn't seem to actually close bugs that often.
> 
> Ah, my bad. For some reason I thought it had been closed. But I know
> that if you looked (not too hard) you could find bugs that were closed
> by the person assigned to resolve it and/or that were closed before the
> 'fix' was marked stable.
> 
> > 
> > thats because very few (if any) think or care about the difference
> 
> You could make bugzilla try to enforce the process; that would get dev's
> thinking and caring! Just think: The Great QA Rebellion of 2005 ;)
> 

Problem is many of us have sometimes already too many bugs to care about
users reporting something, and then never coming back, not even talking
about keeping to poke the reporter to come back and say the fix works
fine, and close it.  Thus the fix it, test it, resolve the bug as Fixed,
and if the user do not reopen it, your work is done.


-- 
Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


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

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Schlemmer wrote:
> Problem is many of us have sometimes already too many bugs to care about
> users reporting something, and then never coming back, not even talking
> about keeping to poke the reporter to come back and say the fix works
> fine, and close it.  Thus the fix it, test it, resolve the bug as Fixed,
> and if the user do not reopen it, your work is done.
> 

Again, that's why I suggest that the verification be assigned to the
Team Lead. Its not like you have to 'poke the reporter' 1000 times
before the Team Lead does the verification [him|her]self.

I mean the Team Lead is supposed to help the team members along with a
little peer review, right? This process would just encourage more peer
review, right? And one of the biggest strengths of F/OSS is.... PEER
REVIEW!!

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz+U22QTTR4CNEQARAjDIAJwPDBcOjeuYFGSjwTznUGsg4RkgywCgnDYS
ZFQJDE+sjAzo/jROHnukoRU=
=y/cP
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Jon Portnoy]

On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Martin Schlemmer wrote:
> > Problem is many of us have sometimes already too many bugs to care about
> > users reporting something, and then never coming back, not even talking
> > about keeping to poke the reporter to come back and say the fix works
> > fine, and close it.  Thus the fix it, test it, resolve the bug as Fixed,
> > and if the user do not reopen it, your work is done.
> > 
> 
> Again, that's why I suggest that the verification be assigned to the
> Team Lead. Its not like you have to 'poke the reporter' 1000 times
> before the Team Lead does the verification [him|her]self.
> 
> I mean the Team Lead is supposed to help the team members along with a
> little peer review, right? This process would just encourage more peer
> review, right? And one of the biggest strengths of F/OSS is.... PEER
> REVIEW!!
> 

So when can we discuss the salaries you're going to pay the team leads 
to waste fairly significant quantities of time staring over everybody's 
shoulder? 8)

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Gregorio Guidi]

On Saturday 09 July 2005 16:54, Nathan L. Adams wrote:
> Martin Schlemmer wrote:
> > Problem is many of us have sometimes already too many bugs to care about
> > users reporting something, and then never coming back, not even talking
> > about keeping to poke the reporter to come back and say the fix works
> > fine, and close it.  Thus the fix it, test it, resolve the bug as Fixed,
> > and if the user do not reopen it, your work is done.
>
> Again, that's why I suggest that the verification be assigned to the
> Team Lead. Its not like you have to 'poke the reporter' 1000 times
> before the Team Lead does the verification [him|her]self.
>
> I mean the Team Lead is supposed to help the team members along with a
> little peer review, right? This process would just encourage more peer
> review, right? And one of the biggest strengths of F/OSS is.... PEER
> REVIEW!!

Any proposal that implies an enourmous increase of our human resources is 
really useless for us.
Please accept the fact that we cannot change our resources at will, and adapt 
any suggestion to this simple principle.

Gregorio
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Portnoy wrote:
> On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
> 
> So when can we discuss the salaries you're going to pay the team leads 
> to waste fairly significant quantities of time staring over everybody's 
> shoulder? 8)
> 

Ha! If you don't like people staring over your shoulder, or if you
expect payment for your time, go work for Microsoft. ;)

I mean seriously, since when is someone else looking at your work a Bad
Thing in F/OSS?? I really can't get my brain around that one.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz/Sy2QTTR4CNEQARAjZQAJ92xrrbvfn3LZAY4UJCq9jDKtJTxgCgjSSN
NxEldX9wWQLIJozIIJRqXbw=
=gnDc
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Stephen P. Becker]

Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jon Portnoy wrote:
> 
>>On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
>>
>>So when can we discuss the salaries you're going to pay the team leads 
>>to waste fairly significant quantities of time staring over everybody's 
>>shoulder? 8)
>>
> 
> 
> Ha! If you don't like people staring over your shoulder, or if you
> expect payment for your time, go work for Microsoft. ;)
> 
> I mean seriously, since when is someone else looking at your work a Bad
> Thing in F/OSS?? I really can't get my brain around that one.

Clearly, you either chose to blatantly ignore, or completely
misunderstood what avenj was saying.  What he *meant* was we don't have
the time or manpower to have developers take significant portions of
their valuable time to do what you suggest without paying somebody to do it.

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gregorio Guidi wrote:
> 
> Any proposal that implies an enourmous increase of our human resources is 
> really useless for us.
> Please accept the fact that we cannot change our resources at will, and adapt 
> any suggestion to this simple principle.

Now *that* is a reasonable argument.

But come on guys, I'm suggesting *one* look at a bug by an independent
party before marking it done.

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz/WW2QTTR4CNEQARAo8hAKCLfYZxHliZ1ChAgiuRZ6sNPwO8rwCgqCm6
SczzEoiUpUxklhRZ7muBl2o=
=/HL1
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen P. Becker wrote:
> Clearly, you either chose to blatantly ignore, or completely
> misunderstood what avenj was saying.  What he *meant* was we don't have
> the time or manpower to have developers take significant portions of
> their valuable time to do what you suggest without paying somebody to do it.
> 

No, I didn't blatantly ignore or misunderstand Jon. The ;) was meant to
imply humor, but I am the first to admit that email isn't the best
medium for that sort of thing.

But as far as the manpower thing goes, it is obviously a good and valid
point. Please read my last response to Ciaran on that topic.

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz/lM2QTTR4CNEQARAkoIAJ9EnB8nzHNSOIfJ5OW42bgNftvs0gCfbOkv
bcYnd7C9s0np/5SmY+iwzQE=
=i6xI
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Mike Frysinger]

On Friday 08 July 2005 11:46 pm, Nathan L. Adams wrote:
> Mike Frysinger wrote:
> >>>This brings up a point that really irks me. In the bug, I believe the
> >>> dev implies that the reported bug has merit /yet he closes the bug
> >>> before actually doing something about it/. And I don't mean to pick on
> >>> Jeffrey; this seems to be a common habit among Gentoo devs.
> >
> > that's because we got tired of asking for more info/whatever and never
> > getting anything back ... so we close the bug, get it off our 'todo'
> > lists, and wait for the user to get back to us (not all do)
> >
> > this is the biggest reason NEEDINFO was created
>
> Having the reporter be the verifier is a great idea (probably ideal),
> but again, you could assign the verification to the Team Lead. If the
> Team Lead can get the user to respond, great, otherwise they could do
> the QA themselves.

you missed the point of NEEDINFO

the bug is closed as NEEDINFO until the reporter gets back to us ... then it's 
re-opened ... in fact, the entire point is that the reporter *never responds 
again* so having them verify anything doesnt make any sense in this case
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[R Hill]

Nathan L. Adams wrote:
> Gregorio Guidi wrote:
>> Any proposal that implies an enourmous increase of our human resources is 
>> really useless for us.
>> Please accept the fact that we cannot change our resources at will, and adapt 
>> any suggestion to this simple principle.
> 
> Now *that* is a reasonable argument.
> 
> But come on guys, I'm suggesting *one* look at a bug by an independent
> party before marking it done.

That's reasonable, but I don't see that party being a Team Lead or even 
a dev.  If there's a bug filed and another user can confirm it, it's 
Verified.  That's the whole idea behind the status.

I don't really see much to gain by adding another step in the bug 
reporting process.  Some projects use it, some don't.  I don't think 
b.g.o is formal enough re. bugzilla to warrant it.

I do agree with the original point.  Reports shouldn't be marked 
resolved unless the bug is fixed or permanent, or not enough info is 
given to verify that a bug actually exists.

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Jon Portnoy]

On Sat, Jul 09, 2005 at 12:00:50PM -0400, Nathan L. Adams wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jon Portnoy wrote:
> > On Sat, Jul 09, 2005 at 10:54:46AM -0400, Nathan L. Adams wrote:
> > 
> > So when can we discuss the salaries you're going to pay the team leads 
> > to waste fairly significant quantities of time staring over everybody's 
> > shoulder? 8)
> > 
> 
> Ha! If you don't like people staring over your shoulder, or if you
> expect payment for your time, go work for Microsoft. ;)
> 
> I mean seriously, since when is someone else looking at your work a Bad
> Thing in F/OSS?? I really can't get my brain around that one.
> 

I didn't say that.

I'm saying that (a) team leads do not want to waste their time in such a 
way just to give you warm fuzzies (b) devs do not particularly want 
their team lead reviewing every single action they take, it sends the 
message that devs don't know wtf they're doing and need their hands held

-- 
Jon Portnoy
avenj/irc.freenode.net
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jon Portnoy wrote:
> I didn't say that.
> 
> I'm saying that (a) team leads do not want to waste their time in such a 
> way just to give you warm fuzzies (b) devs do not particularly want 
> their team lead reviewing every single action they take, it sends the 
> message that devs don't know wtf they're doing and need their hands held
> 

(a) Its not a waste of time, and it is a FACT that peer review improves
quality.

(b) That's just a little prima donna...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0HSj2QTTR4CNEQARAncMAJ9d4k5ATKQQGTEeba+Dx9GoFjklFwCgjEww
3YzpdaKhz0wr4zibNcRzTOk=
=lCjU
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Jory A. Pratt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nathan L. Adams wrote:

> Jon Portnoy wrote:
>
>> I didn't say that.
>
>> I'm saying that (a) team leads do not want to waste their time in
>>
> such a
>> way just to give you warm fuzzies (b) devs do not particularly
>> want their team lead reviewing every single action they take, it
>> sends the message that devs don't know wtf they're doing and need
>> their hands
> held
>
>
> (a) Its not a waste of time, and it is a FACT that peer review
> improves quality.
>
> (b) That's just a little prima donna...


    Nathan you have this misconception that just cause a bug apears on
one system it is gonna apear on multiple systems. Most compilation
bugs that I have seen are usually due to user not maintaining their
configurations properly. You also still fail to understand that most
of us maintain more packages than just one and it is impossible for us
to take and drop what we are working on to help test and confirm that
a bug does exist and is not user error. As far as team leads go they
make sure the project stay on task and packages and bugs are handled
in a timely manner. I would like to know do you want us to have 15
devs test for a particular bug if a team lead is not avaliable or
would you like us to have just 2 people test?

    This has gotten way out of control with time and how issues are
delt with, personally I think that you have a vendictive against a few
devs that have closed bugs on you that they have not been able to
replicate and/or find invalid. I can not say either way all I know is
you in FACT have a misconception of how much time goes into testing
before a package is moved to stable.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0IW9GDfjNg8unQIRAvhNAJ9gXX7KNauZuYTvR4exeHUR7t6zdgCgk8yH
LKl2nGSz2dLjmGrPb5gJAa4=
=BzWw
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jory A. Pratt wrote:
>     Nathan you have this misconception that just cause a bug apears on
> one system it is gonna apear on multiple systems.

What are you talking about? This whole discussion was framed with the
situation where the *developer* determines that the bug report has
merit. From my original post:

"In the bug, I believe the dev implies that the reported bug has merit
/yet he closes the bug before actually doing something about it/."

> Most compilation
> bugs that I have seen are usually due to user not maintaining their
> configurations properly.

Then that wouldn't be something that a dev would submit a fix for, now
would it?

> You also still fail to understand that most
> of us maintain more packages than just one and it is impossible for us
> to take and drop what we are working on to help test and confirm that
> a bug does exist and is not user error.

Again, you are confusing what I am suggesting with a completely
different situation. NEVER have I suggested that user configuration
problems should have some elaborate verification process.

> As far as team leads go they
> make sure the project stay on task and packages and bugs are handled
> in a timely manner.

Great! My hat's off to them!

> I would like to know do you want us to have 15
> devs test for a particular bug if a team lead is not avaliable or
> would you like us to have just 2 people test?

OK, now you're rambling. If a team lead isn't available they should have
a designated sub. That has nothing to do with the bug closer process;
that is a Gentoo organization issue.

>     This has gotten way out of control with time and how issues are
> delt with, personally I think that you have a vendictive against a few
> devs that have closed bugs on you that they have not been able to
> replicate and/or find invalid.

Yes, that tinfoil hat is paying off nicely for you. ;)

Seriously, my suggestion has nothing to with bugs that are found to be
invalid. Please read the thread carefully and that should become apparent.

Furthermore, I don't hold grudges against people who disagree with me.

And lastly, what bugs have I filed that were marked invalid that would
lead me to start this great conspiracy against some devs? Please
enlighten me:

http://bugs.gentoo.org/query.cgi?format=advanced

> I can not say either way all I know is
> you in FACT have a misconception of how much time goes into testing
> before a package is moved to stable.

Now you're a mind reader too. Please tell me what else I have a
misconception about. I'm sure my life will be greatly enriched by your
sage wisdom in the matter! ;)

If you want to continue the flamewar, I suggest we take it off this
mailing list; other subscribers might not find it as entertaining as I do...

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0JSk2QTTR4CNEQARAhTmAJ96wIR/fPFm9xTK+K+tOzmcztm3dQCgmxWr
+Zf5AtXi5Nux+eWK/Gfcbcg=
=moyc
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Daniel Drake]

Nathan L. Adams wrote:
> (a) Its not a waste of time, and it is a FACT that peer review improves
> quality.

I don't think anyone is disputing that it would be a beneficial concept, in
terms of improving quality and feedback.

However the suggestion you are making is really not practical in our
development model.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Henrik Brix Andersen]

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

Dear Nathan,

On Sat, 2005-07-09 at 12:04 -0400, Nathan L. Adams wrote:
> But come on guys, I'm suggesting *one* look at a bug by an independent
> party before marking it done.

Great! Thank you for your offer to review our bugfixes. Please start
right away.

Thanks again.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Henrik Brix Andersen wrote:
> Dear Nathan,
> 
> On Sat, 2005-07-09 at 12:04 -0400, Nathan L. Adams wrote:
> 
>>But come on guys, I'm suggesting *one* look at a bug by an independent
>>party before marking it done.
> 
> 
> Great! Thank you for your offer to review our bugfixes. Please start
> right away.
> 

Are you offering me a job? ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0R8t2QTTR4CNEQARAjV8AJ0QgimQUfj2PxpfC18jBB42dNirRgCfXZYt
0v6Tj6qMJU8Cmj+ZApi/Pkk=
=wyyT
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

R Hill wrote:
> Nathan L. Adams wrote:
>> But come on guys, I'm suggesting *one* look at a bug by an independent
>> party before marking it done.
> 
> 
> That's reasonable, but I don't see that party being a Team Lead or even
> a dev.  If there's a bug filed and another user can confirm it, it's
> Verified.  That's the whole idea behind the status.

I'm suggesting that the Team Lead be ultimately responsible, not that
the TL has to verify each bug. The best case would be that all bugs get
verified by the reporter (or another user as you suggest). The worst
case is that no reporters or other users verify the bug, so *then* the
TL gets the job.

> I don't really see much to gain by adding another step in the bug
> reporting process.  Some projects use it, some don't.  I don't think
> b.g.o is formal enough re. bugzilla to warrant it.

I'm suggesting that making b.g.o a *little* more formal might be a Good
Thing.

What do you think about adding the step only to certain critical
products, such as Portage or maybe Catalyst or even the Installation Docs?

> I do agree with the original point.  Reports shouldn't be marked
> resolved unless the bug is fixed or permanent, or not enough info is
> given to verify that a bug actually exists.

As Mike keeps pointing out, the NEEDINFO status covers bugs that a dev
can't reproduce, etc. But my suggestion only covers bugs that a dev has
provided a fix for (irreguardless of whether the dev reproduced the bug
or not).

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0Sjc2QTTR4CNEQARAvCdAJ4tJaecjuA2mQRtiOZ8O9pDOt4kHQCfaMGP
wtIxSh8fX218TXlYyOfBgQs=
=iPoD
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Daniel Drake]

Nathan L. Adams wrote:
> What do you think about adding the step only to certain critical
> products, such as Portage or maybe Catalyst or even the Installation Docs?

You're now significantly altering your proposal, from something that affects
almost everyone, to something that affects only some 'minority groups'. Nobody
can give you a straight single answer.

For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on
the catalyst mailing list. For installation docs, ask on the docs mailing
list. These groups are significantly different, have their own distinctive
procedures, etc.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Jason Stubbs]

On Sunday 10 July 2005 22:55, Nathan L. Adams wrote:
> What do you think about adding the step only to certain critical
> products, such as Portage or maybe Catalyst or even the Installation Docs?

Portage doesn't have a team lead as such. All bug traffic is delivered to all 
members via email though, so what is it that you are actually asking for?

Regards,
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Bugzilla HOWTO Update

[Daniel Drake]

Hi Chris,

Chris White wrote:
> Doc is still here:
> 
> http://www.gentoo.org/doc/en/bugzilla-howto.xml

I've just read over it in full. It looks good - thanks for writing it.

As you know, I've been meaning to write one of these for a while. I've been
keeping a list of topics I think should be mentioned. Stripping out the ones
you have covered, here's what I have left:

maintainer-needed description
maintainer-wanted description
why isnt my bug being looked at
why isnt my ebuild being looked at
what are bug-wranglers
never reassign a bug
dont close as fixed just because you have a workaround
if in doubt, let the developer close it
link to how to go into the testing tree
make sure you are using the latest version
always try the testing package before reporting bug
dont pollute existing bugs by posting unrelated or related problems. use one
bug for one issue.
always post "emerge info"
always upload as plain text
always attach large postings, never paste
always use unified diff
always post stuff on the bug, never in private email unless requested
if you find a duplicate bug, instead of filing yours, tag onto the end of the
existing one, even if the information you are adding does not differ
debugging with dmesg
never say "it doesnt work" or "it crashes"
post config.log if it fails during configure
why did you mark it as upstream instead of fixing it yourself
how to apply patches in general
how to apply patches in ebuilds

Since the doc is already covering a lot of content, and adding some of these
points to it will broaden it further, I think it makes sense to have 2 docs.
One for "how to report a bug", and another for "how to give us lots of yummy
info" in a bug report.

Something like:

How to report a bug:
- Search, check that nobody has filed it already
- Fill in the form under the right product
- How to get "emerge info" output
- General policy stuff:
  - If attaching, use plain text and never tarballs
  - Don't reassign bugs, leave that to devs
  - Don't close just because you have workarounds
- What to do if your bug isnt getting attention
- maintainer-needed/wanted description
etc....

How to give us lots of yummy info:
- How to apply patches
- How to use strace
- How to identify a configure failure
  - and how to upload config.log
- How to use gdb, for C apps
- Using valgrind?
etc....

That way, most users will find all the information they need in the first doc,
without being scared away by scary stuff. It would also serve as a document
that you can read and understand in full before filing your first bug. Those
who have the time and experience can go onto the second doc and learn how to
help us debug the problem after the bug has been filed.

It could also be used as a reference thing, e.g. on a kernel bug, I'll say
"please try this patch", user says "how?", it would be nice if i could point
them to a specific page on the tech doc.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Drake wrote:
> Nathan L. Adams wrote:
> 
>>What do you think about adding the step only to certain critical
>>products, such as Portage or maybe Catalyst or even the Installation Docs?
> 
> You're now significantly altering your proposal, from something that affects
> almost everyone, to something that affects only some 'minority groups'. Nobody
> can give you a straight single answer.

The whole point of this discussion is to get feedback and alter the idea
as needed, not to beat everyone over the head with the Original Idea (c)
until everyone sees it My Way (TM). So kindly pick the version of the
idea that you like best, and base your discussion on that. ;)

> For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on
> the catalyst mailing list. For installation docs, ask on the docs mailing
> list. These groups are significantly different, have their own distinctive
> procedures, etc.

Good point. See my reply to Jon Portnoy for the latest revision of the
idea that would apply to everyone as an optional 'best practice'.

Nathan

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0TtM2QTTR4CNEQARAjeAAJ0bhA31Oc0Ho5mRnjkjCvg5zZZVkwCgm7Ib
ehPatwEpWl9LdD59n8HJnxE=
=J1U+
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Bugzilla HOWTO Update

[Nathan L. Adams]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris White wrote:
> Doc is still here:
> 
> http://www.gentoo.org/doc/en/bugzilla-howto.xml
> 
> After a good ammount of user input the bugzilla doc has been updated.  The new version uses ggdb3 instead of g for debugging and contains a new section on testing ebuilds.  Thanks goes to robbat2 for his commentary on what to improve.  Thanks goes to the people who help fix my crap for grammar mistakes ;).  So far it seems to be comming along nicely, I've been notified of the upgrade to bugzilla comming soon, and will update my screenshots and other information accordingly.  Thanks again to everyone.
> 
> Chris White

This sort of thing could reduce the number of INVALID and NEEDINFO bugs.
Great job!

Nathan


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC0TvG2QTTR4CNEQARAl3LAKCd4ODRkgSLpgf64yz1BcrGZAbnAwCeKPg+
RNBnuP0w+ISiDU2XFvqU3js=
=c30Y
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Daniel Drake]

Nathan L. Adams wrote:
> Good point. See my reply to Jon Portnoy for the latest revision of the
> idea that would apply to everyone as an optional 'best practice'.

Again, it doesn't really work like this. The groups you describe are different
in nature, and certain procedures suit some groups better than others. Sure,
we can write somewhere "its good to review bug fixes" but thats not really
making any progress unless you can convert a particular group to do it as you
describe.

(As a sidenote, I don't think writing a general recommendation like that is
such a good idea. At least, I can't see it working in the groups I am involved
in.)

Here's what I suggest you do:

Pick a group. Subscribe to their mailing list.

Write a mail to their list, stating clearly what you think the current problem
is, and how you propose to solve or minimize it. Be prepared to back up your
proposal with existing closed bug reports, where having someone explicitly
review the fix and make a comment after the bug has been fixed would have been
beneficial and would have made some positive difference.

Try hard to understand their responses in full. As you've found out, its not
easy to know whether your own suggestions would be worthwhile to a development
community which you haven't had much involvement in (at least, not as much
involvement as the people you are speaking to).

Good luck :)

Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]

[Henrik Brix Andersen]

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

On Sun, 2005-07-10 at 09:14 -0400, Nathan L. Adams wrote:
> Are you offering me a job? ;)

Are you applying for one?

No, really - I think the basic idea in your proposal is great. But
Gentoo is a community based open source software project, worked on by
volunteers in their spare time. I think you're forgetting this in your
current proposal.

If you're so keen on seeing this proposal through, I suggest you do what
any other open source developer must do to get his/her ideas through:
show me the code - or in this context - be prepared to do most of the
initial work yourself. That's how open source works.

Sincerely,
Brix
-- 
Henrik Brix Andersen <brix@gentoo.org>
Gentoo Metadistribution | Mobile computing herd

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

Re: [gentoo-dev] New Bugzilla HOWTO Update

[Shyam Mani]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/10/2005 08:27 PM, Daniel Drake wrote:

> As you know, I've been meaning to write one of these for a while. I've been
> keeping a list of topics I think should be mentioned. Stripping out the ones
> you have covered, here's what I have left:
> 
> maintainer-needed description
> maintainer-wanted description

These two are there, but kinda obscure. They need to be more prominent.
As for the rest of the points you've brought up, did you have time to
pen down answers as well? If so, could we have a look at them please?
Some answers are obvious, but some others aren't and these points are
quite valid and do need to be in the doc.

> Since the doc is already covering a lot of content, and adding some of these
> points to it will broaden it further, I think it makes sense to have 2 docs.
> One for "how to report a bug", and another for "how to give us lots of yummy
> info" in a bug report.
> 
> Something like:
> 
> How to report a bug:
> - Search, check that nobody has filed it already
> - Fill in the form under the right product
> - How to get "emerge info" output
> - General policy stuff:
>   - If attaching, use plain text and never tarballs
>   - Don't reassign bugs, leave that to devs
>   - Don't close just because you have workarounds
> - What to do if your bug isnt getting attention
> - maintainer-needed/wanted description
> etc....
> 
> How to give us lots of yummy info:
> - How to apply patches
> - How to use strace
> - How to identify a configure failure
>   - and how to upload config.log
> - How to use gdb, for C apps
> - Using valgrind?
> etc....

Yeah, I guess that's the way the doc will go now. I'll have a word with
Chris before we start splitting the doc. Other docs-team people had a
similar opinion as well, so I guess it's only a matter of time before we
end up having the above format.

> It could also be used as a reference thing, e.g. on a kernel bug, I'll say
> "please try this patch", user says "how?", it would be nice if i could point
> them to a specific page on the tech doc.

Very valid point. Thanks for the inputs Daniel! :)

Regards,

- --
Shyam Mani | <fox2mike@gentoo.org>
docs-team  | http://gdp.gentoo.org
GPG Key    | 0xFDD0E345
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC0YGFYZNYgP3Q40URAsACAJ9q3nWpqaJlTvAXUHIQq0iuSKuqRQCeN3cn
Apy9mAtQymYDYRXGy/kkMQY=
=SBEp
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Bugzilla HOWTO Update

[Daniel Drake]

Shyam Mani wrote:
> As for the rest of the points you've brought up, did you have time to
> pen down answers as well? If so, could we have a look at them please?
> Some answers are obvious, but some others aren't and these points are
> quite valid and do need to be in the doc.

I haven't written any answers. I was planning to write this document based on
those points, but never got around to it.

I'm happy to modify the document to cover my points, but I don't know when I'd
get time to do so. So if you or anyone else want to takes the job, feel free ;)
If you'd like me to elaborate on any points, just ask.

Thanks,
Daniel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Bugzilla HOWTO Update

[David Morgan]

On 15:57 Sun 10 Jul     , Daniel Drake wrote:
> How to give us lots of yummy info:
> - How to apply patches
> - How to use strace
> - How to identify a configure failure
>   - and how to upload config.log
> - How to use gdb, for C apps
> - Using valgrind?
> etc....

Tigger wrote a doc about writing helpful bug reports for the auditing
team which covers some of this. I can't remember the url, so someone
might like to poke him about it if he isn't paying attention to this
discussion.

Dave

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] New Bugzilla HOWTO Update

[Chris White]

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

Doc is still here:

http://www.gentoo.org/doc/en/bugzilla-howto.xml

After a good ammount of user input the bugzilla doc has been updated.  The new version uses ggdb3 instead of g for debugging and contains a new section on testing ebuilds.  Thanks goes to robbat2 for his commentary on what to improve.  Thanks goes to the people who help fix my crap for grammar mistakes ;).  So far it seems to be comming along nicely, I've been notified of the upgrade to bugzilla comming soon, and will update my screenshots and other information accordingly.  Thanks again to everyone.

Chris White

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

[gentoo-dev] New Bugzilla HOWTO splitup

[Chris White]

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

Thanks to everyone that has given me input on the bugzilla document.  Right now we're working on splitting up the bugzilla guide as dsd has suggested.  Sorry about the delay in response, but these docs have been keeping me fairly busy (work as well), and with the school semester comming up soon, things are gonna get really weird really fast ;).  More information to come soon.

Chris White

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

Re: [gentoo-dev] New Bugzilla HOWTO Update

[Daniel Drake]

Chris White wrote:
>>never reassign a bug
> 
> 
> Ok, I have a section on how to re-assign the bug to the maintainer if you're the reporter, so you don't want that at all is what you're saying?  Just let bug-wranglers handle it?

Yes, I'm pretty much saying that. Thinking back to the situation that prompted
me to note this down, a kernel bug came in. bug-wranglers assigned it to
kernel. The reporter then reassigned it to me(!?) without me even responding,
with a comment like, "dsd this one is for you". Since when do our users get to
choose which developer fixes their bug? I found this quite rude and replied
with a (probably too harsh) comment and reassigned it back to kernel. The user
then sent me an apologetic email, stating that he didn't know much about
Gentoo development and asked me to explain the reassignment procedures.

My response to that: Just leave reassignment to the developers (wranglers
included).

>>always try the testing package before reporting bug
> 
> 
> Not sure what you mean by this.  I'd assume they would have already tested the package in order to have hit the bug?

If v3.2.1 is stable, and v3.2.2 is ~arch, and they found the bug on v3.2.1,
then they should also try v3.2.2 before filing the bug. Thats all I was
thinking of.

>>how to apply patches in general
> 
> 
> I need a clearer example of this.  Do you mean applying kernel patches?  Most users will just need to know how to patch ebuilds and add epatch lines to ebuilds, I'm not sure of anything else.

I mean applying patches using patch. So yes, kernel patches would be included
under that. And I imagine there are many situations (for non-kernel stuff)
where using patch is easier than epatch.

For example, to add a patch to a small ebuild package, you can either create
an overlay, copy the ebuild over, modify the ebuild to add epatch (this
involves being able to find the right function in the ebuild, possibly even
_creating_ a src_unpack function, requiring a lot of knowledge from the user),
make a filesdir, put patch in filesdir, emerge.

Or:

cd /usr/portage/blah/blah
ebuild blah.ebuild unpack
pushd /var/tmp/portage/blah/work/blah
patch -p1 /path/to/patch
popd
ebuild blah.ebuild merge

I think the latter version is easier since it doesn't require as much
background knowledge. And the patch technique is useful to know for if you
need to patch a kernel or something like that.

Daniel
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: New Bugzilla HOWTO Update

[Duncan]

Daniel Drake posted <42D649CE.3070101@gentoo.org>, excerpted below,  on
Thu, 14 Jul 2005 12:17:34 +0100:

> Chris White wrote:
>>>never reassign a bug
>> 
>> 
>> Ok, I have a section on how to re-assign the bug to the maintainer if
>> you're the reporter, so you don't want that at all is what you're
>> saying?  Just let bug-wranglers handle it?
> 
> Yes, I'm pretty much saying that. Thinking back to the situation that
> prompted me to note this down, a kernel bug came in. bug-wranglers
> assigned it to kernel. The reporter then reassigned it to me(!?) without
> me even responding, with a comment like, "dsd this one is for you". Since
> when do our users get to choose which developer fixes their bug? I found
> this quite rude and replied with a (probably too harsh) comment and
> reassigned it back to kernel. The user then sent me an apologetic email,
> stating that he didn't know much about Gentoo development and asked me to
> explain the reassignment procedures.
> 
> My response to that: Just leave reassignment to the developers (wranglers
> included).

Counter-example.  The amd64 team specifically mentions in their
documentation on keywording that keyword bugs can be specifically assigned
to amd64.  Likewise with the multilib-strict bugs, they were to be
assigned to amd64.  Of course, that's an arch team, not an individual
developer, but the point stands, if these bugs are being filed on specific
request of some team or individual developer (as with testing of some
package or another), there's no reason to bother bug-wranglers with it,
when all they are going to do is assign it to the same folks that
requested it, that got the user testing and filing the bug in the first
place!

So... something like the following (first draft off the top of my head,
can probably be rewritten rather better than this):

"Leave the bug assignment alone, unless you are sure you know who to
assign it to.  For most bugs and reporters, that means let the
bug-wranglers handle it, unless the bug has been filed in response to a
specific request by the package maintainer/herd or your arch team.  If you
are reading this, it probably means leave it alone."

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list