[QA] To clone or not to clone ( a bug report ) that's the question...

["Jóhann B. Guðmundsson"]

When a Bug Hunter encounters the same bug in past (supported ) release, 
current release and rawhide.

Should he..

A.
     File the same bug 3 times as in once for each release?

Or

B.
     File the bug once and comment on that report that the same bug
     is present in the other release(s) as well?

Cast your opinions and vote on how you prefer it.

The majority of the outcome will decide on how Bug Hunters will be 
directed to
handle this.

JBG

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  Should he..
>  
>  A.
>       File the same bug 3 times as in once for each release?
>  
>  Or
>  
>  B.
>       File the bug once and comment on that report that the same bug
>       is present in the other release(s) as well?
>  
>  Cast your opinions and vote on how you prefer it. 
B

Doing A is a major annoyance for us packagers, it splits the discussion into
multiple threads, it floods us with even more bugmail and it brings no
benefit as we have to fix the issue in all affected releases anyway, we
should do it for all at the same time and close it once the updates are
pushed (just set any of the updates to close the bug and the others not,
they should be going out at the same time anyway - Rawhide should just get
fixed right away). I'm also very unhappy with the Security Team doing A and
think the security bug policy should be changed.

        Kevin Kofler

[Jesse Keating]

On Wed, 2009-01-21 at 21:46 +0000, "Jóhann B. Guðmundsson" wrote:
>   
>  A.
>       File the same bug 3 times as in once for each release? 
I'd prefer A.  My reasons:

  1) the same "bug" may be caused by different things in different
releases.  Not every package has the same code for the entire release
family.

  2) different sets of users care about bugs in different release trees.
Closing a bug as fixed->rawhide doesn't help the user who is hitting
this issue on say F-9.

  3) bodhi auto-closing.  Not every update gets pushed at the same time,
and closing a single bug when an F-10 update goes out doesn't help the
F-9 users know that the update for their release has gone out, or been
delayed, or just not provided.

  4) The maintainer is the right person to decide if the bugs should be
collapsed into one, rather than the triager trying to make a judgement
call.  It's easier to close->dup than to clone in the first place, if
all the above doesn't apply.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Kevin Kofler]

Jesse Keating wrote:
>    1) the same "bug" may be caused by different things in
> different
>  releases.  Not every package has the same code for the entire release
>  family. 
That's pretty rare. Even where the version differs, the bug can still be the
same. Even for Amarok 1 and 2, which are very different, there are bugs in
common with almost the same code involved (like the recently-fixed security
issue).

>    2) different sets of users care about bugs in different release
> trees.
>  Closing a bug as fixed->rawhide doesn't help the user who is hitting
>  this issue on say F-9. 
Solution: make it a policy that bugs should never be closed Rawhide unless
they only affected Rawhide. It should also be required to push bugfixes out
to at least updates-testing as soon as the bug gets fixed in Rawhide,
unless there is a really good reason not to (e.g. the fix needs a rewrite
of the whole application).

>    3) bodhi auto-closing.  Not every update gets pushed at the same
> time, 
Then that's the issue to solve.

>  and closing a single bug when an F-10 update goes out doesn't
> help the
>  F-9 users know that the update for their release has gone out, or been
>  delayed, or just not provided. 
But having the bug cloned does not solve this, requiring bugfixes to be
pushed to all supported releases at the same time (unless there's a strong
reason not to) does.

>    4) The maintainer is the right person to decide if the bugs should
> be
>  collapsed into one, rather than the triager trying to make a judgement
>  call.  It's easier to close->dup than to clone in the first place, if
>  all the above doesn't apply. 
I really don't want to have to close clones as duplicates all the time, and
triagers might even end up creating new clones if they notice there's only
one.

        Kevin Kofler

[Jesse Keating]

On Thu, 2009-01-22 at 00:39 +0100, Kevin Kofler wrote:
>  Jesse Keating wrote:
>  >   1) the same "bug" may be caused by different things in different
>  > releases.  Not every package has the same code for the entire release
>  > family.
>  
>  That's pretty rare. Even where the version differs, the bug can still be the
>  same. Even for Amarok 1 and 2, which are very different, there are bugs in
>  common with almost the same code involved (like the recently-fixed security
>  issue). 
Might be rare in your world, but isn't rare in mine.

>  >   2) different sets of users care about bugs in different
> release trees.
>  > Closing a bug as fixed->rawhide doesn't help the user who is hitting
>  > this issue on say F-9.
>  
>  Solution: make it a policy that bugs should never be closed Rawhide unless
>  they only affected Rawhide. It should also be required to push bugfixes out
>  to at least updates-testing as soon as the bug gets fixed in Rawhide,
>  unless there is a really good reason not to (e.g. the fix needs a rewrite
>  of the whole application). 
Then that just means our rawhide bug lingers open even when it may be
fixed, which throws off trackers and blockers and queries.  Not a
solution.

