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

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

[Jory A. Pratt]

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

    I have sat here and read you all rant on and on about these
issues, but you still are not taking into account that when a bug is
marked worksforme or needmoreinfo that we are unable to replicate the
error. We are not saying that the bug does not exist we are saying
that of all the QA that we can do for you the user are unable to
replicate the error.
If you can point out a number of bugs that violate my points please
say so ... If you can not I believe you need to step back re-evalute
the your thoughts and possibly send an apoligy to the DEV's. You
forget we do not get paid for our time and/or work that we put into
your DISTRO.

Sincely
    Jory

P.S. I am not looking for a flame war I am looking for you all to step
back and think before you say that no QA is being completed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCz0nvGDfjNg8unQIRAhhSAKCzfvWNC/eKrE7R5TlerkjqSnTYdgCcCNPI
E4EW86zFhUMXdtS1mZr/9Fw=
=DFhN
-----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:
>     I have sat here and read you all rant on and on about these
> issues,

Jory, I take issue with that. I am not ranting. I am proposing a way to
*improve* QA.

> but you still are not taking into account that when a bug is
> marked worksforme or needmoreinfo that we are unable to replicate the
> error. We are not saying that the bug does not exist we are saying
> that of all the QA that we can do for you the user are unable to
> replicate the error.

I do software development, systems integration, and bug squashing for a
living. I know this fact: Sometimes the developer doesn't realise what
the actual problem is. Sometimes its because the end-user didn't
communicate well. Sometimes its because the developer is being an ass
(we've all been guilty of this). *That* is why verification should be
done not by the person writing the fix. It should be by an independent
party; Team Lead, reporter, etc.

> If you can point out a number of bugs that violate my points please
> say so ... If you can not I believe you need to step back re-evalute
> the your thoughts and possibly send an apoligy to the DEV's. You
> forget we do not get paid for our time and/or work that we put into
> your DISTRO.

"Dear Developers Who Take Constructive Critizism as Insults,

Please grow thicker skin. No one is out to get you. Believe it or not,
the people trying to improve the process are on your side, and they're
not trying to insult you. No one is saying that because the process
could be better that your work is somehow diminished.

Sincerely,

Nathan

p.s. End-users aren't paid to report bugs on 'your DISTRO' either."

> 
> Sincely
>     Jory
> 
> P.S. I am not looking for a flame war

Well you severly missed the mark on that one...

> I am looking for you all to step
> back and think before you say that no QA is being completed.

Maybe you should stop assuming that a critique of a process is a
personal insult. And I never said that 'no QA is being completed'. I'm
suggesting a way to improve QA.

Nathan

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

iD8DBQFCz+kV2QTTR4CNEQARAjrTAJ0a3xa6Tao/+u5P7UGXjK6xonzLogCfexzQ
BN9PNjeOoQO3e12Dz4taKZA=
=S0om
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| I do software development, systems integration, and bug squashing for
| a living.

Gentoo's 'moving target' development model is not the development model
used by your typical 'stable release once or twice per year' large
software development project.

HTH,
-- 
Ciaran McCreesh
-- 
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

Ciaran McCreesh wrote:
> On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | I do software development, systems integration, and bug squashing for
> | a living.
> 
> Gentoo's 'moving target' development model is not the development model
> used by your typical 'stable release once or twice per year' large
> software development project.
> 

That is absolutely true. But what I'm suggesting is by no means as
strict as what you will find in those environments. I just think a
small, incremental move in that direction could significantly improve
Gentoo's QA process.

Nathan

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

iD8DBQFCz/Wm2QTTR4CNEQARAscBAJ9dBE+wWl1Tq0sZcMxC19ZQeNRYCACgh0HG
QrB00IUUp3AI9ojffFEvYQo=
=H6iQ
-----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

Ciaran McCreesh wrote:
> On Sat, 09 Jul 2005 11:11:17 -0400 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | I do software development, systems integration, and bug squashing for
> | a living.
> 
> Gentoo's 'moving target' development model is not the development model
> used by your typical 'stable release once or twice per year' large
> software development project.
> 

Ah, how about this:

Most of Gentoo's developers are concerned with Ebuilds (packaging if you
will). A small subset of developers are concerned with Portage itself.

