An interesting read when discussing what to do about our bugs...

[Jesse Keating]

http://glyphobet.net/blog/?p=140

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jon Ciesla]

>  http://glyphobet.net/blog/?p=140 
Why would any maintainer NOT ask to see the fstab, but still blame it for
the problem?  Now, I've only RTFA and not RTFB, but that's just crap
troubleshooting.  I supervise a help desk and I don't let that sort of
thing slide here, and I sure as . . .something certain. . .wouldn't put up
with in a bug report.

Why not just chase the bug down, and follow the evidence where it leads?

>  --
>  Jesse Keating
>  Fedora -- All my bits are free, are yours?
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list 

-- 
novus ordo absurdum

[Benjamin Kreuter]

I've had a similar experience with Ubuntu guys -- they are not interested in 
discussing any serious problems with their distro.  There was an STNYLug 
meeting at my school a few months back, and is was led by a Canonical 
employee.  He wanted us to think up a list of Linux pros and cons -- but when 
I suggested that packages breaking between major releases was a con, I was 
completely shot down by him.  He didn't even want to discuss it.  Some other 
Ubuntu contributors in the room acted like it wasn't really a problem because 
other systems suffer from it as well.

I walked out...

-- Benjamin Kreuter

[nodata]

Am Freitag, den 18.01.2008, 13:36 -0500 schrieb Benjamin Kreuter:
>  I've had a similar experience with Ubuntu guys -- they are not
>  interested in 
>  discussing any serious problems with their distro.  There was an
>  STNYLug 
>  meeting at my school a few months back, and is was led by a Canonical 
>  employee.  He wanted us to think up a list of Linux pros and cons --
>  but when 
>  I suggested that packages breaking between major releases was a con, I
>  was 
>  completely shot down by him.  He didn't even want to discuss it.  Some
>  other 
>  Ubuntu contributors in the room acted like it wasn't really a problem
>  because 
>  other systems suffer from it as well.
>  
>  I walked out...
>  
>  -- Benjamin Kreuter 
Apart from security bugs, I have never had a bug fixed in Ubuntu, ever.
The tactic seems to be to wait until Debian fix it, or wait until Debian
fix it and then ask you to upgrade to the next release.

Fedora does a lot better, much better, but probably the most annoying
aspect of using Fedora's bugzilla is the attitude of some of the
maintainers (not all) and the "closing, report upstream" attitude.

Closing a bug report with "report it upstream" is a let down. It's
repetitive boring work that a computer should be doing.

It takes a lot of effort to report a bug, and by this I mean that I know
a *lot* of people who find a bug, and maybe a fix, but don't bug report
it. They should be, but I can see why they don't.

[Seth Vidal]

On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:

>  Apart from security bugs, I have never had a bug fixed in Ubuntu,
> ever.
>  The tactic seems to be to wait until Debian fix it, or wait until Debian
>  fix it and then ask you to upgrade to the next release.
>  
>  Fedora does a lot better, much better, but probably the most annoying
>  aspect of using Fedora's bugzilla is the attitude of some of the
>  maintainers (not all) and the "closing, report upstream" attitude.
>  
>  Closing a bug report with "report it upstream" is a let down. It's
>  repetitive boring work that a computer should be doing.
>  
>  It takes a lot of effort to report a bug, and by this I mean that I know
>  a *lot* of people who find a bug, and maybe a fix, but don't bug report
>  it. They should be, but I can see why they don't. 
Hmm, is that what the 'upstream' close reason is for? Normally, I close
things 'upstream' when I have checked a fix into the upstream code base.
Which seems pretty reasonable time to close it to me.

-sv

[nodata]

Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal:
>  On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:
>  
>  > Apart from security bugs, I have never had a bug fixed in Ubuntu, ever.
>  > The tactic seems to be to wait until Debian fix it, or wait until Debian
>  > fix it and then ask you to upgrade to the next release.
>  > 
>  > Fedora does a lot better, much better, but probably the most annoying
>  > aspect of using Fedora's bugzilla is the attitude of some of the
>  > maintainers (not all) and the "closing, report upstream" attitude.
>  > 
>  > Closing a bug report with "report it upstream" is a let down. It's
>  > repetitive boring work that a computer should be doing.
>  > 
>  > It takes a lot of effort to report a bug, and by this I mean that I know
>  > a *lot* of people who find a bug, and maybe a fix, but don't bug report
>  > it. They should be, but I can see why they don't.
>  
>  Hmm, is that what the 'upstream' close reason is for? Normally, I close
>  things 'upstream' when I have checked a fix into the upstream code base.
>  Which seems pretty reasonable time to close it to me.
>  
>  -sv
>   
I'm talking about closing the bug and telling the reporter to report
upstream, i.e. "go away".

[Hans de Goede]

nodata wrote:
>  Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal:
> > On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:
> >
> >> Apart from security bugs, I have never had a bug fixed in Ubuntu, ever.
> >> The tactic seems to be to wait until Debian fix it, or wait until Debian
> >> fix it and then ask you to upgrade to the next release.
> >>
> >> Fedora does a lot better, much better, but probably the most annoying
> >> aspect of using Fedora's bugzilla is the attitude of some of the
> >> maintainers (not all) and the "closing, report upstream" attitude.
> >>
> >> Closing a bug report with "report it upstream" is a let down. It's
> >> repetitive boring work that a computer should be doing.
> >>
> >> It takes a lot of effort to report a bug, and by this I mean that I know
> >> a *lot* of people who find a bug, and maybe a fix, but don't bug report
> >> it. They should be, but I can see why they don't.
> > Hmm, is that what the 'upstream' close reason is for? Normally, I close
> > things 'upstream' when I have checked a fix into the upstream code base.
> > Which seems pretty reasonable time to close it to me.
> >
> > -sv
> >
>  
>  I'm talking about closing the bug and telling the reporter to report
>  upstream, i.e. "go away".
>   
I agree that the above is bad.

Sometimes (rarely) I do forward a bugreport upstream (using upstream's 
preferred bug tracking mechanism) and then kindly explain that I'm not intimate 
enough with the code to fix the issue at hand with a reasonable effort, point 
them to the upstream bug and add them to the CC there if possible. And then 
close with a resolution of upstream. Not very pretty, but honest and way better 
then letting bugs linger for months.

Regards,