>  
>  >   3) bodhi auto-closing.  Not every update gets pushed at the same time,
>  
>  Then that's the issue to solve. 
Right, and how do you propose we "solve" this (not that I agree that
this is a problem)?

>  
>  > and closing a single bug when an F-10 update goes out doesn't help the
>  > F-9 users know that the update for their release has gone out, or been
>  > delayed, or just not provided.
>  
>  But having the bug cloned does not solve this, requiring bugfixes to be
>  pushed to all supported releases at the same time (unless there's a strong
>  reason not to) does. 
At the same time doesn't work.  What if your attempted fix on F-9 fails,
but the fix on F-10 succeeds?  Should the F-10 build sit in
updates-testing until the say that F-9 works?  F-10 users just suffer
for the sake of having the push go at the same time?  Ridiculous.

>  
>  >   4) The maintainer is the right person to decide if the bugs should be
>  > collapsed into one, rather than the triager trying to make a judgement
>  > call.  It's easier to close->dup than to clone in the first place, if
>  > all the above doesn't apply.
>  
>  I really don't want to have to close clones as duplicates all the time, and
>  triagers might even end up creating new clones if they notice there's only
>  one. 
You can always opt out of having triagers touch KDE bugs.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating

[Kevin Kofler]

Jesse Keating wrote:
>  Then that just means our rawhide bug lingers open even when it may
> be
>  fixed, which throws off trackers and blockers and queries.  Not a
>  solution. 
Then push the fix out to releases sooner, maybe even directly to stable if
it's important enough to be on the tracker for the next release. Why would
it be so important as to block the next release and not worth being fixed
in the current one ASAP (unless the current one is not affected at all,
which is exactly when you'd use CLOSED RAWHIDE)?

> > >   3) bodhi auto-closing.  Not every update gets pushed at
> the same
> > >   time,
> > 
> > Then that's the issue to solve.
>  
>  Right, and how do you propose we "solve" this (not that I agree that
>  this is a problem)? 
By pushing the updates out to the releases at the same time.

>  At the same time doesn't work.  What if your attempted fix on F-9
> fails,
>  but the fix on F-10 succeeds?  Should the F-10 build sit in
>  updates-testing until the say that F-9 works?  F-10 users just suffer
>  for the sake of having the push go at the same time?  Ridiculous. 
Well, in the cases I've seen, we just used the same fix everywhere, so I
don't see why it would work in one release and not the other. Generally, I
just wait for the first positive feedback on any release or for a week or
two without negative feedback and then push it to stable on all releases.
Waiting for feedback on all releases is a lost cause (except for some
packages like the kernel, but feedback there generally gets ignored
altogether), we already have to be happy to get any feedback at all. Having
bugfixes stalled in testing for ages doesn't help anyone.

>  You can always opt out of having triagers touch KDE bugs. 
Well, our KDE triager is doing good work and is also working with KDE SIG,
so I'm sure we can have him follow KDE-specific policies and the other
triagers rarely ever touch KDE bugs. But I'd rather policies weren't
radically different across components. Inconsistencies confuse everyone.
For example, not everything I maintain or comaintain is a KDE package.
Reporters, triagers and maintainers will be working with packages from
unfamiliar components occasionally, differing policies will confuse them
pretty quickly. That's why I think consistency is important (and also why
I'm complaining about the security team following a policy to clone bugs
for each release when almost nobody else is doing that).

        Kevin Kofler

[Jesse Keating]

On Thu, 2009-01-22 at 13:08 +0100, Kevin Kofler wrote:
>  Jesse Keating wrote:
>  > Then that just means our rawhide bug lingers open even when it may be
>  > fixed, which throws off trackers and blockers and queries.  Not a
>  > solution.
>  
>  Then push the fix out to releases sooner, maybe even directly to stable if
>  it's important enough to be on the tracker for the next release. Why would
>  it be so important as to block the next release and not worth being fixed
>  in the current one ASAP (unless the current one is not affected at all,
>  which is exactly when you'd use CLOSED RAWHIDE)? 
Again because the fix for rawhide vs a release tree may be different, as
the versions are different.  Also the fix needs to be in -testing on the
release tree to make sure that the fix integrates well with the other
software, whereas it needs to go out in rawhide immediately.  I really
think you're stuck in the mindset of same software on every branch,
which just isn't and shouldn't be the case for everybody.

>  
>  >> >   3) bodhi auto-closing.  Not every update gets pushed at the same
>  >> >   time,
>  >> 
>  >> Then that's the issue to solve.
>  > 
>  > Right, and how do you propose we "solve" this (not that I agree that
>  > this is a problem)?
>  
>  By pushing the updates out to the releases at the same time. 
Gee it's so simple.  The hat goes on the head! </sarcasm>