Would have a *slightly* improved QA process on Portage development be
such a bad thing/impossible. As I posted earlier, all I'm suggesting is
*one* verification check by the Team Lead or the reporter before marking
a bug as done. And Portage is arguably more stable and less fluid than
the entirety of the ebuild tree.

Nathan

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

iD8DBQFCz/aK2QTTR4CNEQARApI1AKCH+XUcl4FR7xjZIK4V+GQPUFXoLACeJc5W
M00736E0mlNtN7IqEqDh6wA=
=Y9+n
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Marco Matthies]

Nathan L. Adams wrote:
> Jory, I take issue with that. I am not ranting. I am proposing a way to
> *improve* QA.

Some thoughts from a humble user:

Any improvement must neither excessively waste developer nor user time,
it is the most scarce resource. To optimize this, the common case must
be made fast, and the common case is that the bug has been truly fixed
when it has been closed.

The person reporting the bug can reopen the bug, as he/she is in a
perfect position to test the fix. You can't have the people (developers)
who are already the busiest spend significant time recreating bugs and
testing the fix, just to find out that, yes indeed, it has been fixed.

Sincerely,
Marco
-- 
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

Marco Matthies wrote:
> Nathan L. Adams wrote:
> 
>>Jory, I take issue with that. I am not ranting. I am proposing a way to
>>*improve* QA.
> 
> 
> Some thoughts from a humble user:
> 
> Any improvement must neither excessively waste developer nor user time,
> it is the most scarce resource. To optimize this, the common case must
> be made fast, and the common case is that the bug has been truly fixed
> when it has been closed.
> 
> The person reporting the bug can reopen the bug, as he/she is in a
> perfect position to test the fix. You can't have the people (developers)
> who are already the busiest spend significant time recreating bugs and
> testing the fix, just to find out that, yes indeed, it has been fixed.
> 
> Sincerely,
> Marco

I don't think any of the devs would suggest that *any* fix should be
accepted without first testing it (under the current process). If you
don't believe me, submit it an ebuild and keyword it as stable on a
platform that you have not tested it on. The change I'm suggesting is
having either the reporter or the Team Lead verify that the 'fix'
actually works.

Also, in the case were the 'fix' doesn't actually fix the bug, you waste
alot more development time by letting it slip through and having to
'fix' it again later. So you can justify the time cost now, with time
saved later.

But then again, developer time *is* a very scarce resource. That's why I
fielded the idea that the verification process only be required on
things like Portage.

Good development takes time.

Nathan


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

iD8DBQFC0Cvw2QTTR4CNEQARAg7MAJ912/60YTVVPBm3AQGFy4gMweYSsgCfTfym
3sQwbgylKR1GD6LllzKQDl4=
=E0DJ
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Sat, 09 Jul 2005 15:56:32 -0400 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| I don't think any of the devs would suggest that *any* fix should be
| accepted without first testing it (under the current process). If you
| don't believe me, submit it an ebuild and keyword it as stable on a
| platform that you have not tested it on. The change I'm suggesting is
| having either the reporter or the Team Lead verify that the 'fix'
| actually works.

Oh absolutely, I agree entirely that it is a vital part of the QA
process that the team lead verifies that an arch developer has correctly
managed to use ekeyword.

-- 
Ciaran McCreesh
-- 
gentoo-dev@gentoo.org mailing list

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

[Marco Matthies]

Nathan L. Adams wrote:
> Also, in the case were the 'fix' doesn't actually fix the bug, you waste
> alot more development time by letting it slip through and having to
> 'fix' it again later. So you can justify the time cost now, with time
> saved later.