Hans

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote:
>  nodata wrote:
>  >Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal:
>  >>On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:
>  >>
>  >>>Apart from security bugs, I have never had a bug fixed in Ubuntu, ever.
>  >>>The tactic seems to be to wait until Debian fix it, or wait until Debian
>  >>>fix it and then ask you to upgrade to the next release.
>  >>>
>  >>>Fedora does a lot better, much better, but probably the most annoying
>  >>>aspect of using Fedora's bugzilla is the attitude of some of the
>  >>>maintainers (not all) and the "closing, report upstream" attitude.
>  >>>
>  >>>Closing a bug report with "report it upstream" is a let down.
> It's
>  >>>repetitive boring work that a computer should be doing.
>  >>>
>  >>>It takes a lot of effort to report a bug, and by this I mean that I know
>  >>>a *lot* of people who find a bug, and maybe a fix, but don't bug report
>  >>>it. They should be, but I can see why they don't.
>  >>Hmm, is that what the 'upstream' close reason is for? Normally, I close
>  >>things 'upstream' when I have checked a fix into the upstream code base.
>  >>Which seems pretty reasonable time to close it to me.
>  >>
>  >>-sv
>  >>
>  >
>  >I'm talking about closing the bug and telling the reporter to report
>  >upstream, i.e. "go away".
>  >
>  
>  I agree that the above is bad.
>  
>  Sometimes (rarely) I do forward a bugreport upstream (using upstream's 
>  preferred bug tracking mechanism) and then kindly explain that I'm not 
>  intimate enough with the code to fix the issue at hand with a reasonable 
>  effort, point them to the upstream bug and add them to the CC there if 
>  possible. And then close with a resolution of upstream. Not very pretty, 
>  but honest and way better then letting bugs linger for months. 
It is possible to link tickets between the Red Hat bugzilla and other
BZ instances. At the bottom there is a 'External Bugzilla References'
form - simply add the number of the associated upstream BZ ticket. 
Rather than entering upstream and then closing the RH BZ ticket, I'd
suggest using this linkage between BZ instances. Then when the upstream
maintainer finds a fix, you still have a record of the fact that it
needs to be pulled into Fedora. If you close the Fedora BZ, you'll
never remember to pull in the fix from upstream.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Hans de Goede]

Daniel P. Berrange wrote:
>  On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote:
> > nodata wrote:
> >> Am Samstag, den 19.01.2008, 13:10 -0500 schrieb seth vidal:
> >>> On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:
> >>>
> >>>> Apart from security bugs, I have never had a bug fixed in Ubuntu, ever.
> >>>> The tactic seems to be to wait until Debian fix it, or wait until Debian
> >>>> fix it and then ask you to upgrade to the next release.
> >>>>
> >>>> Fedora does a lot better, much better, but probably the most annoying
> >>>> aspect of using Fedora's bugzilla is the attitude of some of the
> >>>> maintainers (not all) and the "closing, report upstream"
> attitude.
> >>>>
> >>>> Closing a bug report with "report it upstream" is a let down.
> It's
> >>>> repetitive boring work that a computer should be doing.
> >>>>
> >>>> It takes a lot of effort to report a bug, and by this I mean that I know
> >>>> a *lot* of people who find a bug, and maybe a fix, but don't bug
> report
> >>>> it. They should be, but I can see why they don't.
> >>> Hmm, is that what the 'upstream' close reason is for? Normally, I
> close
> >>> things 'upstream' when I have checked a fix into the upstream code
> base.
> >>> Which seems pretty reasonable time to close it to me.
> >>>
> >>> -sv
> >>>
> >> I'm talking about closing the bug and telling the reporter to report
> >> upstream, i.e. "go away".
> >>
> > I agree that the above is bad.
> >
> > Sometimes (rarely) I do forward a bugreport upstream (using upstream's 
> > preferred bug tracking mechanism) and then kindly explain that I'm not 
> > intimate enough with the code to fix the issue at hand with a reasonable 
> > effort, point them to the upstream bug and add them to the CC there if 
> > possible. And then close with a resolution of upstream. Not very pretty, 
> > but honest and way better then letting bugs linger for months.
>  
>  It is possible to link tickets between the Red Hat bugzilla and other
>  BZ instances. At the bottom there is a 'External Bugzilla References'
>  form - simply add the number of the associated upstream BZ ticket. 
>  Rather than entering upstream and then closing the RH BZ ticket, I'd
>  suggest using this linkage between BZ instances. Then when the upstream
>  maintainer finds a fix, you still have a record of the fact that it
>  needs to be pulled into Fedora. If you close the Fedora BZ, you'll
>  never remember to pull in the fix from upstream.
>   
I know about the BZ link feature and I always use it when a bug is reported 
both upstream and in Fedora, but I've never ever seen any good come out of it, 
I would expect Fedora BZ to send out mails to those CC-ed on the Fedora bug 
when something happens in the upstream linked bug, maybe even add a comment 
when the upstream bug changes, but it does none of the above, so I wonder what 
is the added value of using the BZ link feature instead of just putting an url 
to upstream's ticket in a comment?

Regards,

Hans

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 07:47:00PM +0100, Hans de Goede wrote:
>  Daniel P. Berrange wrote:
>  >On Sat, Jan 19, 2008 at 07:34:57PM +0100, Hans de Goede wrote:
>  >>nodata wrote:
>  >>
>  >>Sometimes (rarely) I do forward a bugreport upstream (using upstream's 
>  >>preferred bug tracking mechanism) and then kindly explain that I'm not 
>  >>intimate enough with the code to fix the issue at hand with a reasonable 
>  >>effort, point them to the upstream bug and add them to the CC there if 
>  >>possible. And then close with a resolution of upstream. Not very pretty, 
>  >>but honest and way better then letting bugs linger for months.
>  >
>  >It is possible to link tickets between the Red Hat bugzilla and other
>  >BZ instances. At the bottom there is a 'External Bugzilla References'
>  >form - simply add the number of the associated upstream BZ ticket. 
>  >Rather than entering upstream and then closing the RH BZ ticket, I'd
>  >suggest using this linkage between BZ instances. Then when the upstream
>  >maintainer finds a fix, you still have a record of the fact that it
>  >needs to be pulled into Fedora. If you close the Fedora BZ, you'll
>  >never remember to pull in the fix from upstream.
>  >
>  
>  I know about the BZ link feature and I always use it when a bug is reported 
>  both upstream and in Fedora, but I've never ever seen any good come out of 
>  it, I would expect Fedora BZ to send out mails to those CC-ed on the Fedora 
>  bug when something happens in the upstream linked bug, maybe even add a 
>  comment when the upstream bug changes, but it does none of the above, so I 
>  wonder what is the added value of using the BZ link feature instead of just 
>  putting an url to upstream's ticket in a comment? 
With some upstream BZ instances, we do actually get state updates from the
upstream BZ fed back into the RH BZ, but I agree in 95% of scenarios it
does very little. Which is a shame. At least by using the link feature
we have the potential to write tools to do automatic analysis/reports/etc.
But if you just add a URL, we have lost this formal linkage forever and
don't even get the possibilty of writing tools to process it.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Matej Cepl]