>  
>  > At the same time doesn't work.  What if your attempted fix on F-9 fails,
>  > but the fix on F-10 succeeds?  Should the F-10 build sit in
>  > updates-testing until the say that F-9 works?  F-10 users just suffer
>  > for the sake of having the push go at the same time?  Ridiculous.
>  
>  Well, in the cases I've seen, we just used the same fix everywhere, so I
>  don't see why it would work in one release and not the other. 
Because for a lot of people, software is /different/ on one release vs
the other.  Particularly software that is used by lots of other things.

>   Generally, I
>  just wait for the first positive feedback on any release or for a week or
>  two without negative feedback and then push it to stable on all releases.
>  Waiting for feedback on all releases is a lost cause (except for some
>  packages like the kernel, but feedback there generally gets ignored
>  altogether), we already have to be happy to get any feedback at all. Having
>  bugfixes stalled in testing for ages doesn't help anyone.
>  
>  > You can always opt out of having triagers touch KDE bugs.
>  
>  Well, our KDE triager is doing good work and is also working with KDE SIG,
>  so I'm sure we can have him follow KDE-specific policies and the other
>  triagers rarely ever touch KDE bugs. But I'd rather policies weren't
>  radically different across components. Inconsistencies confuse everyone.
>  For example, not everything I maintain or comaintain is a KDE package.
>  Reporters, triagers and maintainers will be working with packages from
>  unfamiliar components occasionally, differing policies will confuse them
>  pretty quickly. That's why I think consistency is important (and also why
>  I'm complaining about the security team following a policy to clone bugs
>  for each release when almost nobody else is doing that).
>  
>          Kevin Kofler
>   
-- 
Jesse Keating RHCE      (http://jkeating.livejournal.com)
Fedora Project          (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca               (http://identi.ca/jkeating)

[Bill Nottingham]

Kevin Kofler (kevin.kofler(a)chello.at) said: 
>  >   2) different sets of users care about bugs in different
> release trees.
>  > Closing a bug as fixed->rawhide doesn't help the user who is hitting
>  > this issue on say F-9.
>  
>  Solution: make it a policy that bugs should never be closed Rawhide unless
>  they only affected Rawhide. It should also be required to push bugfixes out
>  to at least updates-testing as soon as the bug gets fixed in Rawhide,
>  unless there is a really good reason not to (e.g. the fix needs a rewrite
>  of the whole application). 
For any bug that's filed? Wow, and people thought we did a lot of
updates *now*.

Bill

[Kevin Kofler]

Bill Nottingham wrote:
>  For any bug that's filed? Wow, and people thought we did a lot
> of
>  updates *now*. 
Well, if it's something like "please update Summary/Description/URL", then
really nobody cares when it gets fixed in a release, so it can be closed as
RAWHIDE and I don't see why we would bother tracking when if ever it gets
fixed in existing releases. But if it's a real issue, I don't see why it
shouldn't get fixed in releases ASAP.

        Kevin Kofler

[Kevin Fenzi]

On Wed, 21 Jan 2009 21:46:48 +0000
"Jóhann B. Guðmundsson" <johannbg(a)hi.is&gt; wrote:

>  When a Bug Hunter encounters the same bug in past (supported )
>  release, current release and rawhide.
>  
>  Should he..
>  
>  A.
>       File the same bug 3 times as in once for each release?
>  
>  Or
>  
>  B.
>       File the bug once and comment on that report that the same bug
>       is present in the other release(s) as well? 
I prefer B. If it becomes obvious to the maintainer that they need to
separate things out, they can clone the bug then. If their work flow
works best doing that then they can, without forcing more bugs on them
if it does not. 

I personally ask submitters when they say it's affecting more releases
or if they report against f10: "Do you think this warrants an update?
Will you test it for me on that release?"

Sometimes they say "no, I just wanted it fixed, fix it in rawhide and I
will get it the next time there is a reason to update stable releases"
and sometimes they want/need it fixed in the release they are seeing it
in. 

>  Cast your opinions and vote on how you prefer it. 
I don't think voting is a good idea. 
I think we should try and come to a consensus on what will help our
maintainers and triagers and reporters handle bugs.

>  The majority of the outcome will decide on how Bug Hunters will be 
>  directed to
>  handle this. 
I don't think a poll on the devel list should be used for this... 
Can't we agree on whats least disruptive and use that?

>  JBG 
kevin

[Mamoru Tasaka]

Jóhann B. Guðmundsson wrote, at 01/22/2009 06:46 AM +9:00:
>  When a Bug Hunter encounters the same bug in past (supported )
> release, 
>  current release and rawhide.
>  
>  Should he..
>  
>  A.
>      File the same bug 3 times as in once for each release?
>  
>  Or
>  
>  B.
>      File the bug once and comment on that report that the same bug
>      is present in the other release(s) as well?
>  
>  Cast your opinions and vote on how you prefer it.
>  
>  The majority of the outcome will decide on how Bug Hunters will be 
>  directed to
>  handle this.
>  
>  JBG 
Just FYI this topic once brought up one year ago:
http://www.redhat.com/archives/fedora-devel-list/2008-January/msg02836.html

Mamoru

["Jóhann B. Guðmundsson"]

Mamoru Tasaka wrote:
>  Jóhann B. Guðmundsson wrote, at 01/22/2009 06:46 AM +9:00:
> > When a Bug Hunter encounters the same bug in past (supported ) 
> > release, current release and rawhide.
> >
> > Should he..
> >
> > A.
> >     File the same bug 3 times as in once for each release?
> >
> > Or
> >
> > B.
> >     File the bug once and comment on that report that the same bug
> >     is present in the other release(s) as well?
> >
> > Cast your opinions and vote on how you prefer it.
> >
> > The majority of the outcome will decide on how Bug Hunters will be 
> > directed to
> > handle this.
> >
> > JBG
>
>  Just FYI this topic once brought up one year ago:
>  http://www.redhat.com/archives/fedora-devel-list/2008-January/msg02836.html 
>
>
>  Mamoru
>  
I can see were this is heading and I honestly did not think that this 
could be that complicated.

FYI this is neither about Bodhi nor Triaging nor will the outcome of 
this just stay in a thread on
a mailing list.

This is about if a TESTER aka "Bug Hunter" shall report the bug
he came across ONCE and comment on that report if he comes accross the 
same bug
in another release.

OR

If he should file another separate report describing the exact same bug 
for that release.

This subject WILL be a topic on the next QA meeting and votes counted 
and a FINAL decision be made.

The decision that is made on that meeting WILL end up in testers guide 
and be mentioned on the QA TESTERS page.

YOU as a maintainer or developer of a component have a week to choose 
either A or B and express your opinion on that chose.

There will be an option where YOU can add your component as an exception 
to that final outcome on that TESTERS page.

YOU could perhaps ask the triage team to handle reports against YOUR 
component differently then the outcome of final decision
but that's something the triage team have to decide if they will offer 
that service to a maintainer or a developer.

Please take your time and participate in the voting so we can get as 
accurate result
A result that express the will of the ( majority of the ) community.

Thank you for your time.

JBG

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  This subject WILL be a topic on the next QA meeting and votes counted
>
>  and a FINAL decision be made. 
I don't think this arrogant attitude is helping anyone, no matter what
option ends up chosen. I don't see why the decision has to be rushed nor
why a QA team vote would be the right way to decide about this issue (it
affects packagers at least as much as QA and triage folks).

        Kevin Kofler

["Jóhann B. Guðmundsson"]

Kevin Kofler wrote:
>  "Jóhann B. Guðmundsson" wrote:
>    
> > This subject WILL be a topic on the next QA meeting and votes counted 
> > and a FINAL decision be made.
> >     
>
>  I don't think this arrogant attitude is helping anyone, no matter what
>  option ends up chosen. I don't see why the decision has to be rushed nor
>  why a QA team vote would be the right way to decide about this issue (it
>  affects packagers at least as much as QA and triage folks).
>
>          Kevin Kofler
>
>     
It's the packager/maintainer/developer and only them that make this 
decision.

If maintainer decides not to participate and then finds him disliking 
the end result
then he got nobody else to blame but him self.

This outcome of this will affect how testers are guided on how to report 
bugs
and will be in section under Reporting Bugs.

This is done to improve overall quality of bug reporting.

You got to excuse me if you and others feel that I'm being arrogant
or harsh but i'm not doing this to win popularity contents or beauty 
patents!

I'm doing this to improve overall quality of the bug reporting.

I'm not about to let this thread take 180 degree turn and the focus on 
the actual topic
be lost as so happens to many others topics on this list.

If you and other maintainers feel that week is to little to vote and 
discuss this matter please express
that along with how much time you think it takes to come to a final 
conclusion.

JBG

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  It's the packager/maintainer/developer and only them that make
> this
>  decision. 
Then the decision should be made through a channel of
packagers/maintainers/developers (or maybe their representatives, i.e.
FESCo), not in a QA meeting!

>  If maintainer decides not to participate and then finds him
> disliking
>  the end result then he got nobody else to blame but him self. 
If you want maintainers to take the decision, a QA meeting is the wrong
venue.

        Kevin Kofler

["Jóhann B. Guðmundsson"]

Kevin Kofler wrote:
>  "Jóhann B. Guðmundsson" wrote:
>    
> > It's the packager/maintainer/developer and only them that make this
> > decision.
> >     
>
>  Then the decision should be made through a channel of
>  packagers/maintainers/developers (or maybe their representatives, i.e.
>  FESCo), not in a QA meeting!
>
>    
> > If maintainer decides not to participate and then finds him disliking
> > the end result then he got nobody else to blame but him self.
> >     
>
>  If you want maintainers to take the decision, a QA meeting is the wrong
>  venue.
>
>          Kevin Kofler
>
>     
If you and others think this decision should be in the hand of FESCo 
instead of QA
then I would like FESCo to add this topic to their next meeting agenda 
and I truly
hope they can reach a satisfying result.

The QA meeting topic as I see it was just about counting the votes on 
the thread
and make that an official decision.

I also see that asking the maintainers for what they wanted was an error 
on my behalf.

Testers need training guidelines and policies to work by, a proper "work 
flow" and if the
responses to every matter are going to be like this one I simply cut out 
the inefficient process.

I will write those guidelines policy and provide testers with a decent 
work flow.

Anyone that opposes anything in that guideline can than pick out 
questionable issues , make them to a topic on this
list or ask FESCo to address those issue(s) in their meetings.

There will be no time "pressure" matter since the guideline has already 
been written and made
so debates can be stuck in infinite loop until the storage space on the 
mail server fills up..

When and if an actually satisfying result comes out of it, a person can 
simply log into the wiki and adjust the
the guidelines to that result..

With this approach testers will at least have something in their hand to 
work with
which will indeed improve the overall process of bug reporting.

Thank you for your time.

JBG

/*JFDI to da bone.. */

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  Testers need training guidelines and policies to work by, a proper
> "work
>  flow" and if the responses to every matter are going to be like this one I
>  simply cut out the inefficient process. 
The "inefficient process" is required to achieve a solution which actually
SATISFIES everybody rather than somebody's arbitrary decision.

>  I will write those guidelines policy and provide testers with a
> decent
>  work flow. 
With what authority?

>  Anyone that opposes anything in that guideline can than pick out
>  questionable issues , make them to a topic on this list or ask FESCo to
>  address those issue(s) in their meetings. 
In fact I ask this to be escalated to FESCo right NOW and to get a clear
statement that you aren't allowed to unilaterally decide on a policy for
the entire project. This is not Guðmundssonix, it's Fedora!

>  There will be no time "pressure" matter since the guideline
> has already
>  been written and made 
With what authority?

        Kevin Kofler

["Jóhann B. Guðmundsson"]

Kevin Kofler wrote:
>  "Jóhann B. Guðmundsson" wrote:
>    
> > Testers need training guidelines and policies to work by, a proper "work
> > flow" and if the responses to every matter are going to be like this one I
> > simply cut out the inefficient process.
> >     
>
>  The "inefficient process" is required to achieve a solution which actually
>  SATISFIES everybody rather than somebody's arbitrary decision.
>
>     
A solution to this has been proposed and been added here 
https://fedorahosted.org/fedora-qa/ticket/5
> > I will write those guidelines policy and provide testers with a
> decent
> > work flow.
> >     
>
>  With what authority?
>     
With mine and QA authority and let's time I checked I had the free will 
to write whatever I felt like
under my space on the wiki which I have I done ..

For example the new QA wiki page this as been approved on the QA meeting.

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA

Here's a suggestion for components layout on the QA Namespace and yes 
this means
that there will be a similar page that needs to be created for each 
component in Fedora

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA/file-roller

Here's another one  ( This one waits Haralds approval )

https://fedoraproject.org/wiki/User:Johannbg/Draft/QA/Test_Days/Features/...

Here you can see I layout I suggested for Gnome Desktop

http://fedoraproject.org/wiki/Desktop/Testing

And more on the way..

We might even rewrite things to be coming more closer to what's being 
done on ltp.sf.net

>    
> > Anyone that opposes anything in that guideline can than pick out
> > questionable issues , make them to a topic on this list or ask FESCo to
> > address those issue(s) in their meetings.
> >     
>
>  In fact I ask this to be escalated to FESCo right NOW and to get a clear
>  statement that you aren't allowed to unilaterally decide on a policy for
>  the entire project. This is not Guðmundssonix, it's Fedora!
>
>     
Since when did I say that that I was Fedora?

> > There will be no time "pressure" matter since the
> guideline has already
> > been written and made
> >     
>
>  With what authority?
>
>     
See above.

Dont worry you can bother yourself with writing your own proper 
testing/test pages for your own components.

Looking forward to see them.

JBG

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  Dont worry you can bother yourself with writing your own proper
>  testing/test pages for your own components.
>  
>  Looking forward to see them. 
I just proposed a competing arbitrary policy in your QA ticket:
https://fedorahosted.org/fedora-qa/ticket/5

It's easy to write up an arbitrary policy without asking anyone, even easier
to copy somebody else's as you did (and while this does mean at least 2
people are supporting the policy, that's not a consensus). But that's not
how decisions are made in a community project.

        Kevin Kofler

["Jóhann B. Guðmundsson"]

Kevin Kofler wrote:
>  "Jóhann B. Guðmundsson" wrote:
>    
> > Dont worry you can bother yourself with writing your own proper
> > testing/test pages for your own components.
> >
> > Looking forward to see them.
> >     
>
>  I just proposed a competing arbitrary policy in your QA ticket:
>  https://fedorahosted.org/fedora-qa/ticket/5
>
>  It's easy to write up an arbitrary policy without asking anyone, even easier
>  to copy somebody else's as you did (and while this does mean at least 2
>  people are supporting the policy, that's not a consensus). But that's not
>  how decisions are made in a community project.
>
>          Kevin Kofler
>
>     
Please dont mix testers with triagers these are 2 separated teams.

It would be good if you could spend some time of your writing energy
writing testing/ test cases for your components and how you would like
testers to report to components that you maintain.

And of course I copied Mark suggestion it's a dam good one but that does 
not mean
that it will be the one that makes into the final chapter.

And so far I have not published anything without it being approved 
first  either on a QA meeting
or by the maintainer giving his blessing on testing/test cases that it's 
like he wants it.

And I offer my service to those maintainers that dont have the time to 
write theirs and gladly accept my
aid in that matter.

JBG

[Kevin Kofler]

"Jóhann B. Guðmundsson" wrote:
>  Please dont mix testers with triagers these are 2 separated teams.
But if one of the teams is not expected to clone bugs, then neither is the
other. :-) So this policy is equally relevant to both teams.

And there are activities which are really both testing and triaging, like
retesting if a bug still applies, at least at KDE upstream this is
something the triagers do. Is there already a policy who's responsible for
such activity? If not, I'd suggest you go talking to the triagers about it.
(Right now, I don't see any such retesting going on, so I get the (possibly
mistaken) impression that each team is expecting the other to do it. ;-) )