Just think of it as branch prediction.
If the case you describe here truly were that common, we'd all be doomed
anyway, as that would mean the common case is developers closing bugs
without fixing them and users filing bugs but not being interested if
they're fixed.

> But then again, developer time *is* a very scarce resource. That's why I
> fielded the idea that the verification process only be required on
> things like Portage.

Yes, in a volunteer project such scrutinous QA will certainly only work
in a small domain, and is only really feasible for the most critical
components. On the other hand, IMHO, these components are already the
most thoroughly tested - I'd trust portage with brain surgery any day!

As a final note, I have enjoyed this conversation but I'm actually not
really qualified to talk about these matters as I'm not a gentoo dev, so
I'll refrain from more philosophizing - otherwise somebody might take me
up on that brain-surgery thing :)

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

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

[R Hill]

Marco Matthies wrote:
> Nathan L. Adams wrote:
> The person reporting the bug can reopen the bug, as he/she is in a
> perfect position to test the fix.

Just a thought I've had from time to time - why can't people other than 
the reporter reopen a resolved bug report?  I'm thinking that there are 
cases where the reporter files a PR that gets marked resolved for 
whatever reason and then buggers off.  Later someone else comes across 
the bug and can either comment in the closed bug and hope someone 
notices or file a new report which will inevitably be marked Dupe. 
What's the correct thing to do in this situation?

--de.

-- 
gentoo-dev@gentoo.org mailing list

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

[Duncan]

R Hill posted <daqjb7$8m2$1@sea.gmane.org>, excerpted below,  on Sun, 10
Jul 2005 01:39:18 -0600:

> Marco Matthies wrote:
>> Nathan L. Adams wrote:
>> The person reporting the bug can reopen the bug, as he/she is in a
>> perfect position to test the fix.
> 
> Just a thought I've had from time to time - why can't people other than 
> the reporter reopen a resolved bug report?  I'm thinking that there are 
> cases where the reporter files a PR that gets marked resolved for 
> whatever reason and then buggers off.  Later someone else comes across 
> the bug and can either comment in the closed bug and hope someone 
> notices or file a new report which will inevitably be marked Dupe. 
> What's the correct thing to do in this situation?

Here's how I've handled it.  I've filed a new bug, mentioning the other
one by number (which bugzilla will automatically turn clicky to reach the
old one, if you give it the proper hint, bugzilla #xxxxxx) in my report,
and detailing why the issue remains, either detailing how this report is
the same issue and the fix either wasn't right or wasn't reapplied to a
new version, or detailing how this one may /look/ similar but is /not/ the
same, because x and y and z are different.

This works well enough, because it's known that only the original reporter
can reopen, so they aren't expecting you to do something you can't do. 
Further, you preempt the duplicate thing, by saying why this one is
different or why the problem reoccurred.  For those unable to trace the
technical details, simply saying the same problem appears to occur with a
new version, or still occurs for them with the old version, or whatever,
should suffice.

-- 
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: Closing bugs [was: New Bugzilla HOWTO]

[R Hill]

Nathan L. Adams wrote:
> living. I know this fact: Sometimes the developer doesn't realise what
> the actual problem is. Sometimes its because the end-user didn't
> communicate well. Sometimes its because the developer is being an ass
> (we've all been guilty of this). *That* is why verification should be
> done not by the person writing the fix. It should be by an independent
> party; Team Lead, reporter, etc.

a) what would be the point of the reporter also being the verifier as 
far as confirming that the bug is real and not a PEBKAC error?

b) what would be the point of requiring that verification be done by a 
third party if the dev the PR is assigned to can reproduce the bug 
themselves?

c) how do you propose the assignee fix the bug if they cannot reproduce 
it?  this may be possible in some cases, but not anywhere near the majority.

d) team leads lead the team, not attempt to reproduce bugs for every PR 
that falls under their umbrella.  to be blunt, they have much better 
things to do.