On 2008-01-19, 18:47 GMT, Hans de Goede wrote:
>  I would expect Fedora BZ to send out mails to those CC-ed on 
>  the Fedora bug when something happens in the upstream linked 
>  bug, maybe even add a comment when the upstream bug changes, 
>  but it does none of the above, so I wonder what is the added 
>  value of using the BZ link feature instead of just putting an 
>  url to upstream's ticket in a comment? 
I am not sure, whether this bug 
https://bugzilla.redhat.com/show_bug.cgi?id=189813 is a good 
candidate for comment, or whether you should file a new bug, but 
I would love to Cc: on that.

Matěj

[Nicolas Mailhot]

Le samedi 19 janvier 2008 à 18:39 +0000, Daniel P. Berrange a écrit :
 
>  Rather than entering upstream and then closing the RH BZ ticket,
> I'd
>  suggest using this linkage between BZ instances.  
Unfortunately some packagers will still yell at you for opening two
bugs 

-- 
Nicolas Mailhot

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 09:10:31PM +0100, Nicolas Mailhot wrote:
>  
>  Le samedi 19 janvier 2008 à 18:39 +0000, Daniel P. Berrange a écrit :
>   
>  > Rather than entering upstream and then closing the RH BZ ticket, I'd
>  > suggest using this linkage between BZ instances. 
>  
>  Unfortunately some packagers will still yell at you for opening two
>  bugs  
I don't care about packagers yelling at me - I care about making the best
effort to fix user's bugs. 

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Jef Spaleta]

On Jan 19, 2008 9:23 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  I'm talking about closing the bug and telling the reporter to
> report
>  upstream, i.e. "go away". 

As a package maintainer, what would you like me to do in situations
where I need the reporter to talk to upstream?  Should I just pat you
on the head and promise to fix it, even though I can't?  If I can't
even reproduce the problem with my hardware, or its a feature request
that needs to be discussed as part of an upstream development what
exactly are the better choices than encouraging you to take your case
to upstream?

-jef"I'm no Seth"spaleta

[nodata]

Am Samstag, den 19.01.2008, 20:36 -0900 schrieb Jeff Spaleta:
>  On Jan 19, 2008 9:23 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > I'm talking about closing the bug and telling the reporter to report
>  > upstream, i.e. "go away".
>  
>  
>  As a package maintainer, what would you like me to do in situations
>  where I need the reporter to talk to upstream?  Should I just pat you
>  on the head and promise to fix it, even though I can't?  If I can't
>  even reproduce the problem with my hardware, or its a feature request
>  that needs to be discussed as part of an upstream development what
>  exactly are the better choices than encouraging you to take your case
>  to upstream?
>  
>  -jef"I'm no Seth"spaleta
>   
I'd like you to click the "transfer to upstream bugzilla" button :)

[Jef Spaleta]

On Jan 20, 2008 1:39 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  I'd like you to click the "transfer to upstream
> bugzilla" button :) 
That button exists?

-jef

[Ignacio Vazquez-Abrams]

On Sun, 2008-01-20 at 14:54 -0900, Jeff Spaleta wrote:
>  On Jan 20, 2008 1:39 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > I'd like you to click the "transfer to upstream bugzilla" button :)
>  
>  That button exists? 
I'm sure if we poke mkanat long/hard enough...

-- 
Ignacio Vazquez-Abrams <ivazqueznet(a)gmail.com&gt;

PLEASE don't CC me; I'm already subscribed

[Jon Stanley]

It does. It is used when a maintainer (or someone) reports a bug to an
upstream bz or whatever. I agree that there needs to be something in
the 'External Bugzilla Reference' part when this is used. I'm out
watching (American) football at the moment, so if someone could make
this change it would be appreciated.


On 1/20/08, Jeff Spaleta <jspaleta(a)gmail.com&gt; wrote:
>  On Jan 20, 2008 1:39 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > I'd like you to click the "transfer to upstream bugzilla" button :)
>
>  That button exists?
>
>  -jef
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
Jon Stanley
Fedora Ambassador
jstanley(a)fedoraproject.org

[Jesse Keating]

On Sat, 19 Jan 2008 20:36:52 -0900
"Jeff Spaleta" <jspaleta(a)gmail.com&gt; wrote:

>  As a package maintainer, what would you like me to do in situations
>  where I need the reporter to talk to upstream?  
You file the bug upstream for them, and add them to the cc list if
possible, or you file it upstream, and respond in our bugzilla with a
link to the upstream bug and ask them to attach themselves to that
upstream bug.

I get the sense that we need to come up with a 'How to appropriately
respond to bugzilla entries' guideline for new maintainers...

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Ralf Corsepius]

On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote:
>  On Jan 19, 2008 9:23 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > I'm talking about closing the bug and telling the reporter to report
>  > upstream, i.e. "go away".
>  
>  
>  As a package maintainer, what would you like me to do in situations
>  where I need the reporter to talk to upstream? 
A reporter should never be supposed
to talk upstream, because he is
reporting an issue a problem with the product (your package) you are
supposed to be responsible for, not against the product an upstream
ships to you (the source tarball).

>    Should I just pat you
>  on the head and promise to fix it, even though I can't? 
What prevents you from
simply telling the truth?

>    If I can't
>  even reproduce the problem with my hardware, or its a feature request
>  that needs to be discussed as part of an upstream development what
>  exactly are the better choices than encouraging you to take your case
>  to upstream? 
Communicate such issues upstream and provide upstream a link to the
original issue, such they can investigate?

Ralf

[Jef Spaleta]

On Jan 20, 2008 10:36 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  A reporter should never be supposed to talk upstream, because he is
>  reporting an issue a problem with the product (your package) you are
>  supposed to be responsible for, not against the product an upstream
>  ships to you (the source tarball). 
I think you are wrong. Dead wrong.
it does absolutely no good for me to attempt to act as a proxy for
hardware breakage that I can't re-confirm with my own hardware.  At
some point the person experiencing the hardware problem has to be able
to talk directly with a developer who is in a position to confirm and
fix.  Whether that means driving upstream developers to the fedora
bugreport or driving users to upstream developers.... it doesn't
matter. I refuse..REFUSE... to stop asking users with hardware
specific breakage to be proactive and tap into the upstream resource
when I can't confirm the problem.