>  It would be good if you could spend some time of your writing energy
>  writing testing/ test cases for your components and how you would like
>  testers to report to components that you maintain. 
If I start writing test cases for KDE, I'll never finish... Canned test
plans just don't work for huge GUI apps with many features, unless you have
a specific feature you want to test (e.g. to verify whether a given bug is
fixed).

>  And so far I have not published anything without it being approved
>  first  either on a QA meeting
>  or by the maintainer giving his blessing on testing/test cases that it's
>  like he wants it. 
The problem is that the way to handle bug reports is something which affects
packagers and triagers much more than it affects testers. You just file the
bug(s), the packagers and triagers will have to deal with them. So a tester
meeting is a bad place to decide on such a policy.

In addition, a statement like "There will be no time "pressure" matter
since
the guideline has already been written and made so debates can be stuck in
infinite loop until the storage space on the mail server fills up.." makes
you sound totalitarian. Maybe I should give you the benefit of the doubt
and assume something got lost in translation?

        Kevin Kofler

[Mark McLoughlin]

On Fri, 2009-01-23 at 04:38 +0100, Kevin Kofler wrote:

>  Maybe I should give you the benefit of the doubt and assume
> something
>  got lost in translation? 
That's always a good idea :-)

GNOME's "code of conduct" spells out some common sense that can be easy
to forget in the middle of a debate:

  http://live.gnome.org/CodeOfConduct

  Be respectful and considerate: 
    Disagreement is no excuse for poor behaviour or personal attacks.
    Remember that a community where people feel uncomfortable is not a
    productive one.

  Be patient and generous: 
    If someone asks for help it is because they need it. Do politely
    suggest specific documentation or more appropriate venues where
    appropriate, but avoid aggressive or vague responses such as
    "RTFM". 

  Assume people mean well: 
    Remember that decisions are often a difficult choice between
    competing priorities. If you disagree, please do so politely. If
    something seems outrageous, check that you did not misinterpret it.
    Ask for clarification, but do not assume the worst.

  Try to be concise: 
    Avoid repeating what has been said already. Making a conversation
    larger makes it difficult to follow, and people often feel
    personally attacked if they receive multiple messages telling them
    the same thing. 