> "Dear Developers Who Take Constructive Critizism as Insults,
> 
> Please grow thicker skin. No one is out to get you. Believe it or not,
> the people trying to improve the process are on your side, and they're
> not trying to insult you. No one is saying that because the process
> could be better that your work is somehow diminished.
> 
> Sincerely,
> 
> Nathan


Dear Nathan,

In your spare time, could you please begin testing every new problem 
report filed as of now for validity and tag them appropriately?  This 
small, incremental move should greatly improve our QA process.  Thanks boo.

XOXOX

--de.

Note: I am not denying there could be a (small) policy problem, I'm just 
pointing out that the proposed solution is unworkable.

-- 
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:
> a) what would be the point of the reporter also being the verifier as
> far as confirming that the bug is real and not a PEBKAC error?

Sometimes devs do clever things to their systems that end-users aren't
aware of, or they test the fix logged into their machine with special
priviledges, etc. So having the reporter verify would test the fix with
those things out of the loop.

> b) what would be the point of requiring that verification be done by a
> third party if the dev the PR is assigned to can reproduce the bug
> themselves?

I'm assuming that this would only apply to cases where the dev has
provided a fix (in most cases I assume they would have reproduced the
problem). The reporter's test would have the benefits mentioned above,
and if the Team Lead tested, they could review the fix for technical
correctness, etc.

> c) how do you propose the assignee fix the bug if they cannot reproduce
> it?  this may be possible in some cases, but not anywhere near the
> majority.

My suggestion doesn't even cover that; it assumes that the dev has
provided a fix.

> d) team leads lead the team, not attempt to reproduce bugs for every PR
> that falls under their umbrella.  to be blunt, they have much better
> things to do.

Is it out of the scope of the Team Lead to check that [his|her] devs are
fixing things in a technically correct manner? From the "Gentoo
Developer Handbook":

"Team leads are responsible for organizing the developer in their team
and coordinating releases and also resolving issues within the team, as
well as improving products on the basis of feedback from the community."

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=5

I think a bug report qualifies as feedback from the community and
verifying that a bug fix actually works would qualify as improving products.

> Dear Nathan,
> 
> In your spare time, could you please begin testing every new problem
> report filed as of now for validity and tag them appropriately?  This
> small, incremental move should greatly improve our QA process.  Thanks boo.

Again, my suggestion attempts to improve the process farther down
stream; the problem of validating new bugs and tagging them
appropriately is a separate matter.

Also, suggesting that I do all the work is silly. It suggests, to me at
least, that you can't find anything wrong with what I'm suggesting, but
for some reason or another you're unwilling to change your working
habits. So you throw up the "if its such a good idea, you do it... ALL
of it!" nonsense. Obviously, no process (including the current Gentoo
bugzilla process being used daily) will work without participation from
most of the people involved. There will *always* be people who disagree,
and there will *always* be people who skirt the system in some way.
That's just life.

> Note: I am not denying there could be a (small) policy problem, I'm just
> pointing out that the proposed solution is unworkable.

Great! Can you think of any ways to make my idea workable? What about a
completely different solution?

To restate the problem: When a dev submits a fix for a bug, it should be
verified and peer reviewed before the bug is marked done.

Nathan

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

iD8DBQFC0Sdc2QTTR4CNEQARAsh+AJ93PRmC0JLJlBNV3kSbFlKR2vOkOgCdEpvq
2SVJFg/G2B0sb8CXTstOGEY=
=CAPL
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Jon Portnoy]

On Sun, Jul 10, 2005 at 09:49:16AM -0400, Nathan L. Adams wrote:
> 
> To restate the problem: When a dev submits a fix for a bug, it should be
> verified and peer reviewed before the bug is marked done.
> 

That's not a problem, that's an opinion.

I'm not at all convinced that not having every bug resolution reviewed 
every time is a problem, maybe you should start there :)