If there is a feature request that needs discussion, then why exactly
should I as a maintainer be the one to champion it? If it's something
i've no personal interest in it, nor have a personal need for it, then
I'm certainly not in a position to argue for it.  The stake holders
for those sort of discussions are in the upstream development
communication channels... that's where feature roadmapping
happens...and that's where features have to be discussed and
integrated.  I'm not going to stand in proxy for someone else's ideas
that do not resonate with me.  Nor am I going to drop a request on the
floor at the fedora package level, because I personally unmoved by a
particular feature request.  I'm not such an egotistical bastard that
I'm going to assume that just because I'm not interested in the
feature as the Fedora package maintainer that the upstream developers
aren't.

>  What prevents you from simply telling the truth? 
I do tell the truth...sometimes upstream communication is a useful
thing...and continuing to rely on me as the Fedora package maintainer
to do all of it, is in fact a sub-optimal way of making sure things
get done.  I suck and I'll proudly and forthrightly tell people that.

-jef

[Jon Ciesla]

>  On Jan 20, 2008 10:36 PM, Ralf Corsepius <rc040203(a)freenet.de&gt;
> wrote:
> > A reporter should never be supposed to talk upstream, because he is
> > reporting an issue a problem with the product (your package) you are
> > supposed to be responsible for, not against the product an upstream
> > ships to you (the source tarball).
>
>  I think you are wrong. Dead wrong.
>  it does absolutely no good for me to attempt to act as a proxy for
>  hardware breakage that I can't re-confirm with my own hardware.  At
>  some point the person experiencing the hardware problem has to be able
>  to talk directly with a developer who is in a position to confirm and
>  fix.  Whether that means driving upstream developers to the fedora
>  bugreport or driving users to upstream developers.... it doesn't
>  matter. I refuse..REFUSE... to stop asking users with hardware
>  specific breakage to be proactive and tap into the upstream resource
>  when I can't confirm the problem.
>
>  If there is a feature request that needs discussion, then why exactly
>  should I as a maintainer be the one to champion it? If it's something
>  i've no personal interest in it, nor have a personal need for it, then
>  I'm certainly not in a position to argue for it.  The stake holders
>  for those sort of discussions are in the upstream development
>  communication channels... that's where feature roadmapping
>  happens...and that's where features have to be discussed and
>  integrated.  I'm not going to stand in proxy for someone else's ideas
>  that do not resonate with me.  Nor am I going to drop a request on the
>  floor at the fedora package level, because I personally unmoved by a
>  particular feature request.  I'm not such an egotistical bastard that
>  I'm going to assume that just because I'm not interested in the
>  feature as the Fedora package maintainer that the upstream developers
>  aren't.
>
> > What prevents you from simply telling the truth?
>
>  I do tell the truth...sometimes upstream communication is a useful
>  thing...and continuing to rely on me as the Fedora package maintainer
>  to do all of it, is in fact a sub-optimal way of making sure things
>  get done.  I suck and I'll proudly and forthrightly tell people that.
>
>  -jef 
I have to agree with jef.  More communication is generally better.  Some
upstream devs are wonderful at troubleshooting bugs, and really make
maintaining the package easier.  Why not use all the resources available?

>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
novus ordo absurdum

[Jesse Keating]

On Wed, 23 Jan 2008 11:06:22 -0900
"Jeff Spaleta" <jspaleta(a)gmail.com&gt; wrote:

>  I think you are wrong. Dead wrong.
>  it does absolutely no good for me to attempt to act as a proxy for
>  hardware breakage that I can't re-confirm with my own hardware.  At
>  some point the person experiencing the hardware problem has to be able
>  to talk directly with a developer who is in a position to confirm and
>  fix.  Whether that means driving upstream developers to the fedora
>  bugreport or driving users to upstream developers.... it doesn't
>  matter. I refuse..REFUSE... to stop asking users with hardware
>  specific breakage to be proactive and tap into the upstream resource
>  when I can't confirm the problem. 
There is a huge difference between engaging the user and helping them
to contact upstream, or getting upstream in contact with the user,
basically facilitating that wonderful communication, and saying "Shut
up, that's upstream, go away" and closing the bug.

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

[Jon Ciesla]

>  On Wed, 23 Jan 2008 11:06:22 -0900
>  "Jeff Spaleta" <jspaleta(a)gmail.com&gt; wrote:
>
> > I think you are wrong. Dead wrong.
> > it does absolutely no good for me to attempt to act as a proxy for
> > hardware breakage that I can't re-confirm with my own hardware.  At
> > some point the person experiencing the hardware problem has to be able
> > to talk directly with a developer who is in a position to confirm and
> > fix.  Whether that means driving upstream developers to the fedora
> > bugreport or driving users to upstream developers.... it doesn't
> > matter. I refuse..REFUSE... to stop asking users with hardware
> > specific breakage to be proactive and tap into the upstream resource
> > when I can't confirm the problem.
>
>  There is a huge difference between engaging the user and helping them
>  to contact upstream, or getting upstream in contact with the user,
>  basically facilitating that wonderful communication, and saying "Shut
>  up, that's upstream, go away" and closing the bug. 
Very true, it MUST be a collaborative exercise.

>  --
>  Jesse Keating
>  Fedora -- All my bits are free, are yours?
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list 

-- 
novus ordo absurdum

[Alan Cox]

On Wed, Jan 23, 2008 at 02:20:01PM -0600, Jon Ciesla wrote:
>  >> specific breakage to be proactive and tap into the upstream
> resource
>  >> when I can't confirm the problem.
>  >
>  > There is a huge difference between engaging the user and helping them
>  > to contact upstream, or getting upstream in contact with the user,
>  > basically facilitating that wonderful communication, and saying "Shut
>  > up, that's upstream, go away" and closing the bug.
>  
>  Very true, it MUST be a collaborative exercise. 
I try to leave the RH bug open and even if I report it being an upstream
problem then update it now and again with the status of things. That way
people at least know something is happening and when it will be worth trying
an update

[Chris Adams]

Once upon a time, Alan Cox <alan(a)redhat.com&gt; said:
>  I try to leave the RH bug open and even if I report it being an
> upstream
>  problem then update it now and again with the status of things. That way
>  people at least know something is happening and when it will be worth trying
>  an update 
Sometimes the RH bug owner _is_ upstream; I reported a bug in hal-info
data and didn't get a response yet, so I opened a bug upstream.  I think
it ended up owned by the same person.

One argument in favor of having the package owner report bugs upstream
is they presumably have a better idea about how and where, have bugzilla
accounts, etc.  They can filter the reports (so when Fedora users open
10 RH bug entries for the same problem, upstream only has to deal with
one report).  The package owner will also need to know when the bug has
been fixed to make an update (in some cases, end-users may need a
package owner to help build test packages as well).

-- 
Chris Adams <cmadams(a)hiwaay.net&gt;
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.

[Jon Ciesla]