(Not suggesting that we need to go through this process of writing a
code, debating it endlessly and getting people to sign up for it - but
it is a nice set of guidelines)

Cheers,
Mark.

["Jóhann B. Guðmundsson"]

Kevin Kofler wrote:
>  "Jóhann B. Guðmundsson" wrote:
>    
> > Please dont mix testers with triagers these are 2 separated teams.
> >     
>
>  But if one of the teams is not expected to clone bugs, then neither is the
>  other. :-) So this policy is equally relevant to both teams.
>
>     
There are exceptions to every rule :)

But indeed in most cases the same applies and from my perspective
more to testers than to triagers.

Testers need to report as correctly and add correct attachments and so
on from the start.

If that goal is accomplished it should really take load off both
triagers and maintainers.

But to reach that goal we need documentation, train testers.

We need test cases and above all what the maintainer wants on a reports 
against his component.

Unfortunately we have little to nothing on the above :(

I and others are trying to address that issue.

>  And there are activities which are really both testing and triaging,
> like
>  retesting if a bug still applies, at least at KDE upstream this is
>  something the triagers do. Is there already a policy who's responsible for
>  such activity? If not, I'd suggest you go talking to the triagers about it.
>  (Right now, I don't see any such retesting going on, so I get the (possibly
>  mistaken) impression that each team is expecting the other to do it. ;-) )
>
>     
Retesting from my perspective should be in the hand of A) the reporter 
and B) Testers