-- 
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:
> On Sun, Jul 10, 2005 at 09:49:16AM -0400, Nathan L. Adams wrote:
> 
>>To restate the problem: When a dev submits a fix for a bug, it should be
>>verified and peer reviewed before the bug is marked done.
>>
> 
> 
> That's not a problem, that's an opinion.
> 
> I'm not at all convinced that not having every bug resolution reviewed 
> every time is a problem, maybe you should start there :)
> 

Well originally I was going for "any bug that a dev thinks has merit",
but after reading some of the replies I'm now leaning towards "any bug
that a dev submits a fix for". And I've also fielded the idea that it
only be mandatory for certain critical products such as Portage.

Maybe as a start, the Developer's Guide can be revised to state that:

"Ideally any bug that a fix is submitted for should be verified and peer
reviewed. It should be verified by the reporter or another user. If the
reporter or another user are unable or unwilling to verify the fix, the
Team Lead should take responsibility for the verification. Ideally, all
bug fixes should be peer reviewed by the Team Lead and/or other team
members before the bug is marked as RESOLVED.

The following products have been deemed critical, and therefor must
follow the above process:

X
Y
Z"

Then it becomes a completely optional 'best practice' for the vast
majority of bugs.

Nathan

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

iD8DBQFC0Tn52QTTR4CNEQARAliRAJ9CNmaI5OnHd4i1w0UKHEBq2e9XxgCgk2Hh
4Ep0I76PAIb9ItQCmD/929E=
=YQOy
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Sun, 10 Jul 2005 11:08:41 -0400 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| Maybe as a start, the Developer's Guide can be revised to state that:
| 
| "Ideally any bug that a fix is submitted for should be verified and
| peer reviewed. It should be verified by the reporter or another user.
| If the reporter or another user are unable or unwilling to verify the
| fix, the Team Lead should take responsibility for the verification.
| Ideally, all bug fixes should be peer reviewed by the Team Lead and/or
| other team members before the bug is marked as RESOLVED.

Again, Gentoo is not a large corporation or Debian. The assumption is
that the majority of fixes are done correctly the first time, and this
assumption is valid. Hence, the default behaviour is to mark bugs as
RESOLVED, with reopening being an entirely legitimate and encouraged
response for those occasional instances where the resolution was not
sufficient.

-- 
Ciaran McCreesh
-- 
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

Ciaran McCreesh wrote:
> On Sun, 10 Jul 2005 11:08:41 -0400 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | Maybe as a start, the Developer's Guide can be revised to state that:
> | 
> | "Ideally any bug that a fix is submitted for should be verified and
> | peer reviewed. It should be verified by the reporter or another user.
> | If the reporter or another user are unable or unwilling to verify the
> | fix, the Team Lead should take responsibility for the verification.
> | Ideally, all bug fixes should be peer reviewed by the Team Lead and/or
> | other team members before the bug is marked as RESOLVED.
> 
> Again, Gentoo is not a large corporation or Debian.


I don't see how Gentoo's status (or rather lack thereof) as a
corporation or Debian has anything to do with encouraging peer review.

> The assumption is
> that the majority of fixes are done correctly the first time, and this
> assumption is valid.

I don't see how you could prove that assumption. If you can, please do so.

> Hence, the default behaviour is to mark bugs as
> RESOLVED, with reopening being an entirely legitimate and encouraged
> response for those occasional instances where the resolution was not
> sufficient.
> 

There are plenty of devs who don't share in the viewpoint that reopening
bugs is legitimate and should encouraged (although I agree it is and
should be). I base opinion that on some of the kicking and screaming
I've seen on bugzilla in the past. ;)

Nathan

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

iD8DBQFC0T+c2QTTR4CNEQARAmhWAJ485c4s5MjMzQRUrCn4rR06qB/nDwCfQowx
KGJfs0VkcxZO3yHOKKIPFwE=
=LdlM
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