>  Once upon a time, Alan Cox <alan(a)redhat.com&gt; said:
> > I try to leave the RH bug open and even if I report it being an upstream
> > problem then update it now and again with the status of things. That way
> > people at least know something is happening and when it will be worth
> > trying
> > an update
>
>  Sometimes the RH bug owner _is_ upstream; I reported a bug in hal-info
>  data and didn't get a response yet, so I opened a bug upstream.  I think
>  it ended up owned by the same person.
>
>  One argument in favor of having the package owner report bugs upstream
>  is they presumably have a better idea about how and where, have bugzilla
>  accounts, etc.  They can filter the reports (so when Fedora users open
>  10 RH bug entries for the same problem, upstream only has to deal with
>  one report).  The package owner will also need to know when the bug has
>  been fixed to make an update (in some cases, end-users may need a
>  package owner to help build test packages as well). 
I do exactly what Alan does.  Making the RH bug a coordinating point is
helpful for users, so they don't necessarily have to dig too far to find
out what's going on. I have this going on with a roundcubemail security
bug going on right now.  I have a reference to the upstream bug in the RH
bug, so users can see for themselves why it's not updated yet. :/

>  --
>  Chris Adams <cmadams(a)hiwaay.net&gt;
>  Systems and Network Administrator - HiWAAY Internet Services
>  I don't speak for anybody but myself - that's enough trouble.
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
novus ordo absurdum

[Ralf Corsepius]

On Wed, 2008-01-23 at 16:06 -0500, Alan Cox wrote:
>  On Wed, Jan 23, 2008 at 02:20:01PM -0600, Jon Ciesla wrote:
>  > >> specific breakage to be proactive and tap into the upstream resource
>  > >> when I can't confirm the problem.
>  > >
>  > > There is a huge difference between engaging the user and helping them
>  > > to contact upstream, or getting upstream in contact with the user,
>  > > basically facilitating that wonderful communication, and saying "Shut
>  > > up, that's upstream, go away" and closing the bug.
Unfortunately, the latter also happens.

>  > Very true, it MUST be a collaborative exercise.
>  
>  I try to leave the RH bug open and even if I report it being an upstream
>  problem then update it now and again with the status of things. That way
>  people at least know something is happening and when it will be worth trying
>  an update 
Fully agreed, that's the only viable and reasonable approach.

Ralf

[Michael Schwendt]

On Wed, 23 Jan 2008 11:06:22 -0900, Jeff Spaleta wrote:

>  On Jan 20, 2008 10:36 PM, Ralf Corsepius wrote:
>  > A reporter should never be supposed to talk upstream, because he is
>  > reporting an issue a problem with the product (your package) you are
>  > supposed to be responsible for, not against the product an upstream
>  > ships to you (the source tarball).
>  
>  I think you are wrong. Dead wrong.
>  it does absolutely no good for me to attempt to act as a proxy for
>  hardware breakage that I can't re-confirm with my own hardware. 
-snip-

And with regard to many bugs you can reproduce, which do not require
special hardware, Ralf is right.

Even in the specific case you outline above you are supposed to notify
upstream developers about the problem yourself. Because if you don't, and
if the user does not report the problem upstream, the product *you* ship
might remain broken.

[Horst H. von Brand]

Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote:
>  > On Jan 19, 2008 9:23 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > > I'm talking about closing the bug and telling the reporter to report
>  > > upstream, i.e. "go away". 
>  > As a package maintainer, what would you like me to do in
> situations
>  > where I need the reporter to talk to upstream? 
>  A reporter should never be supposed to talk upstream, because he is
>  reporting an issue a problem with the product (your package) you are
>  supposed to be responsible for, not against the product an upstream
>  ships to you (the source tarball). 
It might very well happen that the packager can't reproduce the problem
(doesn't have the exact hardware, whatever).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: [phone]
Universidad Tecnica Federico Santa Maria             [phone]
Casilla 110-V, Valparaiso, Chile               Fax:  [phone]

[Ralf Corsepius]

On Wed, 2008-01-23 at 19:29 -0300, Horst H. von Brand wrote:
>  Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  > On Sat, 2008-01-19 at 20:36 -0900, Jeff Spaleta wrote:
>  > > On Jan 19, 2008 9:23 AM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  > > > I'm talking about closing the bug and telling the reporter to report
>  > > > upstream, i.e. "go away".
>  
>  > > As a package maintainer, what would you like me to do in situations
>  > > where I need the reporter to talk to upstream?
>  
>  > A reporter should never be supposed to talk upstream, because he is
>  > reporting an issue a problem with the product (your package) you are
>  > supposed to be responsible for, not against the product an upstream
>  > ships to you (the source tarball).
>  
>  It might very well happen that the packager can't reproduce the problem
>  (doesn't have the exact hardware, whatever). 
Yes, it _might_ happen, nobody
denies this, but ...

... this is far from being the rule/norm.

Often reporters are ordinary user, who actually don't have much clues
about an application's internals, who "just reports something" he
considers to be a "bug" or an application "misbehavior". Forcing them
to
"go upstream" would mean to push them into a forum they often aren't
really interested to participate in nor competent enough to participate.

Ralf

[Tom Lane]

seth vidal <skvidal(a)fedoraproject.org&gt; writes:
>  On Sat, 2008-01-19 at 19:08 +0100, nodata wrote:
> > Closing a bug report with "report it upstream" is a let down. It's
> > repetitive boring work that a computer should be doing.
> > 
> > It takes a lot of effort to report a bug, and by this I mean that I know
> > a *lot* of people who find a bug, and maybe a fix, but don't bug report
> > it. They should be, but I can see why they don't. 
>  Hmm, is that what the 'upstream' close reason is for? 
I believe what that's supposed to mean is "the bug *has been* reported
upstream" --- either by the maintainer or the original reporter.

Now if the maintainer can't fix it himself, I can see the point of
asking the original reporter to report upstream: cutting out the
middleman.  If upstream wants more details they're likely to need to
ask the original reporter anyway.

But certainly the maintainer should be polite about asking that.

			regards, tom lane

[Nicolas Mailhot]

Le samedi 19 janvier 2008 à 13:10 -0500, seth vidal a écrit :

>  Hmm, is that what the 'upstream' close reason is for?
> Normally, I close
>  things 'upstream' when I have checked a fix into the upstream code base.
>  Which seems pretty reasonable time to close it to me. 
There is a huge variance between maintainers.

Some will only look at fedora bugs
Others will tell you to open bugs upstream, but do nothing if a sister
fedora bug is not opened
Yet others will only look at upstream bugs, and complain if you open a
fedora bug
Others won't look at any bug and rely on upstream grapewine to know what
need to be fixed.

Complete disregard for tester efforts seems widespread. Complaining to
reporters they didn't open an issue in the right place is common. So is
ignoring bugs because supposedly they're not complete enough (without
bothering to explain what complete would be). Even more annoying are
maintainers that ask to do a lot of stuff then ignore completely the
result.

There are exceptions of course (in particular I nominate Caolan McNamara
for being exceptionally responsive ad helpful on openoffice.org bugs).
But most of the times fighting spirit and behaving like a bastard seems
to be a requirement to get issues dealt with (for example forgetting to
block the right fxblocker is a quick way to oblivion)

-- 
Nicolas Mailhot

[Kevin Kofler]

Nicolas Mailhot <nicolas.mailhot <at> laposte.net> writes:
>  Complete disregard for tester efforts seems widespread. Complaining
> to
>  reporters they didn't open an issue in the right place is common. So is
>  ignoring bugs because supposedly they're not complete enough (without
>  bothering to explain what complete would be). Even more annoying are
>  maintainers that ask to do a lot of stuff then ignore completely the
>  result. 
I can fully understand your frustration, reporting a bug can be hard sometimes. 
However, please also try to understand the maintainer's side. You're 
maintaining a few packages yourself, have you never felt frustrated about:
* getting swamped with dozens of (non-Fedora-specific) bug reports against huge 
upstream projects, where technically you might be able to fix any of them, but 
you definitely don't have the time to fix them all? and/or
* occasionally getting bug reports which are so vague that you don't have the 
slightest chance of ever figuring out what went wrong, let alone reproducing 
them? (This is not always the reporters fault, by the way, some applications 
love crashing, drawing things incorrectly etc. for no apparent reason. See e.g. 
XChat's occasional weird graphical glitches which have been there for years 
because nobody understands what's happening. These things can frustrate the 
maintainer at least as much as the reporter.)
That's the situation of a lot of packages, and especially the first issue is a 
major one for KDE.