If maintainers need testing send a mail to the test-list.

If you need test cases or help setting up or anything else from QA
open a ticket in the new fedora-qa trac instance on fedorahosted.

> > It would be good if you could spend some time of your writing
> energy
> > writing testing/ test cases for your components and how you would like
> > testers to report to components that you maintain.
> >     
>
>  If I start writing test cases for KDE, I'll never finish... Canned test
>  plans just don't work for huge GUI apps with many features, unless you have
>  a specific feature you want to test (e.g. to verify whether a given bug is
>  fixed).
>
>     
I disagree I think this is doable, we need to come up with template for 
the most common
nominators in the gui app ( open new save help etc..  ) then just add 
test cases for those
that are not.
> > And so far I have not published anything without it being
> approved
> > first  either on a QA meeting
> > or by the maintainer giving his blessing on testing/test cases that it's
> > like he wants it.
> >     
>
>  The problem is that the way to handle bug reports is something which affects
>  packagers and triagers much more than it affects testers. You just file the
>  bug(s), the packagers and triagers will have to deal with them. So a tester
>  meeting is a bad place to decide on such a policy.
>
>     
Again if the report does this properly from start the need of triaging 
should be to minimum.
>  In addition, a statement like "There will be no time
> "pressure" matter since
>  the guideline has already been written and made so debates can be stuck in
>  infinite loop until the storage space on the mail server fills up.." makes
>  you sound totalitarian. Maybe I should give you the benefit of the doubt
>  and assume something got lost in translation?
>     
My good man your not asking the right question and you don't get answers 
to question you don't ask.