On Sun, 10 Jul 2005 11:32:44 -0400 "Nathan L. Adams" <nadams@ieee.org>
wrote:
| > Again, Gentoo is not a large corporation or Debian.
| 
| I don't see how Gentoo's status (or rather lack thereof) as a
| corporation or Debian has anything to do with encouraging peer review.

You're taking methods from a "how your typical oversized software
engineering bloatware project works" situation and trying to apply them
outside of their domain.

| > The assumption is
| > that the majority of fixes are done correctly the first time, and
| > this assumption is valid.
| 
| I don't see how you could prove that assumption. If you can, please do
| so.

Experience. I receive bug mail for a heck of a lot of bugs. I see how
many of them are indeed correctly resolved when they are marked as such.

| > Hence, the default behaviour is to mark bugs as
| > RESOLVED, with reopening being an entirely legitimate and encouraged
| > response for those occasional instances where the resolution was not
| > sufficient.
| > 
| 
| There are plenty of devs who don't share in the viewpoint that
| reopening bugs is legitimate and should encouraged (although I agree
| it is and should be). I base opinion that on some of the kicking and
| screaming I've seen on bugzilla in the past. ;)

No, that kicking and screaming is reserved for when bugs are reopened
inappropriately.

-- 
Ciaran McCreesh
-- 
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

Ciaran McCreesh wrote:
> On Sun, 10 Jul 2005 11:32:44 -0400 "Nathan L. Adams" <nadams@ieee.org>
> wrote:
> | > Again, Gentoo is not a large corporation or Debian.
> | 
> | I don't see how Gentoo's status (or rather lack thereof) as a
> | corporation or Debian has anything to do with encouraging peer review.
> 
> You're taking methods from a "how your typical oversized software
> engineering bloatware project works" situation and trying to apply them
> outside of their domain.

The Linux kernel has a mult-tiered sign-off/peer review method[1]. I
guess they're just your typical oversized software engineering bloatware
project then, right?

> | > The assumption is
> | > that the majority of fixes are done correctly the first time, and
> | > this assumption is valid.
> | 
> | I don't see how you could prove that assumption. If you can, please do
> | so.
> 
> Experience. I receive bug mail for a heck of a lot of bugs. I see how
> many of them are indeed correctly resolved when they are marked as such.

Ah ha! So you've been peer reviewing bug fixes!!! Wouldn't it be nice if
all developers did that sort of thing and gained that kind of experience?

> | > Hence, the default behaviour is to mark bugs as
> | > RESOLVED, with reopening being an entirely legitimate and encouraged
> | > response for those occasional instances where the resolution was not
> | > sufficient.
> | > 
> | 
> | There are plenty of devs who don't share in the viewpoint that
> | reopening bugs is legitimate and should encouraged (although I agree
> | it is and should be). I base opinion that on some of the kicking and
> | screaming I've seen on bugzilla in the past. ;)
> 
> No, that kicking and screaming is reserved for when bugs are reopened
> inappropriately.

Let's not reopen old wounds. ;)

[1] http://www.groklaw.net/article.php?story=20050529095918381

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

iD8DBQFC0Z6n2QTTR4CNEQARAg/vAJ0d74aHyB1123sAmIMMxuSgxX4bKQCglP6a
ihY16+oc5BTRLudHW6PtZ3s=
=Me/f
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[Diego 'Flameeyes' Pettenò]

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