We're doing what we can to fix KDE bugs. In our case, the preferred way to 
handle things is:
* Please file bug reports both at Fedora and KDE, and cross-link them (use the 
upstream URL feature in our Bugzilla). Once you clicked through the "pick your 
component" wizard at bugs.kde.org, you can just copy&paste your entire 
formatted Fedora bug report into their freetext textbox. (Yes, it would be 
great if we could sync our bugzillas automatically, but unfortunately it's just 
not there, so someone has to do the copy&paste. It's better if the reporter 
does it because that way they'll get the bugmail. We know how to CC ourselves 
where it makes sense, CCing a reporter in a bug we file is harder because we 
can't know if you have a valid KDE bugzilla account nor if it's under the same 
e-mail address as the Fedora one.)
* We'll try to track the upstream bug report, but pinging us if upstream comes 
up with a fix can't hurt.
* The more urgent the bug, the more likely we are to apply a fix as soon as 
possible. Otherwise, we'll pick it up automatically once we upgrade to the next 
bugfix release of KDE. (We aren't pushing those updates just for fun, nor to 
sadistically break things as we're sometimes accused of.)

        Kevin Kofler

[Nicolas Mailhot]

Le samedi 19 janvier 2008 à 20:31 +0000, Kevin Kofler a écrit :
>  Nicolas Mailhot <nicolas.mailhot <at> laposte.net>
> writes:
>  > Complete disregard for tester efforts seems widespread. Complaining to
>  > reporters they didn't open an issue in the right place is common. So is
>  > ignoring bugs because supposedly they're not complete enough (without
>  > bothering to explain what complete would be). Even more annoying are
>  > maintainers that ask to do a lot of stuff then ignore completely the
>  > result.
>  
>  I can fully understand your frustration, reporting a bug can be hard sometimes. 
>  However, please also try to understand the maintainer's side. 
I completely understand maintainers. They reserve their right to be
bastards (for very good reasons). So do I (ditto).

However it does mean I won't ever suggest newbies to report bugs with
good conscience, because most of them are not ready for such a ruthless
system.

-- 
Nicolas Mailhot

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 09:08:38PM +0100, Nicolas Mailhot wrote:
>  Complete disregard for tester efforts seems widespread. Complaining
> to
>  reporters they didn't open an issue in the right place is common. So is
>  ignoring bugs because supposedly they're not complete enough (without
>  bothering to explain what complete would be). Even more annoying are
>  maintainers that ask to do a lot of stuff then ignore completely the
>  result. 
For all Xen related bugs I always need to get /var/log/xen/xend.log
and quite often the guest VM config file. At the same time I often do
not have time to deal with a bug immediately. So I will take a quick
look at request the info that will likely be required to diagnose the
bug. So when I do finally have time to analyse the bug perhaps a month
or more later, I will have most of the info neccessary.  If I didn't
request the data immediately, then the user would probably not still
have the neccessary data the weeks/ month later and there'd be no
chance to fix it.  So I always as for as much information as possible
the moment the bug is opened, since that's the time at which the user
has it easily available.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Till Maas]

On Saturday 19 January 2008 21:41:07 Daniel P. Berrange wrote:

>  For all Xen related bugs I always need to get /var/log/xen/xend.log
>  and quite often the guest VM config file. At the same time I often do
>  not have time to deal with a bug immediately. So I will take a quick
>  look at request the info that will likely be required to diagnose the
>  bug. So when I do finally have time to analyse the bug perhaps a month
>  or more later, I will have most of the info neccessary.  If I didn't
>  request the data immediately, then the user would probably not still
>  have the neccessary data the weeks/ month later and there'd be no
>  chance to fix it.  So I always as for as much information as possible
>  the moment the bug is opened, since that's the time at which the user
>  has it easily available. 
Maybe the bug reporter feels better, when you explain this in your comment, if 
you do not do this already.

Regards,
Till

[Daniel P. Berrange]

On Sat, Jan 19, 2008 at 09:48:15PM +0100, Till Maas wrote:
>  On Saturday 19 January 2008 21:41:07 Daniel P. Berrange wrote:
>  
>  > For all Xen related bugs I always need to get /var/log/xen/xend.log
>  > and quite often the guest VM config file. At the same time I often do
>  > not have time to deal with a bug immediately. So I will take a quick
>  > look at request the info that will likely be required to diagnose the
>  > bug. So when I do finally have time to analyse the bug perhaps a month
>  > or more later, I will have most of the info neccessary.  If I didn't
>  > request the data immediately, then the user would probably not still
>  > have the neccessary data the weeks/ month later and there'd be no
>  > chance to fix it.  So I always as for as much information as possible
>  > the moment the bug is opened, since that's the time at which the user
>  > has it easily available.
>  
>  Maybe the bug reporter feels better, when you explain this in your comment, if 
>  you do not do this already. 
Sometimes I do, sometimes I don't - its hard to generalize the response
since it depends on a thousand & one different factors. One thing I think
would be helpful though, would be for bugzilla to show people a list of
required data when entering a bug on a per component level.