You should be asking me why do I feel that the -devel list is an
inefficient way to use for communication/intellect discussion 
invention's and finally a decision making.

I'll try to be more subtle this time and explain in more detail what I 
mean..

I feel that way because a lot of topics here are..

A) The same ones over and over again and finally when things have settle 
down we make a release and
     since there was no solution found or that solution/decision not 
properly documented and put on a page on the wiki
     the whole thing starts again.

B) A lot of topic start as A but end up as Y or Z so the original topic 
got lost and the answer to
     that topic still remains unresolved..
     ( that's why you saw me being so harsh I sensed it start heading in 
that direction )

C)  A lot of great ideas ( and not so great ) come up on this list are 
we documenting them
      For example are we putting them on think tank page on the wiki? 
      So they can be revisited when time or manpower are in place to 
work on some of those ideas
      I believe we are not doing it and I feel that they just get lost 
and buried in the paper flood.

D) Allot of the discussion that happens here are without people 
proposing alternative solution a different approach
     to the task at hand but instead you see people start taking sides 
and the debate continues and the task at stays stale.
     ( And in this case Mark did come with an alternative answer to the 
questions being asked and so did you later in the game )

D) A lot of topic here do no belong on this list and should redirected 
to their appropriate mailing lists
     Redirect end users topic to their list, test related topics to the 
test list etc..

And the answer to all this boils down to things being as they are 
because we allowed them to be.

Instead of redirect traffic to they appropriate mailing list...
Instead of taking notes when good solution come..
Instead of when the same topic reappear the person that brought up that 
topic is redirect to the place that holds the final solution that was 
found..
.....
....

So my question is..

Are we doing any stats on the traffic on this mailing list as in how 
many threads are constructive and how many reach final decision vs
how many end up in "my side is better than yours" and traffic that 
should be else where etc.. ?

So the conclusion that I have come to regarding this mailing list can be 
proven wrong...

JBG

[Jon Stanley]

On Thu, Jan 22, 2009 at 5:28 PM, Kevin Kofler <kevin.kofler(a)chello.at&gt; wrote:

>  In fact I ask this to be escalated to FESCo right NOW and to get a
> clear
>  statement that you aren't allowed to unilaterally decide on a policy for
>  the entire project. This is not Guðmundssonix, it's Fedora! 
So Kevin withdrew his complaint to FESCo, but I felt like I should
still chime in here (and if the larger FESCo needs/wants to discuss
this, I'm all in favor of that).  When I started the triage process ~1
year ago, since it would affect ALL maintainers, I took it to FESCo
since that seemed the right thing to do. I still believe that any
proposal that affects maintainer workflow needs FESCo review. We
review all of the packaging guidelines that are prepared by the FPC
prior to their adoption, for example.

So if you're looking to change something, I'd take it to FESCo for approval.

[Mamoru Tasaka]

Jóhann B. Guðmundsson wrote, at 01/22/2009 09:23 PM +9:00:
>  This subject WILL be a topic on the next QA meeting and votes counted
>
>  and a FINAL decision be made. 
.....

Please see:
http://fedoraproject.org/wiki/Communicate/MailingListGuidelines#Do_not_us...

Anyway as I wrote one year ago,
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg02841.html
I don't think filing the same bug for each branch is needed.

Mamoru

[Mark McLoughlin]

Hi Jóhann,

On Thu, 2009-01-22 at 12:23 +0000, "Jóhann B. Guðmundsson" wrote:
>  Mamoru Tasaka wrote:
>  > Jóhann B. Guðmundsson wrote, at 01/22/2009 06:46 AM +9:00:
>  >> When a Bug Hunter encounters the same bug in past (supported ) 
>  >> release, current release and rawhide.
>  >>
>  >> Should he..
>  >>
>  >> A.
>  >>     File the same bug 3 times as in once for each release?
>  >>
>  >> Or
>  >>
>  >> B.
>  >>     File the bug once and comment on that report that the same bug
>  >>     is present in the other release(s) as well? 
I think a sensible policy is:

  1) File the bug against the version you have tested with

  2) If this version is not rawhide, there is generally no need to also
     file a bug against rawhide. Maintainers should always check 
     whether the bug is fixed in rawhide. Commenting whether you 
     believe the bug exists in rawhide is always useful.

  3) If you think this is a critical bug and have checked that it 
     exists other released versions, then you should clone the bug for 
     those other versions.

  4) Otherwise, just comment on the impact to other versions and let 
     the maintainer decide whether cloning the bug is appropriate.

No, it's not a black/white policy. It requires a little bit of common
sense. But that's okay, right?

>  This subject WILL be a topic on the next QA meeting and votes counted
>
>  and a FINAL decision be made.
>  
>  The decision that is made on that meeting WILL end up in testers guide 
>  and be mentioned on the QA TESTERS page.
>  
>  YOU as a maintainer or developer of a component have a week to choose 
>  either A or B and express your opinion on that chose. 
Voting sucks, rough consensus is preferable.

>  There will be an option where YOU can add your component as an
> exception 
>  to that final outcome on that TESTERS page. 
(B) is pretty much the status quo; if this voting thing means that (A)
is chosen and the triage team starts cloning a bunch of bugs, you can be
sure you'll have maintainers who haven't read or replied to this thread
waking up and getting annoyed that they've 3x bug reports to deal
with :-)

Cheers,
Mark.

[Daniel P. Berrange]

On Thu, Jan 22, 2009 at 03:27:19PM +0000, Mark McLoughlin wrote:
>  Hi Jóhann,
>  
>  On Thu, 2009-01-22 at 12:23 +0000, "Jóhann B. Guðmundsson" wrote:
>  > Mamoru Tasaka wrote:
>  > > Jóhann B. Guðmundsson wrote, at 01/22/2009 06:46 AM +9:00:
>  > >> When a Bug Hunter encounters the same bug in past (supported ) 
>  > >> release, current release and rawhide.
>  > >>
>  > >> Should he..
>  > >>
>  > >> A.
>  > >>     File the same bug 3 times as in once for each release?
>  > >>
>  > >> Or
>  > >>
>  > >> B.
>  > >>     File the bug once and comment on that report that the same bug
>  > >>     is present in the other release(s) as well?
>  
>  I think a sensible policy is:
>  
>    1) File the bug against the version you have tested with
>  
>    2) If this version is not rawhide, there is generally no need to also
>       file a bug against rawhide. Maintainers should always check 
>       whether the bug is fixed in rawhide. Commenting whether you 
>       believe the bug exists in rawhide is always useful.
>  
>    3) If you think this is a critical bug and have checked that it 
>       exists other released versions, then you should clone the bug for 
>       those other versions.
>  
>    4) Otherwise, just comment on the impact to other versions and let 
>       the maintainer decide whether cloning the bug is appropriate.
>  
>  No, it's not a black/white policy. It requires a little bit of common
>  sense. But that's okay, right? 
I agree - common sense is the most important thing - there are plenty
of scenarios where cloning makes sense - and also plenty of scenarios
where it is just creating alot of extra work for no gain. So mandating
either of those two options is sub-optimal. Flexible guidelines are 
preferable to hard rules.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

["Jóhann B. Guðmundsson"]

Mark McLoughlin wrote:

<snip>
.....
<snip>
>  I think a sensible policy is:
>
>    1) File the bug against the version you have tested with
>
>    2) If this version is not rawhide, there is generally no need to also
>       file a bug against rawhide. Maintainers should always check 
>       whether the bug is fixed in rawhide. Commenting whether you 
>       believe the bug exists in rawhide is always useful.
>
>    3) If you think this is a critical bug and have checked that it 
>       exists other released versions, then you should clone the bug for 
>       those other versions.
>
>    4) Otherwise, just comment on the impact to other versions and let 
>       the maintainer decide whether cloning the bug is appropriate.
>     
I do believe you nailed this one Mark :)

+1
>  No, it's not a black/white policy. It requires a little bit of
> common
>  sense. But that's okay, right?
>
>     
Of course not and alternative, different approaches,
better suggestions/solution are always welcome.

JBG