On Sunday 10 July 2005 17:32, Nathan L. Adams wrote:
> I don't see how you could prove that assumption. If you can, please do so.
You see more people ranting that bugs aren't resolved, or more people happy 
because their bugs are resolved?
I'm sorry but I can say at least for myself that most of the bugs i marked 
RESOLVED FIXED are actually resolved, a couple of them had little problems 
fixed just a bit later. When I can't be sure if a change is fixed, I usually 
use RESOLVED TEST-REQUEST (If I'm sure enough to say that is resolved) or I 
just ask the reporter to see if the bug *is* really resolved.

> There are plenty of devs who don't share in the viewpoint that reopening
> bugs is legitimate and should encouraged (although I agree it is and
> should be). I base opinion that on some of the kicking and screaming
> I've seen on bugzilla in the past. ;)
Reopening WONTFIX, CANTFIX or INVALID bugs stating that "it's a bug because I 
screwed up everything and *you* must fix that for me" is something I don't 
really like.
Reopening bugs because the fix isn't complete, or because there is still the 
same problem is fine.

What is really annoying is getting bug reopened because after one bug is fixed 
there's something else not working right, and the reporter continues on the 
same bug report.
One bug, one report. If after a fix there are still problems, open a *new* bug 
for a new issue.

-- 
Diego "Flameeyes" Pettenò
Gentoo Developer - http://dev.gentoo.org/~flameeyes/
(Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM)

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

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

[Maurice van der Pot]

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

On Sun, Jul 10, 2005 at 11:08:41AM -0400, Nathan L. Adams wrote:
> "Ideally any bug that a fix is submitted for should be verified and peer
> reviewed. It should be verified by the reporter or another user. If the
> reporter or another user are unable or unwilling to verify the fix, the
> Team Lead should take responsibility for the verification. Ideally, all
> bug fixes should be peer reviewed by the Team Lead and/or other team
> members before the bug is marked as RESOLVED. "

I think right now the situation is so far from ideal that we should not
focus too much on ideally, but rather on realistically as we do now.

The number of open bugs in Gentoo's bugzilla keeps growing. It really is
triage. And when doing triage, it's still valid to say that ideally
something would be done so and so, but you know that's never gonna
happen.

If the developer shortage was not as big as it is, we could probably
really do something with your proposition.

Regards,
Maurice.

-- 
Maurice van der Pot

Gentoo Linux Developer   griffon26@gentoo.org     http://www.gentoo.org
Creator of BiteMe!       griffon26@kfk4ever.com   http://www.kfk4ever.com


[-- Attachment #2: 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

Maurice van der Pot wrote:
> If the developer shortage was not as big as it is, we could probably
> really do something with your proposition.

Then why not lay the ground work, documentation-wise, now? Then as you
add on developers they have a nice reference on 'best practices' for
Gentoo development.

Nathan

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

iD8DBQFC0aGh2QTTR4CNEQARApwyAKCIIM6lv5fgZIH/zENJ0k63WaQKLgCglnUH
0qWsK9ByqQqyKFxvPPLvtAc=
=ZPnl
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

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

[R Hill]

Nathan L. Adams wrote:
  > I'm assuming that this would only apply to cases where the dev has
> provided a fix (in most cases I assume they would have reproduced the
> problem). The reporter's test would have the benefits mentioned above,
> and if the Team Lead tested, they could review the fix for technical
> correctness, etc.

> Again, my suggestion attempts to improve the process farther down
> stream; the problem of validating new bugs and tagging them
> appropriately is a separate matter.

Ah, okay.  You're talking about patch review.  Now this makes sense. 
I've always considered the Verified status to be indicative that a third 
party has been able to reproduce the bug, not that a fix has been 
"approved".  My mistake.

--de.

-- 
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:
> Ah, okay.  You're talking about patch review.  Now this makes sense.
> I've always considered the Verified status to be indicative that a third
> party has been able to reproduce the bug, not that a fix has been
> "approved".  My mistake.

No problem; I appreciate your input. I think Chris White's (et. al.)
recent work on the documentation is going to have a better effect on the
problem you mention.

Nathan

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

iD8DBQFC0Z832QTTR4CNEQARAlxWAJwIkswVeLsJlSfcVmcTGcjaBGAKZACghI0b
eqbYsXXyTLxJhyf8YhEH/VI=
=R/2Y
-----END PGP SIGNATURE-----
-- 
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 --]

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

[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

[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

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]

[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

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]

[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]

[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

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

[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]

[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]

[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] 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]

[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] 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]

[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] 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