eg, for a virt-manager bug I always want $HOME/.virt-manager.log

eg, for a Xen bug I always want /var/log/xen/xend.log, and the config file
    of the associated guest VM

eg, for an perl-Test-AutoBuild bug I always want /var/lib/builder/auto-build.log

Even if the user thinks they are providing enough info that they don't
need the logs, history has taught me that people frequently supply incorrect
data, either accidentally or delibrately.

It shouldn't be outside the realms of possibility to be able to associate
a short snippet of HTML with each BZ component, so the 'create bug' form
can tell users the component-specific data required upfront.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  [phone] -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|

[Matej Cepl]

On 2008-01-19, 18:10 GMT, seth vidal wrote:
>  Hmm, is that what the 'upstream' close reason is for?
> Normally, 
>  I close things 'upstream' when I have checked a fix into the 
>  upstream code base. Which seems pretty reasonable time to close 
>  it to me. 
OK, this is something which should be well described in the 
http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?).  
Closing upstream is from the maintainer's point of view pretty 
difficult thing to do. First rule, which I try to always hold 
with Xorg bugs is that the bug should *NEVER* be closed as 
UPSTREAM unless I have number of the upstream bug in the External 
Bugzilla References (or in the comment, if the upstream bugzilla 
is not available among external bugzilla references; fortunately, 
that doesn't happen for the bugs I triage). So, even if I ask 
reporter to file the bug upstream (and I do it less and less), 
I put them in NEEDINFO, and close the bug as UPSTREAM only when 
they come bug with the number of the upstream bug.

I totally understand the reasons why we ask reporters to file the 
bug, and why it is problematic to file a bug ourselves (after 
all, it is THEIR bug, they can reproduce it, test the fix, 
provide additional information, etc.), but still I do it less and 
less. Now I usually try to find a duplicate bug in the upstream 
bugzilla (trip into Mozilla bugzilla always cheers me up -- if 
our bugzilla is mess, and it is, I have no words to describe 
their bugzilla ;-)), and suggest to the reporter to comment on it 
and join the happy crowd around that bug in the upstream 
bugzilla.

The reason is that asking them to file a bug upstream (internally 
called "a request for suicide") is very bad from the marketing 
point of view. I feel that we should treat the bug reporters as 
our most valuable asset (which they are), and to be very careful 
not to alieante them. If there is a person, who is willing to 
file a reasonably thought-through bug to our bugzilla, it is 
a person, which is extremely valuable to us (because that's the 
only QA we have in Fedora, and because open-source software is 
bug driven).

However, I don't think it is necessary to close bug upstream only 
when I have actually fixed it (unless you are a primary developer 
of the particular component, as seth is). Whole point of 
upstreaming bugs (and you can read it in 
https://bugzilla.redhat.com/page.cgi?id=fields.html#upstream 
which is actually pretty good resource to read) is that everybody 
from all distributions can join their efforts about fixing the 
bug, so the issue doesn't have to be fixed multiple times in each 
distro independently. It is always a good idea to write something 
in such sense to the comment by which you either ask reporter to 
file a bug upstream, or by the one by which you close the bug.

Just my 0.02 CZK ;-)

Matěj

[Jon Stanley]

On Jan 19, 2008 5:19 PM, Matej Cepl <mcepl(a)redhat.com&gt; wrote:

>  OK, this is something which should be well described in the
>  http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?). 
I've added some stuff, instead of the novel here, I've put the Cliff's
Notes version in :).  Let me know if I got something wrong.

[Matej Cepl]

On 2008-01-20, 00:56 GMT, Jon Stanley wrote:
>  On Jan 19, 2008 5:19 PM, Matej Cepl <mcepl(a)redhat.com&gt; wrote:
>
> > OK, this is something which should be well described in the
> > http://fedoraproject.org/wiki/JonStanley/BugWorkflow (Jon?).
>
>  I've added some stuff, instead of the novel here, I've put the Cliff's
>  Notes version in :).  Let me know if I got something wrong. 
Thanks, I am sorry to employ as my Cliff ;-), but I would really 
add as an iron rule, that there always have to be the upstream 
bug number in the External Bugzilla References, before the bug is 
closed as UPSTREAM.

Matej

[Kevin Kofler]

nodata <lsof <at> nodata.co.uk> writes:
>  Fedora does a lot better, much better, but probably the most
> annoying
>  aspect of using Fedora's bugzilla is the attitude of some of the
>  maintainers (not all) and the "closing, report upstream" attitude.
>  
>  Closing a bug report with "report it upstream" is a let down. It's
>  repetitive boring work that a computer should be doing. 
We're 4 maintainers for all of KDE in Fedora (and that's already 4 times as 
many as not too long ago). We get dozens of bug reports, many of which aren't 
specific to Fedora in any way. There's no way we can fix them all by ourselves, 
the only way to actually get things fixed is to report them to the actual 
upstream maintainers of the concrete application you're having issues with. And 
I don't think KDE is the only set of packages in this situation.

        Kevin Kofler

[Benjamin Kreuter]

On Saturday 19 January 2008 15:05:36 Kevin Kofler wrote:
>  We're 4 maintainers for all of KDE in Fedora (and that's
> already 4 times as
>  many as not too long ago). We get dozens of bug reports, many of which
>  aren't specific to Fedora in any way. There's no way we can fix them all by
>  ourselves, the only way to actually get things fixed is to report them to
>  the actual upstream maintainers of the concrete application you're having
>  issues with. And I don't think KDE is the only set of packages in this
>  situation.
>
>          Kevin Kofler 
Yeah, but that is the reason why bugs are referred upstream.  The problem is 
when a package maintainer tries to say that the problem is upstream in 
situations where the bug is caused by the way the package was compiled, or 
some conflicting configuration with another package, etc.

-- Benjamin Kreuter

[Kevin Kofler]

Benjamin Kreuter <ben.kreuter <at> gmail.com> writes:
>  Yeah, but that is the reason why bugs are referred upstream.  The
> problem is 
>  when a package maintainer tries to say that the problem is upstream in 
>  situations where the bug is caused by the way the package was compiled, or 
>  some conflicting configuration with another package, etc. 
Of course, if the maintainer(s) try blaming upstream for something which is 
actually their fault, that's bad. Unfortunately, it isn't always obvious who's

at fault.

        Kevin Kofler

[Tom Tromey]

> >>>> "Kevin" == Kevin Kofler
> <kevin.kofler(a)chello.at&gt; writes: 
> > Closing a bug report with "report it upstream" is a let
> down. It's
> > repetitive boring work that a computer should be doing. 
Kevin> There's no way we can fix them all by ourselves, the only way
Kevin> to actually get things fixed is to report them to the actual
Kevin> upstream maintainers of the concrete application you're having
Kevin> issues with. And I don't think KDE is the only set of packages
Kevin> in this situation.

What would be good here is an easy way to push a report upstream.

This would solve the Fedora maintainer's problem ("this is not our
bug") without requiring extra work from the bug reporter (who is
probably lazy like me, and anyway isn't in as good a position to
triage a report as the Fedora maintainer).

Tom

[Ian Malone]

Tom Tromey wrote:
> >>>>> "Kevin" == Kevin Kofler
> <kevin.kofler(a)chello.at&gt; writes:
>  
> >> Closing a bug report with "report it upstream" is a let down. It's
> >> repetitive boring work that a computer should be doing.
>  
>  Kevin> There's no way we can fix them all by ourselves, the only way
>  Kevin> to actually get things fixed is to report them to the actual
>  Kevin> upstream maintainers of the concrete application you're having
>  Kevin> issues with. And I don't think KDE is the only set of packages
>  Kevin> in this situation.
>  
>  What would be good here is an easy way to push a report upstream.
>  
>  This would solve the Fedora maintainer's problem ("this is not our
>  bug") without requiring extra work from the bug reporter (who is
>  probably lazy like me, and anyway isn't in as good a position to
>  triage a report as the Fedora maintainer).
>   
Seconded.

As a Fedora end user, rather than a developer, if I report a bug
to Fedora BZ and get told to put it upstream I then have to go and
get a BZ account for upstream.  That may seem trivial but I now
have accounts on quite a few BZs, each of which was only used to
report one or two bugs.

No, the maintainer shouldn't have to act as a proxy, but it would
be nice to have some automated mechanism that would.

-- 
imalone

[Ralf Corsepius]

On Wed, 2008-01-23 at 22:41 +0000, Ian Malone wrote:
>  Tom Tromey wrote:
>  >>>>>> "Kevin" == Kevin Kofler <kevin.kofler(a)chello.at&gt;
> writes:
>  > 
>  >>> Closing a bug report with "report it upstream" is a let down.
> It's
>  >>> repetitive boring work that a computer should be doing.
>  > 
>  > Kevin> There's no way we can fix them all by ourselves, the only way
>  > Kevin> to actually get things fixed is to report them to the actual
>  > Kevin> upstream maintainers of the concrete application you're having
>  > Kevin> issues with. And I don't think KDE is the only set of packages
>  > Kevin> in this situation.
>  > 
>  > What would be good here is an easy way to push a report upstream. 
>  No, the maintainer shouldn't have to act as a proxy,
Maintainers should "maintain" their packages, not simply "package
them
up" .

>   but it would
>  be nice to have some automated mechanism that would. 
IIRC, Debian once had tried
this - It had never really worked. 
Those reports ended up being ignored.

Ralf

[nodata]

Am Samstag, den 19.01.2008, 20:05 +0000 schrieb Kevin Kofler:
>  nodata <lsof <at> nodata.co.uk> writes:
>  > Fedora does a lot better, much better, but probably the most annoying
>  > aspect of using Fedora's bugzilla is the attitude of some of the
>  > maintainers (not all) and the "closing, report upstream" attitude.
>  > 
>  > Closing a bug report with "report it upstream" is a let down. It's
>  > repetitive boring work that a computer should be doing.
>  
>  We're 4 maintainers for all of KDE in Fedora (and that's already 4 times as 
>  many as not too long ago). We get dozens of bug reports, many of which aren't 
>  specific to Fedora in any way. There's no way we can fix them all by ourselves, 
>  the only way to actually get things fixed is to report them to the actual 
>  upstream maintainers of the concrete application you're having issues with. And 
>  I don't think KDE is the only set of packages in this situation.
>  
>          Kevin Kofler
>   
Then don't let people report the bugs into the Fedora bugzilla.

[Jon Stanley]

On Jan 19, 2008 4:17 PM, nodata <lsof(a)nodata.co.uk&gt; wrote:

>  Then don't let people report the bugs into the Fedora bugzilla.
That's not particularly an option, either, since there could be distro
specific or packaging bugs that the 4 maintainers did introduce.  In
this case, I think that the best thing to do is to inform the triage
community (wouldn't be me for KDE since I don't know anything about
it) that the maintainers do not accept bugs which could be reported
upstream, and that the triagers should go ahead and report them
upstream.  Leads to good results for all people - the users that get
some sort of a response, and the maintainers who don't have to worry
about non-packaging bugs.

This is what a good triage team is meant to do - serve as a bridge
between the end-user community and the community of maintainers for a
given set of packages.

[Rex Dieter]

Jon Stanley wrote:

>  On Jan 19, 2008 4:17 PM, nodata <lsof(a)nodata.co.uk&gt; wrote:
>  
> > Then don't let people report the bugs into the Fedora bugzilla.
>  
>  That's not particularly an option, either, since there could be distro
>  specific or packaging bugs that the 4 maintainers did introduce.  
+1

>  > In 
>  this case, I think that the best thing to do is to inform the triage
>  community (wouldn't be me for KDE since I don't know anything about
>  it) that the maintainers do not accept bugs which could be reported
>  upstream, and that the triagers should go ahead and report them
>  upstream.  Leads to good results for all people - the users that get
>  some sort of a response, and the maintainers who don't have to worry
>  about non-packaging bugs. 
Yes and no, sometimes bugs cannot be reproduced by anyone other than the
reporter.  What then?  

Besides, encouraging users to work with upstream aligns well with fedora's
values, which I consider to be a "good thing"(tm).

-- Rex
 
p.s. I *like* to see feedback that stuff has been upstreamed, and usually
make sure I'm Cc'd there too, to track progress, etc..

[Jon Stanley]

2008/1/18 Jesse Keating <jkeating(a)redhat.com&gt;:
>  http://glyphobet.net/blog/?p=140 
Read and taken to heart.  While I *am* posting metrics on our bug
situation, I also understand that doing things just to get those
numbers down serves no goal that we want to achieve.   Instead, the
primary motivation for the metrics is to allow potential and current
triagers to rise above the "suck threshold" as John Poelstra pointed
out - contributors need to see the fact that they are making a
difference.  I think that my goals and those purportedly held by
Ubuntu are two very different things - Ubuntu wants to close bugs for
the sake of closing bugs, I want to make sure things get fixed and the
distribution can improve because of that.  The most important thing is
that no users have the experience referenced in the above post.