Re: Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Oliver Falk]

I had similar issues already and I totally agree with Christoph!
The maintainer should not redirect the bugreporter to the upstream bugreporting plattform.
I already have plenty of accounts on upstream bugzillas because of exactly this...

-of

Christoph Wickert <christoph.wickert(a)googlemail.com&gt; schrieb:

> I am irritated by the way the KDE SIG and the KDE bugzappers handle
> bugs. For most bugs that are reported they demand the reporter to file
> an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If
> the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But
> if the bug has been reported upstream, the Fedora bug gets closed
> UPSTREAM. Ether way, the bug gets closed, no matter if it was actually
> fixed or not.
>
> IMHO filing bugs upstream is a maintainers duty. We are doing the same
> in Xfce or I do the same with all my packages. The only exception I make
> are feature requests, because I cannot support a request that I don't
> understand or that I am not convinced of. The use of a feature should be
> discussed upstream with the developers because they are in no way
> specific to the distribution, but bugs that affect Fedora need to be
> tracked in Fedora.
>
> The wiki says:
> > Deal with reported bugs in a timely manner 
> >       * [...]
> >       * If there are bugs which you aren't capable of fixing yourself
> >         because they deal with intricacies of the source code which
> >         you don't fully understand, then you still need to address
> >         these bugs. It can be helpful to work with the upstream
> >         maintainer of the code, obtain help from more code-oriented
> >         people on fedora-devel, or check other distributions for
> >         patches. Always be sure to post to the bug report what you
> >         have done so that the reporter knows what it happening and
> >         what to expect. It is recommended that non-coder packagers
> >         should find co-maintainers who are familiar with the
> >         programming language used by their package(s), and can help
> >         with such bugs as a kind of 'second line support'.
>
> https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_w...
>
> The Fedora KDE maintainers and bugzappers already have a KDE bugzilla
> account, while most of our users don't. Thus it is easier for them to
> file the bug than it is for the user. The maintainer has to act as a
> proxy between the reporter and the developer. 
>
> By closing down the bugs, our bugzilla is effectively rendered useless
> because there is no way of searching for bugs that affect our KDE
> packages. Bugzilla is for tracking bugs, not for blindly closing bug
> reports no matter if they are fixed or not!
>
> I'd like the KDE SIG and their bugzappers to reconsider their policy:
>      1. Forward bugs to the upstream developers
>      2. Leave bugs open until they are fixed upstream and in Fedora
>
> Regards,
> Christoph
>
> -- 
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Monday 29 March 2010 13:38:52 Oliver Falk wrote:
>  I had similar issues already and I totally agree with Christoph!
>  The maintainer should not redirect the bugreporter to the upstream
>  bugreporting plattform. I already have plenty of accounts on upstream
>  bugzillas because of exactly this... 
Me too. Maybe Open ID support in common Bugzilla instances should work. And I 
said it - if you don't want to report it upstream (even it's upstream bug and 
belongs to upstream Bugzilla) just asked some KDE SIG members to take care. We 
will never say no (except rude replies). I think transparency is what we need, 
not bouncing bugs around - it takes time both reporter and rh/kde assignee and 
leads to slower bug resolution...

Jaroslav 

>  -of
>  
>  Christoph Wickert <christoph.wickert(a)googlemail.com&gt; schrieb:
>  >I am irritated by the way the KDE SIG and the KDE bugzappers handle
>  >bugs. For most bugs that are reported they demand the reporter to file
>  >an upstream bug report at bugs.kde.org and set the bug to NEEDINFO. If
>  >the reporter doesn't respond, the bug is closed NOTABUG or WONTFIX. But
>  >if the bug has been reported upstream, the Fedora bug gets closed
>  >UPSTREAM. Ether way, the bug gets closed, no matter if it was actually
>  >fixed or not.
>  >
>  >IMHO filing bugs upstream is a maintainers duty. We are doing the same
>  >in Xfce or I do the same with all my packages. The only exception I make
>  >are feature requests, because I cannot support a request that I don't
>  >understand or that I am not convinced of. The use of a feature should be
>  >discussed upstream with the developers because they are in no way
>  >specific to the distribution, but bugs that affect Fedora need to be
>  >tracked in Fedora.
>  >
>  >The wiki says:
>  >> Deal with reported bugs in a timely manner
>  >> 
>  >>       * [...]
>  >>       * If there are bugs which you aren't capable of fixing yourself
>  >>       
>  >>         because they deal with intricacies of the source code which
>  >>         you don't fully understand, then you still need to address
>  >>         these bugs. It can be helpful to work with the upstream
>  >>         maintainer of the code, obtain help from more code-oriented
>  >>         people on fedora-devel, or check other distributions for
>  >>         patches. Always be sure to post to the bug report what you
>  >>         have done so that the reporter knows what it happening and
>  >>         what to expect. It is recommended that non-coder packagers
>  >>         should find co-maintainers who are familiar with the
>  >>         programming language used by their package(s), and can help
>  >>         with such bugs as a kind of 'second line support'.
>  >
>  >https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_wi
>  >th_reported_bugs_in_a_timely_manner
>  >
>  >The Fedora KDE maintainers and bugzappers already have a KDE bugzilla
>  >account, while most of our users don't. Thus it is easier for them to
>  >file the bug than it is for the user. The maintainer has to act as a
>  >proxy between the reporter and the developer.
>  >
>  >By closing down the bugs, our bugzilla is effectively rendered useless
>  >because there is no way of searching for bugs that affect our KDE
>  >packages. Bugzilla is for tracking bugs, not for blindly closing bug
>  >reports no matter if they are fixed or not!
>  >
>  >I'd like the KDE SIG and their bugzappers to reconsider their policy:
>  >     1. Forward bugs to the upstream developers
>  >     2. Leave bugs open until they are fixed upstream and in Fedora
>  >
>  >Regards,
>  >Christoph 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michał Piotrowski]

2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
>  I had similar issues already and I totally agree with Christoph!
>  The maintainer should not redirect the bugreporter to the upstream bugreporting
> plattform. I already have plenty of accounts on upstream bugzillas because of exactly
> this...
>  
I don't see any problem here if KDE SIG just declare "we don't fix KDE
bugs, we just update packages".

They are not KDE developers, so they don't know how to fix these bugs.

Regards,
Michal

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Yaakov Nemoy]

2010/3/29 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
> > I had similar issues already and I totally agree with Christoph!
> > The maintainer should not redirect the bugreporter to the upstream bugreporting
> plattform. I already have plenty of accounts on upstream bugzillas because of exactly
> this...
> >
>
>  I don't see any problem here if KDE SIG just declare "we don't fix KDE
>  bugs, we just update packages".
>
>  They are not KDE developers, so they don't know how to fix these bugs. 
This response regardless, as a downstream user of a package, if i
report a bug, it's nice to know if it's going to be fixed in a current
release or not. Until the upstream bugfix lands in a package
downstream, downstream should leave the bug open. The bug can be used
to track an update from bodhi too, and even suggest to the user that
he download a package out of testing to see that it is fixed. Without
the maintainers acting as the man in the middle, a potential bug
reporter not only has to open an account with the KDE bug tracker, but
then he might be asked to download source code, build it on his own,
and do a number of other hassles to help upstream out. The maintainers
can assist this by helping with test builds and so on. It's their
responsibility, otherwise to track the issue upstream, regardless
whether they are active developers.

-Yaakov

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
>  2010/3/29 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  > 2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
>  >> I had similar issues already and I totally agree with Christoph!
>  >> The maintainer should not redirect the bugreporter to the upstream
>  >> bugreporting plattform. I already have plenty of accounts on upstream
>  >> bugzillas because of exactly this...
>  > 
>  > I don't see any problem here if KDE SIG just declare "we don't fix KDE
>  > bugs, we just update packages".
>  > 
>  > They are not KDE developers, so they don't know how to fix these bugs.
>  
>  This response regardless, as a downstream user of a package, if i
>  report a bug, it's nice to know if it's going to be fixed in a current
>  release or not. Until the upstream bugfix lands in a package
>  downstream, downstream should leave the bug open.  
Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution. It's 
just terminology - I would prefer another one - like just UPSTREAM status, or 
ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does not mean that 
nobody cares! It's still tracked!

>  The bug can be used
>  to track an update from bodhi too 
It's used to track in Bodhi.

>  and even suggest to the user that
>  he download a package out of testing to see that it is fixed. Without
>  the maintainers acting as the man in the middle, a potential bug
>  reporter not only has to open an account with the KDE bug tracker, but
>  then he might be asked to download source code, build it on his own,
>  and do a number of other hassles to help upstream out. 
>  The maintainers
>  can assist this by helping with test builds and so on. It's their
>  responsibility, otherwise to track the issue upstream, regardless
>  whether they are active developers.
>  
Usually we do this, we provide testing packages etc. But not only on Fedora 
side but both sides. 

Jaroslav

>  -Yaakov 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Yaakov Nemoy]

2010/3/29 Jaroslav Reznik <jreznik(a)redhat.com&gt;:
>  On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
> > 2010/3/29 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
> > > 2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
> > >> I had similar issues already and I totally agree with Christoph!
> > >> The maintainer should not redirect the bugreporter to the upstream
> > >> bugreporting plattform. I already have plenty of accounts on upstream
> > >> bugzillas because of exactly this...
> > >
> > > I don't see any problem here if KDE SIG just declare "we don't fix
> KDE
> > > bugs, we just update packages".
> > >
> > > They are not KDE developers, so they don't know how to fix these bugs.
> >
> > This response regardless, as a downstream user of a package, if i
> > report a bug, it's nice to know if it's going to be fixed in a current
> > release or not. Until the upstream bugfix lands in a package
> > downstream, downstream should leave the bug open.
>
>  Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution. It's
>  just terminology - I would prefer another one - like just UPSTREAM status, or
>  ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does not mean that
>  nobody cares! It's still tracked! 
Sure, it's good to know that it's tracked. Maybe we should think about
modifying the policy to make this more transparent. Perhaps a 'ON HOLD
- UPSTREAM'.

> > The bug can be used
> > to track an update from bodhi too
>
>  It's used to track in Bodhi.
>
> > and even suggest to the user that
> > he download a package out of testing to see that it is fixed. Without
> > the maintainers acting as the man in the middle, a potential bug
> > reporter not only has to open an account with the KDE bug tracker, but
> > then he might be asked to download source code, build it on his own,
> > and do a number of other hassles to help upstream out.
> > The maintainers
> > can assist this by helping with test builds and so on. It's their
> > responsibility, otherwise to track the issue upstream, regardless
> > whether they are active developers.
> >
>
>  Usually we do this, we provide testing packages etc. But not only on Fedora
>  side but both sides. 
Ah cool. Still, it's something that is general to theoretically all
maintainers. I don't want to mandate this, because ultimately
maintainers are volunteers in the end.


-Yaakov

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Monday 29 March 2010 14:16:55 Yaakov Nemoy wrote:
>  2010/3/29 Jaroslav Reznik <jreznik(a)redhat.com&gt;:
>  > On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
>  >> 2010/3/29 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  >> > 2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
>  >> >> I had similar issues already and I totally agree with Christoph!
>  >> >> The maintainer should not redirect the bugreporter to the upstream
>  >> >> bugreporting plattform. I already have plenty of accounts on upstream
>  >> >> bugzillas because of exactly this...
>  >> > 
>  >> > I don't see any problem here if KDE SIG just declare "we don't
> fix KDE
>  >> > bugs, we just update packages".
>  >> > 
>  >> > They are not KDE developers, so they don't know how to fix these bugs.
>  >> 
>  >> This response regardless, as a downstream user of a package, if i
>  >> report a bug, it's nice to know if it's going to be fixed in a current
>  >> release or not. Until the upstream bugfix lands in a package
>  >> downstream, downstream should leave the bug open.
>  > 
>  > Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution.
>  > It's just terminology - I would prefer another one - like just UPSTREAM
>  > status, or ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does
>  > not mean that nobody cares! It's still tracked!
>  
>  Sure, it's good to know that it's tracked. Maybe we should think about
>  modifying the policy to make this more transparent. Perhaps a 'ON HOLD
>  - UPSTREAM'. 
+1! Just terminology but looks much more better!

Jaroslav

>  >> The bug can be used
>  >> to track an update from bodhi too
>  > 
>  > It's used to track in Bodhi.
>  > 
>  >> and even suggest to the user that
>  >> he download a package out of testing to see that it is fixed. Without
>  >> the maintainers acting as the man in the middle, a potential bug
>  >> reporter not only has to open an account with the KDE bug tracker, but
>  >> then he might be asked to download source code, build it on his own,
>  >> and do a number of other hassles to help upstream out.
>  >> The maintainers
>  >> can assist this by helping with test builds and so on. It's their
>  >> responsibility, otherwise to track the issue upstream, regardless
>  >> whether they are active developers.
>  > 
>  > Usually we do this, we provide testing packages etc. But not only on
>  > Fedora side but both sides.
>  
>  Ah cool. Still, it's something that is general to theoretically all
>  maintainers. I don't want to mandate this, because ultimately
>  maintainers are volunteers in the end.
>  
>  
>  -Yaakov 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/29/2010 02:11 PM, Jaroslav Reznik wrote:
>  On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
> > 2010/3/29 Michał Piotrowski<mkkp4x4(a)gmail.com>:
> >> 2010/3/29 Oliver Falk<oliver(a)linux-kernel.at>:
> >>> I had similar issues already and I totally agree with Christoph!
> >>> The maintainer should not redirect the bugreporter to the upstream
> >>> bugreporting plattform. I already have plenty of accounts on upstream
> >>> bugzillas because of exactly this...
> >>
> >> I don't see any problem here if KDE SIG just declare "we don't fix
> KDE
> >> bugs, we just update packages".
> >>
> >> They are not KDE developers, so they don't know how to fix these bugs.
> >
> > This response regardless, as a downstream user of a package, if i
> > report a bug, it's nice to know if it's going to be fixed in a current
> > release or not. Until the upstream bugfix lands in a package
> > downstream, downstream should leave the bug open.
>
>  Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution. It's
>  just terminology - I would prefer another one - like just UPSTREAM status, or
>  ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does not mean that
>  nobody cares! It's still tracked! 
Pardon, but I strongly have to disagree with this interpretation.

As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing but a 
cheap bold lie packagers use as weak excuse to for not being able to fix 
a bug having hit a user.

In other words: "FIXED UPSTREAM" does not fix anything for the user 
struggling with a bug. It only helps the packager to keep his bug 
statistics clean.

Analogous considerations apply to "FIXED RAWHIDE"

Both bugzilla tags should be banned.

Ralf

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Monday 29 March 2010 14:20:57 Ralf Corsepius wrote:
>  On 03/29/2010 02:11 PM, Jaroslav Reznik wrote:
>  > On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
>  >> 2010/3/29 Michał Piotrowski<mkkp4x4(a)gmail.com>:
>  >>> 2010/3/29 Oliver Falk<oliver(a)linux-kernel.at>:
>  >>>> I had similar issues already and I totally agree with Christoph!
>  >>>> The maintainer should not redirect the bugreporter to the upstream
>  >>>> bugreporting plattform. I already have plenty of accounts on upstream
>  >>>> bugzillas because of exactly this...
>  >>> 
>  >>> I don't see any problem here if KDE SIG just declare "we don't
> fix KDE
>  >>> bugs, we just update packages".
>  >>> 
>  >>> They are not KDE developers, so they don't know how to fix these bugs.
>  >> 
>  >> This response regardless, as a downstream user of a package, if i
>  >> report a bug, it's nice to know if it's going to be fixed in a current
>  >> release or not. Until the upstream bugfix lands in a package
>  >> downstream, downstream should leave the bug open.
>  > 
>  > Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution.
>  > It's just terminology - I would prefer another one - like just UPSTREAM
>  > status, or ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does
>  > not mean that nobody cares! It's still tracked!
>  
>  Pardon, but I strongly have to disagree with this interpretation.
>  
>  As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing but a
>  cheap bold lie packagers use as weak excuse to for not being able to fix
>  a bug having hit a user. 
Indeed - we are not able to fix all bugs on our own. So we work with upstream. 
I said - I don't like to call it "CLOSED". It's not closed, it's
still opened 
issue.

>  In other words: "FIXED UPSTREAM" does not fix anything for
> the user
>  struggling with a bug. It only helps the packager to keep his bug
>  statistics clean. 
We usually don't use it - or I don't remember - if the CLOSED UPSTREAM bug is 
fixed upstream, it's a) backported or b) updated and closed by Bodhi.

Jaroslav

>  Analogous considerations apply to "FIXED RAWHIDE"
>  
>  Both bugzilla tags should be banned.
>  
>  Ralf 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Till Maas]

On Mon, Mar 29, 2010 at 02:20:57PM +0200, Ralf Corsepius wrote:

>  As a user, having been hit by a bug, "CLOSED UPSTREAM" is
> nothing but a 
>  cheap bold lie packagers use as weak excuse to for not being able to fix 
>  a bug having hit a user.
>  
>  In other words: "FIXED UPSTREAM" does not fix anything for the user 
>  struggling with a bug. It only helps the packager to keep his bug 
>  statistics clean. 
Yum related bugs are also closed with upstream, but still the Bodhi
update details contain the bug number, once the update upstream package
makes it's way into Fedora. Then everyone on the CC list of the Fedora
bug will also not notified once the update is there. Except that these
bugs do not show up in searches for open bugs, I do not see anything bad
with this approach.

Regards
Till

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Yaakov Nemoy]

2010/3/29 Till Maas <opensource(a)till.name&gt;:
>  On Mon, Mar 29, 2010 at 02:20:57PM +0200, Ralf Corsepius wrote:
>
> > As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing but a
> > cheap bold lie packagers use as weak excuse to for not being able to fix
> > a bug having hit a user.
> >
> > In other words: "FIXED UPSTREAM" does not fix anything for the user
> > struggling with a bug. It only helps the packager to keep his bug
> > statistics clean.
>
>  Yum related bugs are also closed with upstream, but still the Bodhi
>  update details contain the bug number, once the update upstream package
>  makes it's way into Fedora. Then everyone on the CC list of the Fedora
>  bug will also not notified once the update is there. Except that these
>  bugs do not show up in searches for open bugs, I do not see anything bad
>  with this approach. 
If you define the terminology around the actual process first, then
define the processes around good terminology, it's much easier to get
it right and not confuse people. Fitting the process and terminology
around someone else's design, and you run into trouble. I'm suggesting
we have clearer naming, so a search can be done both on open issues
that are waiting on upstream and a way to filter them out for people
looking for truely open bugs waiting on Fedora / Red Hat. In this case
the terminology is somewhat incorrect. The methodology sounds correct
to me too, i just suggest we name the statuses properly rather than
defining a special case of 'closed' that's counter intuitive and makes
people upset.

-Yaakov

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Mon, 2010-03-29 at 14:20 +0200, Ralf Corsepius wrote:

>  As a user, having been hit by a bug, "CLOSED UPSTREAM" is
> nothing but a 
>  cheap bold lie packagers use as weak excuse to for not being able to fix 
>  a bug having hit a user.
>  
>  In other words: "FIXED UPSTREAM" does not fix anything for the user 
>  struggling with a bug. It only helps the packager to keep his bug 
>  statistics clean.
>  
>  Analogous considerations apply to "FIXED RAWHIDE" 
It's CLOSED UPSTREAM and CLOSED RAWHIDE, not FIXED UPSTREAM and FIXED
RAWHIDE. CLOSED does not, necessarily, mean FIXED.

>  Both bugzilla tags should be banned. 
CLOSED RAWHIDE is intended to be used for...Rawhide. It would be silly
to ban it. What would we then close Rawhide bugs as?

The workflow page already says that closing bugs filed against stable
releases with the RAWHIDE resolution is not valid, and I do point this
out when I come across it. If the maintainer does not intend to fix the
bug in the stable release, it should be set to CLOSED WONTFIX (or CLOSED
CANTFIX) with an explanation of why, and a note that the fix is in
Rawhide.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/31/2010 01:36 AM, Adam Williamson wrote:
>  On Mon, 2010-03-29 at 14:20 +0200, Ralf Corsepius wrote:
>
> > As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing but a
> > cheap bold lie packagers use as weak excuse to for not being able to fix
> > a bug having hit a user.
> >
> > In other words: "FIXED UPSTREAM" does not fix anything for the user
> > struggling with a bug. It only helps the packager to keep his bug
> > statistics clean.
> >
> > Analogous considerations apply to "FIXED RAWHIDE"
>
>  It's CLOSED UPSTREAM and CLOSED RAWHIDE, not FIXED UPSTREAM and FIXED
>  RAWHIDE. CLOSED does not, necessarily, mean FIXED. 
Then let me put it more bluntly:
To a Fedora release's user, both tags 
are a slap into the face of "reporter" and mean "your bug will not be 
fixed".

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Stephen John Smoogen]

On Tue, Mar 30, 2010 at 8:04 PM, Ralf Corsepius <rc040203(a)freenet.de&gt; wrote:
>  On 03/31/2010 01:36 AM, Adam Williamson wrote:
> > On Mon, 2010-03-29 at 14:20 +0200, Ralf Corsepius wrote:
> >
> >> As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing but
> a
> >> cheap bold lie packagers use as weak excuse to for not being able to fix
> >> a bug having hit a user.
> >>
> >> In other words: "FIXED UPSTREAM" does not fix anything for the user
> >> struggling with a bug. It only helps the packager to keep his bug
> >> statistics clean.
> >>
> >> Analogous considerations apply to "FIXED RAWHIDE"
> >
> > It's CLOSED UPSTREAM and CLOSED RAWHIDE, not FIXED UPSTREAM and FIXED
> > RAWHIDE. CLOSED does not, necessarily, mean FIXED.
>  Then let me put it more bluntly: To a Fedora release's user, both tags
>  are a slap into the face of "reporter" and mean "your bug will not be
>  fixed".
>  
I am about to call down lightening and thunder on me.. but I will be
agreeing with the general sentiment that Ralf has. The naming
convention comes from a time in 1998 when developers were swamped and
thought that sending a customer to upstream or rawhide was what anyone
could do. It turned into a somewhat customer support issue as people
do generally feel like they have been given a "pfluog off". It created
a lot more tickets than the bugs that never get looked at all.

It was brought up a couple of times to change the wording to something
else in the early days, but was in general responded that bugzilla was
not a place to coddle people that was what tech support was for. Now
while those people are long gone from Red Hat, anyone using that
bugzilla are 'stuck' with a limited set of choices for closing/fixing
a ticket.

So in general, the terms are not ones that make friends and influence
people. They make a lot of people who have reported bugs not want to
do much with the project again. How to better handle this though is
something that would require cooler heads than I think this current
conversation has :).



-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Yaakov Nemoy]

2010/3/31 Stephen John Smoogen <smooge(a)gmail.com&gt;:
>  On Tue, Mar 30, 2010 at 8:04 PM, Ralf Corsepius
> <rc040203(a)freenet.de&gt; wrote:
> > On 03/31/2010 01:36 AM, Adam Williamson wrote:
> >> On Mon, 2010-03-29 at 14:20 +0200, Ralf Corsepius wrote:
> >>
> >>> As a user, having been hit by a bug, "CLOSED UPSTREAM" is nothing
> but a
> >>> cheap bold lie packagers use as weak excuse to for not being able to fix
> >>> a bug having hit a user.
> >>>
> >>> In other words: "FIXED UPSTREAM" does not fix anything for the
> user
> >>> struggling with a bug. It only helps the packager to keep his bug
> >>> statistics clean.
> >>>
> >>> Analogous considerations apply to "FIXED RAWHIDE"
> >>
> >> It's CLOSED UPSTREAM and CLOSED RAWHIDE, not FIXED UPSTREAM and FIXED
> >> RAWHIDE. CLOSED does not, necessarily, mean FIXED.
> > Then let me put it more bluntly: To a Fedora release's user, both tags
> > are a slap into the face of "reporter" and mean "your bug will not be
> > fixed".
> >
>
>  I am about to call down lightening and thunder on me.. but I will be
>  agreeing with the general sentiment that Ralf has. The naming
>  convention comes from a time in 1998 when developers were swamped and
>  thought that sending a customer to upstream or rawhide was what anyone
>  could do. It turned into a somewhat customer support issue as people
>  do generally feel like they have been given a "pfluog off". It created
>  a lot more tickets than the bugs that never get looked at all.
>
>  It was brought up a couple of times to change the wording to something
>  else in the early days, but was in general responded that bugzilla was
>  not a place to coddle people that was what tech support was for. Now
>  while those people are long gone from Red Hat, anyone using that
>  bugzilla are 'stuck' with a limited set of choices for closing/fixing
>  a ticket.
>
>  So in general, the terms are not ones that make friends and influence
>  people. They make a lot of people who have reported bugs not want to
>  do much with the project again. How to better handle this though is
>  something that would require cooler heads than I think this current
>  conversation has :). 
I tried to make my points with a cool head. I think it's time that we
should consider changing the names.

That said, i have this funny story about these lab monkeys i'll tell
anyone over a beer at the next FUDCon.

-Yaakov

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 07:34 AM, Ralf Corsepius wrote:
>  Then let me put it more bluntly: To a Fedora release's user, both tags 
>  are a slap into the face of "reporter" and mean "your bug will not be 
>  fixed".
>     
So, I get a minor bug report not worth pushing an update for in the
general releases but I fix it in Rawhide, what am I supposed to do? 

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Frank Murphy]

On 31/03/10 09:44, Rahul Sundaram wrote:
>  On 03/31/2010 07:34 AM, Ralf Corsepius wrote:
> >
> > Then let me put it more bluntly: To a Fedora release's user, both tags
> > are a slap into the face of "reporter" and mean "your bug will not be
> > fixed".
> >
>
>  So, I get a minor bug report not worth pushing an update for in the
>  general releases but I fix it in Rawhide, what am I supposed to do?
>
>  Rahul 
Then ask the user Could you try "yum --enablerepo=rawhide update foo"

I know it's not always possible/advisable.
But for that user can he wait maybe 2 releases to get the fix?


-- 
Regards,

Frank Murphy
UTF_8 Encoded, Fedora.x86_64

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 02:38 PM, Frank Murphy wrote:
>  Then ask the user Could you try "yum --enablerepo=rawhide update foo"
>     
> From Fedora 13 onwards, this repo is not even installed by default
because users quite often used to enable this accidentally and had to
reinstall their systems.

>  I know it's not always possible/advisable.
>  But for that user can he wait maybe 2 releases to get the fix?
>     
So, why can't I close it against Rawhide?

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Frank Murphy]

On 31/03/10 10:10, Rahul Sundaram wrote:
>  On 03/31/2010 02:38 PM, Frank Murphy wrote:
> >
> > Then ask the user Could you try "yum --enablerepo=rawhide update foo"
> >
>
> > From Fedora 13 onwards, this repo is not even installed by default 
which will make fixing bugs in current even more important.

>  because users quite often used to enable this accidentally and had
> to
>  reinstall their systems.
>
> > I know it's not always possible/advisable.
> > But for that user can he wait maybe 2 releases to get the fix?
> >
>
>  So, why can't I close it against Rawhide?
>  
No reason, if fixed for current version,
or as above.


>  Rahul 

-- 
Regards,

Frank Murphy
UTF_8 Encoded, Fedora.x86_64

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  which will make fixing bugs in current even more important.
>     
Not at all.  Either the bug is important to fix in the current release
or it is not.  Telling users to get it from Rawhide was never a valid
resolution.  It is a workaround in some very small cases.

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
>  On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  > which will make fixing bugs in current even more important.
>  
>  Not at all.  Either the bug is important to fix in the current release
>  or it is not.  Telling users to get it from Rawhide was never a valid
>  resolution.  It is a workaround in some very small cases. 
For example bug report - typo in SPEC file - it should be fixed in Rawhide, but 
no need to push this update to current releases.

Jaroslav
 
>  Rahul 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Frank Murphy]

On 31/03/10 11:50, Jaroslav Reznik wrote:
>  On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
> > On 03/31/2010 03:45 PM, Frank Murphy wrote:
> >> which will make fixing bugs in current even more important.
> >
> > Not at all.  Either the bug is important to fix in the current release
> > or it is not.  Telling users to get it from Rawhide was never a valid
> > resolution.  It is a workaround in some very small cases.
>
>  For example bug report - typo in SPEC file - it should be fixed in Rawhide, but
>  no need to push this update to current releases.
>
>  
But why would an end user be worried about a typo in a spec file?


-- 
Regards,

Frank Murphy
UTF_8 Encoded, Fedora.x86_64

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 12:55:58 Frank Murphy wrote:
>  On 31/03/10 11:50, Jaroslav Reznik wrote:
>  > On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
>  >> On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  >>> which will make fixing bugs in current even more important.
>  >> 
>  >> Not at all.  Either the bug is important to fix in the current release
>  >> or it is not.  Telling users to get it from Rawhide was never a valid
>  >> resolution.  It is a workaround in some very small cases.
>  > 
>  > For example bug report - typo in SPEC file - it should be fixed in
>  > Rawhide, but no need to push this update to current releases.
>  
>  But why would an end user be worried about a typo in a spec file? 
Other developer, not provenpackager one?

Jaroslav

-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Frank Murphy]

On 31/03/10 12:25, Jaroslav Reznik wrote:
>  On Wednesday 31 March 2010 12:55:58 Frank Murphy wrote:
> > On 31/03/10 11:50, Jaroslav Reznik wrote:
> >> On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
> >>> On 03/31/2010 03:45 PM, Frank Murphy wrote:
> >>>> which will make fixing bugs in current even more important.
> >>>
> >>> Not at all.  Either the bug is important to fix in the current release
> >>> or it is not.  Telling users to get it from Rawhide was never a valid
> >>> resolution.  It is a workaround in some very small cases.
> >>
> >> For example bug report - typo in SPEC file - it should be fixed in
> >> Rawhide, but no need to push this update to current releases.
> >
> > But why would an end user be worried about a typo in a spec file?
>
>  Other developer, not provenpackager one?
>
>  Jaroslav
>  
But isn't the run of the thread about "normal user" and bugs.
Closing or otherwise.

-- 
Regards,

Frank Murphy
UTF_8 Encoded, Fedora.x86_64

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 13:32:24 Frank Murphy wrote:
>  On 31/03/10 12:25, Jaroslav Reznik wrote:
>  > On Wednesday 31 March 2010 12:55:58 Frank Murphy wrote:
>  >> On 31/03/10 11:50, Jaroslav Reznik wrote:
>  >>> On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
>  >>>> On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  >>>>> which will make fixing bugs in current even more important.
>  >>>> 
>  >>>> Not at all.  Either the bug is important to fix in the current release
>  >>>> or it is not.  Telling users to get it from Rawhide was never a valid
>  >>>> resolution.  It is a workaround in some very small cases.
>  >>> 
>  >>> For example bug report - typo in SPEC file - it should be fixed in
>  >>> Rawhide, but no need to push this update to current releases.
>  >> 
>  >> But why would an end user be worried about a typo in a spec file?
>  > 
>  > Other developer, not provenpackager one?
>  > 
>  > Jaroslav
>  
>  But isn't the run of the thread about "normal user" and bugs.
>  Closing or otherwise. 
Who is "normal", "ordinary" user? Remembers me an election campaign in
Czech 
rep right now. I hope I'm not that one "ordinary man" as targeted by one
party 
;-)

The typo issue was only example, even "ordinary" (I don't like it) users
could 
fill bug report that there's possibility to fix it in Rawhide only. Not 
everything can be backported etc...

Jaroslav
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michal Hlavinka]

On Wednesday 31 March 2010 12:50:10 Jaroslav Reznik wrote:
>  On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
>  > On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  > > which will make fixing bugs in current even more important.
>  > 
>  > Not at all.  Either the bug is important to fix in the current release
>  > or it is not.  Telling users to get it from Rawhide was never a valid
>  > resolution.  It is a workaround in some very small cases.
>  
>  For example bug report - typo in SPEC file - it should be fixed in Rawhide,
>  but no need to push this update to current releases. 
Well, I was thinking about example too, but for this case I usually fix all 
releases, and leave bug in modified. This way all people get the fix later 
when something more important comes.

Michal

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 12:57:30 Michal Hlavinka wrote:
>  On Wednesday 31 March 2010 12:50:10 Jaroslav Reznik wrote:
>  > On Wednesday 31 March 2010 12:26:17 Rahul Sundaram wrote:
>  > > On 03/31/2010 03:45 PM, Frank Murphy wrote:
>  > > > which will make fixing bugs in current even more important.
>  > > 
>  > > Not at all.  Either the bug is important to fix in the current release
>  > > or it is not.  Telling users to get it from Rawhide was never a valid
>  > > resolution.  It is a workaround in some very small cases.
>  > 
>  > For example bug report - typo in SPEC file - it should be fixed in
>  > Rawhide, but no need to push this update to current releases.
>  
>  Well, I was thinking about example too, but for this case I usually fix all
>  releases, and leave bug in modified. This way all people get the fix later
>  when something more important comes. 
This goes to current release every Rawhide sync (applies for KDE).

Jaroslav

>  Michal 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/31/2010 10:44 AM, Rahul Sundaram wrote:
>  On 03/31/2010 07:34 AM, Ralf Corsepius wrote:
> >
> > Then let me put it more bluntly: To a Fedora release's user, both tags
> > are a slap into the face of "reporter" and mean "your bug will not be
> > fixed".
> >
>
>  So, I get a minor bug report not worth pushing an update for in the
>  general releases but I fix it in Rawhide, what am I supposed to do? 
My advise: Let common sense rule!

If your "unworthy bug" causes malfunctions somewhere, it is likely 
somebody will not share your opinon about this bug being "not worthy 
updating", but will consider fixing this bug of ultimate priority and 
vital importance.

If your "unworthy bug" doesn't cause malfunctions, you could easily 
close it "WONTFIX" and add a comment.

Ralf

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
>  If your "unworthy bug" doesn't cause malfunctions, you could easily
>  close it "WONTFIX" and add a comment. 
Why do you advocate WONTFIX over FIXED RAWHIDE?  The latter seems the
more accurate status considering that I did fix it in Rawhide.

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/31/2010 11:32 AM, Rahul Sundaram wrote:
>  On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
> >
> >
> > If your "unworthy bug" doesn't cause malfunctions, you could easily
> > close it "WONTFIX" and add a comment.
>
>  Why do you advocate WONTFIX over FIXED RAWHIDE? 
Because it is how s user perceives
it.

His bug is not fixed in the Fedora release he filed the bug against.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 05:50 PM, Ralf Corsepius wrote:
>  On 03/31/2010 11:32 AM, Rahul Sundaram wrote:
> > On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
> >>
> >>
> >> If your "unworthy bug" doesn't cause malfunctions, you could
> easily
> >> close it "WONTFIX" and add a comment.
> >
> > Why do you advocate WONTFIX over FIXED RAWHIDE?
>  Because it is how s user perceives it. 
I don't think engaging in mind reading on behalf of users is a good
argument.  I fixed it in Rawhide and I believe informing the user is
important.  You want me to add a comment and I think the status on
bugzilla should also indicate that.  

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/31/2010 02:28 PM, Rahul Sundaram wrote:
>  On 03/31/2010 05:50 PM, Ralf Corsepius wrote:
>     
> > On 03/31/2010 11:32 AM, Rahul Sundaram wrote:
> >      
> >> On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
> >>        
> >>>
> >>> If your "unworthy bug" doesn't cause malfunctions, you could
> easily
> >>> close it "WONTFIX" and add a comment.
> >>>          
> >> Why do you advocate WONTFIX over FIXED RAWHIDE?
> >>        
> > Because it is how s user perceives it.
> >      
>  I don't think engaging in mind reading on behalf of users is a good
>  argument.  I fixed it in Rawhide and I believe informing the user is
>  important. 
Well this is what I call "cheating the user" and
"maintainer lying at 
themselves about their package's state" and why I consider "FIXED 
RAWHIDE" to be non-helpful.

The maintainer did not fix the bug a "reporter" filed, but left it 
unresolved and fixed another bug: Another incarnation of the same bug 
waiting to hit the users in the next release.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 03/31/2010 06:11 PM, Ralf Corsepius wrote:
>  Well this is what I call "cheating the user" and "maintainer lying at 
>  themselves about their package's state" and why I consider "FIXED 
>  RAWHIDE" to be non-helpful.
>
>  The maintainer did not fix the bug a "reporter" filed, but left it 
>  unresolved and fixed another bug: Another incarnation of the same bug 
>  waiting to hit the users in the next release.
>     
That's just your perception and I don't see any consensus on that.  The
bug is fixed and fixed only in the development branch and this is a
fairly common thing to do for upstream projects as well as
distributions. because the fix is too small or too intrusive. As long as
the user is informed about the reason, the status is just fine.

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jef Spaleta]

On Wed, Mar 31, 2010 at 4:49 AM, Rahul Sundaram <metherid(a)gmail.com&gt; wrote:
>  That's just your perception and I don't see any consensus on
> that.  The
>  bug is fixed and fixed only in the development branch and this is a
>  fairly common thing to do for upstream projects as well as
>  distributions. because the fix is too small or too intrusive. As long as
>  the user is informed about the reason, the status is just fine. 
I'm not sure its always fine. Nor am I sure that its ever a slap in
the face.  The truth is is probably in between.  There is probably
something to be said about tracking deficiencies accurately on a
release by release basis from a non-maintainer point of view.

Unfortunately our ticketing tool doesn't do a great job at this, as we
can't take one ticket and mark multiple release branches it affects
and which of those release branches the fix is provided.


-jef"
<Miracle Max/>It just so happens that your bug here is only MOSTLY
dead. There's a big difference between mostly dead and all dead.
Mostly dead is slightly alive</Miracle Max>
"spaleta

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Juha Tuomala]

On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  Unfortunately our ticketing tool doesn't do a great job at this,
> as we
>  can't take one ticket and mark multiple release branches it affects
>  and which of those release branches the fix is provided. 
that's why there is 'clone' functionality. Use it.


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jef Spaleta]

On Wed, Mar 31, 2010 at 8:15 AM, Juha Tuomala <Juha.Tuomala(a)iki.fi&gt; wrote:
>  that's why there is 'clone' functionality. Use it.
Are you saying that we should all clone every report that we all would
normally close as fixed rawhide?

-jef

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Juha Tuomala]

On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  Are you saying that we should all clone every report that we all
> would
>  normally close as fixed rawhide? 
Are you saying, that everyone facing that bug, should search from 
every release if that has been handled somewhere else other than the 
product in question?

How is it so, that Fedora internal processes differ drastically 
from that what an outsider, a regular user would initially assume?

How the hell some enduser would even know what the wierd term 
'rawhide' stands for? Or wait, was it 'devel'? Right - it depends on 
context.

Sometimes I get a feeling, that Fedora is not even meant for 
'normal' people, not now, not in the future. Currently it certainly 
is not.


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jef Spaleta]

On Wed, Mar 31, 2010 at 8:29 AM, Juha Tuomala <Juha.Tuomala(a)iki.fi&gt; wrote:
>  On Wed, 31 Mar 2010, Jeff Spaleta wrote:
> >
> > Are you saying that we should all clone every report that we all would
> > normally close as fixed rawhide?
>
>  Are you saying, that everyone facing that bug, should search from every
>  release if that has been handled somewhere else other than the product in
>  question? 
No. I'm asking for you to clarify that you feel clone is appropriate
for wide spread use for the specific situation I'm commenting on.  We
are very much stuck in a trap of designing our workflow to fit the
tools we have, instead of designing our tools to fit the workflow we
want. I fully recognize that and I'm sincerely asking if you think as
a matter of policy everyone should be encouraged to clone to as a way
to avoid using fixed rawhide as a closure when updates aren't going to
come down for a specific release.

But you bring up another point about terminology.... We don't all
necessarily agree that each release is itself is a "product"  In fact
Bugzilla doesn't even consider a specific Fedora release as individual
products. The product is Fedora in Bugzilla-speak and the releases are
versions.  its a nuance, but its important to note...we aren't all
using the same terminology to mean the same things. The tools we use
impose there on mental model. People who interact with Bugzilla a lot
may not think about workflow in the same way as someone else.

>  How the hell some enduser would even know what the wierd term
> 'rawhide'
>  stands for? Or wait, was it 'devel'? Right - it depends on context. 
I wouldn't expect them to. I'm certainly not advocating for fixed
rawhide as a reasonable closure or any specific workflow
implementation for that matter. The policy we have now is the best
effort policy we have now.  And with all policy/guidance we can always
look to do better.

I'm asking for a sketch of a policy that would do better at accurately
portraying what deficiencies are alive while still allowing
maintainers to efficiently track which issues they've resolved to
their satisfaction. Till's message about the difficulties inherent in
cloning bug comments are on point.   Cloning seem very cumbersome as a
general policy.  But we can certainly find a way to discuss making it
less cumbersome without getting hot under the collar.

>  Sometimes I get a feeling, that Fedora is not even meant for 'normal'
>  people, not now, not in the future. Currently it certainly is not. 
There's a lot of emotion in those sentences which I'm not really sure
I can do anything constructive with.  We can always try to do better.
 And I think generally speaking that is what people here want to
do...to try to be better. But a lot of the time emotive speech derails
the intent.

-jef

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Juha Tuomala]

On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  No. I'm asking for you to clarify that you feel clone is
> appropriate
>  for wide spread use for the specific situation I'm commenting on.  We
>  are very much stuck in a trap of designing our workflow to fit the
>  tools we have, instead of designing our tools to fit the workflow we
>  want. 
True. If I put myself into enduser's position, she will certainly
only look for the release she has, doesn't find the report among 
50-100 other report and certainly is not going to start looking for 
other releases. Then she gets slapped into face with DUPLICATE and 
her valuable well crafted comments get lost when maintainer didn't 
bother to copy those comments / nyancies into 'right entry'.

I've seen this happen many times. And not being an enduser, I don't 
like it either.

Those are just numbers and some db/disk space, that's all.

>  I fully recognize that and I'm sincerely asking if you think as
>  a matter of policy everyone should be encouraged to clone to as a way
>  to avoid using fixed rawhide as a closure when updates aren't going to
>  come down for a specific release. 
If that remains broken in f11, I'd like to see it cloned there. It 
will show up in queries and prevents duplicates to happen. It saves 
people's time. There are more people wasting time entering those 
duplicates than maintainer saves with current workflow.

It wouldn't get people upset at the front door, those people we 
would like to step ahead and participate. Behaving badly towards 
them through a machine is not going to make them feel that this is a 
community I'd like to join to. Nor report anything again.

>  I'm asking for a sketch of a policy that would do better at
> accurately
>  portraying what deficiencies are alive while still allowing
>  maintainers to efficiently track which issues they've resolved to
>  their satisfaction. 
>  Till's message about the difficulties inherent in cloning bug 
>  comments are on point. 
Yes, he has a point. Imo if the matter is complex and requires a lot 
of comments, that could happen in rawhide entry, other release 
entries could just work as status tracking and have a comment that - 
real, release neutral discussion takes place in 'main bug'. Those 
could even depend on it.

>  Cloning seem very cumbersome as a general policy. 
Yet it happens quite a bit when RHEL is involved.

>  But we can certainly find a way to discuss making it less 
>  cumbersome without getting hot under the collar. 
And that's assumption, towards a person. Why not just let the 
matters argue?

> > Sometimes I get a feeling, that Fedora is not even meant for
> 'normal'
> > people, not now, not in the future. Currently it certainly is not.
>
>  There's a lot of emotion in those sentences which I'm not really sure
>  I can do anything constructive with. 
Where you do you see emotion there? :D That's a fact.

I suggest that if you disagree, make your own field experiments with 
people. I've done mine and they failed. Last one was an economist - 
a friend of mine - that got fed up with Windows he had. He brought 
the whole topic up/idea himself. After some time of trying, he's 
still using windows.

>  We can always try to do better. And I think generally speaking 
>  that is what people here want to do...to try to be better. But a 
>  lot of the time emotive speech derails the intent. 
or getting it derailed by turning the discussion to metadiscussion.

http://fedoraproject.org/wiki/User_base
>  Fedora contributors understand that they may not be representative 
>  of a very large class of users who may find free software serves 
>  their needs as well. By setting the bounds of this larger class, 
>  we can make good decisions about how to make Fedora work well for 
>  as many people as possible, including ourselves
>
>  The Board considers these aspects applicable to the work of the 
>  entire Fedora Project. The Board will encourage process changes 
>  where appropriate to ensure we are meeting the needs of as many 
>  members of this class as possible. 
http://fedoraproject.org/wiki/User_base_-_general_productivity_user
>  They are common to both novice and experts alike 
I think that says quite clearly that we should think those processes 
from enduser's point of view. We know here what the current workflow 
is, what rawhide, those resolutions, etc stands for. Enduser 
doesn't since those are not obvious/clear whatever.

and btw, last time i suggested to get rid of that 'rawhide' because 
it overlaps with 'devel' and is non-obvious, idea got shot down 
'beacuse it fun inside joke'. I guess the bug is in target user 
definition then. :)


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 09:07 -0800, Jeff Spaleta wrote:
>  I'm asking for a sketch of a policy that would do better at
> accurately
>  portraying what deficiencies are alive while still allowing
>  maintainers to efficiently track which issues they've resolved to
>  their satisfaction.  
I've thought about this quite a lot, at both MDV and Fedora, and come to
the conclusion that it's simply not possible to do this with the current
implementation of Bugzilla. There is no really satisfactory way to use
Bugzilla to track issues across multiple distribution releases, that I
can think of. It's not a question of a lack of a policy; we need
improvements to Bugzilla, or a different tool. Launchpad provides a good
model, in this regard (though it is not better than Bugzilla in all
respects).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Garrett Holmstrom]

On 3/31/2010 14:18, Adam Williamson wrote:
>  On Wed, 2010-03-31 at 09:07 -0800, Jeff Spaleta wrote:
> > I'm asking for a sketch of a policy that would do better at accurately
> > portraying what deficiencies are alive while still allowing
> > maintainers to efficiently track which issues they've resolved to
> > their satisfaction.
>
>  I've thought about this quite a lot, at both MDV and Fedora, and come to
>  the conclusion that it's simply not possible to do this with the current
>  implementation of Bugzilla. There is no really satisfactory way to use
>  Bugzilla to track issues across multiple distribution releases, that I
>  can think of. It's not a question of a lack of a policy; we need
>  improvements to Bugzilla, or a different tool. Launchpad provides a good
>  model, in this regard (though it is not better than Bugzilla in all
>  respects). 
The nicest thing that something like Launchpad would provide is separate 
status tracking for each component and release that is affected.  That 
way bugs related to more than one package can easily be marked as such 
so they appear on all the right maintainers' radars, and package 
statuses can be related on a per-release basis.  Separate statuses for 
each part of a bug would make statuses more meaningful.  As an added 
bonus cloning becomes less necessary, too.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 19:31 -0500, Garrett Holmstrom wrote:
>  On 3/31/2010 14:18, Adam Williamson wrote:
>  > On Wed, 2010-03-31 at 09:07 -0800, Jeff Spaleta wrote:
>  >> I'm asking for a sketch of a policy that would do better at accurately
>  >> portraying what deficiencies are alive while still allowing
>  >> maintainers to efficiently track which issues they've resolved to
>  >> their satisfaction.
>  >
>  > I've thought about this quite a lot, at both MDV and Fedora, and come to
>  > the conclusion that it's simply not possible to do this with the current
>  > implementation of Bugzilla. There is no really satisfactory way to use
>  > Bugzilla to track issues across multiple distribution releases, that I
>  > can think of. It's not a question of a lack of a policy; we need
>  > improvements to Bugzilla, or a different tool. Launchpad provides a good
>  > model, in this regard (though it is not better than Bugzilla in all
>  > respects).
>  
>  The nicest thing that something like Launchpad would provide is separate 
>  status tracking for each component and release that is affected.   
Yes, that's exactly what I mean. That's what Bugzilla does not provide,
and Launchpad does. Sorry if this wasn't clear.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Till Maas]

On Wed, Mar 31, 2010 at 07:15:30PM +0300, Juha Tuomala wrote:
>  
>  
>  On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  > Unfortunately our ticketing tool doesn't do a great job at this, as we
>  > can't take one ticket and mark multiple release branches it affects
>  > and which of those release branches the fix is provided.
>  
>  that's why there is 'clone' functionality. Use it. 
Cloning is imho not really helpful, because it also separates the
comments for each bug, e.g. if a bug affects a certain version of a
package that is available in all Fedora releases, than probably all
comments except for the comments regarding only the update for a certain
release need to be mirrored manually to the other bugs afaik. And this
will only cause huge mail spam, because all (co-)maintainers would
receive every comment up to 4 times for Fedora.

Regards
Till

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 19:15 +0300, Juha Tuomala wrote:
>  
>  On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  > Unfortunately our ticketing tool doesn't do a great job at this, as we
>  > can't take one ticket and mark multiple release branches it affects
>  > and which of those release branches the fix is provided.
>  
>  that's why there is 'clone' functionality. Use it. 
No, it's not why there is 'clone' functionality (that was initially
introduced to Bugzilla for different reasons). Using multiple bugs to
track the same issue in multiple releases is a poor workaround for a
lack of functionality in Bugzilla. It's not a really satisfactory
solution.

(Cloning doesn't really do what you want it to do in this case, anyway.
I'm always coming across reports that are cloned from, say, Fedora 13 to
RHEL 6. If the F13 bug was marked as F13Blocker, then the RHEL 6 bug
ends up blocking the F13 release too...people often forget to change
attributes of the initial bug which don't make sense for the new bug).
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michael Schwendt]

On Wed, 31 Mar 2010 19:15:30 +0300 (EEST), Juha wrote:

>  
>  
>  On Wed, 31 Mar 2010, Jeff Spaleta wrote:
>  > Unfortunately our ticketing tool doesn't do a great job at this, as we
>  > can't take one ticket and mark multiple release branches it affects
>  > and which of those release branches the fix is provided.
>  
>  that's why there is 'clone' functionality. Use it.
>  
>  
>  Tuju 
Why would I want to clone a bz ticket if I did not want to fix the
bug in anything other than Rawhide?

It may even be that the reported issue can only be fixed in Rawhide while
fixing it in older software included with stable dist releases would
require unreasonable effort.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Juha Tuomala]

On Wed, 31 Mar 2010, Michael Schwendt wrote:
>  Why would I want to clone a bz ticket if I did not want to fix the
>  bug in anything other than Rawhide? 
Because it's a database of release's bugs, not a todo list?

I could be wrong of course, please correct me if I am. Considering 
that existing and remaining bugs are closed (when reported upstream) 
thou suggest that it actually is a todo list.

I always thought that the bugzilla is for whole community, including 
the users. Not just for pkg maintainers.


Tuju

-- 
I couldn't repair your brakes, so I made your horn louder.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jef Spaleta]

On Wed, Mar 31, 2010 at 12:30 PM, Juha Tuomala <Juha.Tuomala(a)iki.fi&gt; wrote:
>  Because it's a database of release's bugs, not a todo list?
Bugzilla has multiple uses. The upstream project goes to some length
describing it as a flexible tool.  We in fact use it for multiple
purposes. We use it for package review tickets...which are stictly
speaking not "bugs" in a release.  We most definitely use it primarily
as a to-do list manager for package maintainers..from package birth to
package death. The established workflow that we are using now is not
and has never pretended to be an accurate audit trail of active
defects in a given release.

>  I always thought that the bugzilla is for whole community, including
>  the users. Not just for pkg maintainers. 
No one has so far defined a workflow that requires an accurate audit
of active deficiencies in any release.  Closing bugs fixed rawhide
certainly cause some annoyances because closed bugs are marginally
harder to search for (because you have to request closed bugs to
search through) when encountering the problem again and subsequently
cause bugs to be refiled unnecessarily.  The same goes for any closure
condition that bodhi doesn't automatically perform when an update gets
pushed to stable.

-jef

Bugzilla usage

[Orion Poplawski]

On 3/31/2010 2:53 PM, Jeff Spaleta wrote:
>  No one has so far defined a workflow that requires an accurate audit
>  of active deficiencies in any release.  Closing bugs fixed rawhide
>  certainly cause some annoyances because closed bugs are marginally
>  harder to search for (because you have to request closed bugs to
>  search through) when encountering the problem again and subsequently
>  cause bugs to be refiled unnecessarily.  The same goes for any closure
>  condition that bodhi doesn't automatically perform when an update gets
>  pushed to stable.
>
>  -jef
>      
This is why I actually really enjoyed the brief period that bugzilla 
automatically searched closed bugs, though I can see why that isn't 
sustainable.  Perhaps it could automatically search closed bugs for 
supported releases?

- Orion

Bugzilla usage

[Jef Spaleta]

On Wed, Mar 31, 2010 at 6:35 PM, Orion Poplawski <orion(a)cora.nwra.com&gt; wrote:
>  This is why I actually really enjoyed the brief period that bugzilla
>  automatically searched closed bugs, though I can see why that isn't
>  sustainable.  Perhaps it could automatically search closed bugs for
>  supported releases? 
Or perhaps... its time to find the manpower to extend the  "community"
web portal design for an end-user workflow that interacts with
bugzilla.

-jef

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michael Schwendt]

On Wed, 31 Mar 2010 23:30:08 +0300 (EEST), Juha wrote:

>  > Why would I want to clone a bz ticket if I did not want to fix
> the
>  > bug in anything other than Rawhide?
>  
>  Because it's a database of release's bugs, not a todo list? 
Is that an answer or a question?

Anyone who wants to search the database can do so and cover _closed_
tickets in addition to open ones. I don't see the need to keep tickets
open (or clone them) in cases where a status such as WONTFIX, RAWHIDE
or UPSTREAM is appropriate.

>  I could be wrong of course, please correct me if I am. Considering 
>  that existing and remaining bugs are closed (when reported upstream) 
>  thou suggest that it actually is a todo list.
>  
>  I always thought that the bugzilla is for whole community, including 
>  the users. Not just for pkg maintainers. 
Not every ticket immediately is a todo item (e.g. some only track defects
till something definite is found out), but those tickets that are answered
by the pkg maintainer with some action may get _closed_, with the pkg
maintainer having the final word about whether there will be an update.
Reporters (and potential contributors), who think they know better, are
free to propose a feasible solution.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 14:20:40 Ralf Corsepius wrote:
>  On 03/31/2010 11:32 AM, Rahul Sundaram wrote:
>  > On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
>  >> If your "unworthy bug" doesn't cause malfunctions, you could
> easily
>  >> close it "WONTFIX" and add a comment.
>  > 
>  > Why do you advocate WONTFIX over FIXED RAWHIDE?
>  
>  Because it is how s user perceives it.
>  
>  His bug is not fixed in the Fedora release he filed the bug against. 
So there should be a COMMENT why it's closed in rawhide only - usually rawhide 
bugs should be closed in rawhide. But sometimes the fix could lead to difficult 
backport etc... So the only way is to fix it in Rawhide only. 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Frank Murphy]

On 31/03/10 13:34, Jaroslav Reznik wrote:
>  On Wednesday 31 March 2010 14:20:40 Ralf Corsepius wrote:
> > On 03/31/2010 11:32 AM, Rahul Sundaram wrote:
> >> On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
> >>> If your "unworthy bug" doesn't cause malfunctions, you could
> easily
> >>> close it "WONTFIX" and add a comment.
> >>
> >> Why do you advocate WONTFIX over FIXED RAWHIDE?
> >
> > Because it is how s user perceives it.
> >
> > His bug is not fixed in the Fedora release he filed the bug against.
>
>  So there should be a COMMENT why it's closed in rawhide only - usually rawhide
>  bugs should be closed in rawhide. But sometimes the fix could lead to difficult
>  backport etc... So the only way is to fix it in Rawhide only. 
As an end user a comment as such would be welcome.
If' it's important enough to the end user.
They are more informed.


-- 
Regards,

Frank Murphy
UTF_8 Encoded, Fedora.x86_64

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 15:02 +0530, Rahul Sundaram wrote:
>  On 03/31/2010 02:55 PM, Ralf Corsepius wrote:
>  >
>  >
>  > If your "unworthy bug" doesn't cause malfunctions, you could easily
>  > close it "WONTFIX" and add a comment.
>  
>  Why do you advocate WONTFIX over FIXED RAWHIDE?  The latter seems the
>  more accurate status considering that I did fix it in Rawhide. 
That's what the policy currently recommends, but I can see the converse
argument. My thinking in drafting the life cycle was broadly that the
point of the bug report is to track the resolution of a single problem
in a single release; the fact that a fix is in Rawhide means nothing to
the release against which the bug was filed. The resolution of the issue
in the release against which it was filed is that you intentionally did
not fix it: hence WONTFIX.

Again, we could change this if sufficient people seem to think it makes
more sense the other way. This is ultimately yet another manifestation
of the inherent problems Bugzilla has with tracking multiple components
of multiple distribution releases (it doesn't have sufficient
granularity to allow this in any particularly good way).

An alternative is to change the version to Rawhide and then you can use
CLOSED RAWHIDE. You should usually have the reporter's agreement before
doing this, though.

Once again I note that Launchpad handles this noticeably better than
Bugzilla.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 04/01/2010 12:42 AM, Adam Williamson wrote:
>  An alternative is to change the version to Rawhide and then you can use
>  CLOSED RAWHIDE. You should usually have the reporter's agreement before
>  doing this, though.
>
>  Once again I note that Launchpad handles this noticeably better than
>  Bugzilla.
>     
Well, then let's fix bugzilla to adopt launchpad improvements or just
adopt launchpad.

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Thu, 2010-04-01 at 00:45 +0530, Rahul Sundaram wrote:
>  On 04/01/2010 12:42 AM, Adam Williamson wrote:
>  >
>  > An alternative is to change the version to Rawhide and then you can use
>  > CLOSED RAWHIDE. You should usually have the reporter's agreement before
>  > doing this, though.
>  >
>  > Once again I note that Launchpad handles this noticeably better than
>  > Bugzilla. 
>  Well, then let's fix bugzilla to adopt launchpad improvements or
> just
>  adopt launchpad. 
As I said in another mail, Launchpad isn't better in all respects, it's
not a simple decision. Also, currently Bugzilla is shared with Red Hat
and hence benefits from management by dkl and other RH staff; I doubt RH
would switch from Bugzilla, so if Fedora wanted to adopt something RH
could not use, Fedora would have to provide the person-hours to
implement and maintain the new system.

It'd be nice to have better handling for this in a future Bugzilla
release, but I think it might require considerable internal changes,
though I'm not an expert; it doesn't strike me as something simple to
patch in.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Rahul Sundaram]

On 04/01/2010 12:59 AM, Adam Williamson wrote:
>  As I said in another mail, Launchpad isn't better in all respects, it's
>  not a simple decision. Also, currently Bugzilla is shared with Red Hat
>  and hence benefits from management by dkl and other RH staff; 
On the other hand, none of the bugzilla changes from Red Hat seems to be
published anywhere and other than a small number of people inside Red
Hat, we can't as a community make changes and even if we can, there are
a number of places where there is a conflict between RHEL workflows and
Fedora's.  We cannot continuously avoid facing that question.  Even with
the additional maintenance burden on the part of Fedora infrastructure
team, we have opted to separate things over time c.f. build systems,
mailing lists et all.  The only major thing left is bugzilla.

>   I doubt RH
>  would switch from Bugzilla, so if Fedora wanted to adopt something RH
>  could not use, Fedora would have to provide the person-hours to
>  implement and maintain the new system.
>
>  It'd be nice to have better handling for this in a future Bugzilla
>  release, but I think it might require considerable internal changes,
>  though I'm not an expert; it doesn't strike me as something simple to
>  patch in.
>     
I would suggest proposing those changes you have in mind to dkl,  There
is a internal bugzilla list.

Rahul

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Thu, 2010-04-01 at 01:12 +0530, Rahul Sundaram wrote:

>  I would suggest proposing those changes you have in mind to dkl, 
> There
>  is a internal bugzilla list. 
The problem is this isn't an area where I can be terribly constructive;
I can point at the problem but I've nothing to offer in the way of a
solution, as I'm not a coder, nor a Bugzilla architect. I can draw
pie-in-the-sky pictures of Teh Awesome Bugtracking System, if you like,
but I've no real idea how they map to the realities of what's achievable
within the constraints of Bugzilla. Remember RH now has a policy of
diverging as little as possible from upstream Bugzilla, so any changes
we wanted to make would need to be something that upstream would accept,
we can't do significant modifications of Bugzilla purely in the RH
instance.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Till Maas]

On Wed, Mar 31, 2010 at 12:29:26PM -0700, Adam Williamson wrote:

>  It'd be nice to have better handling for this in a future
> Bugzilla
>  release, but I think it might require considerable internal changes,
>  though I'm not an expert; it doesn't strike me as something simple to
>  patch in. 
Maybe it would be enough to somehow store the information in Bugzilla,
e.g. using a flag for each supported release or some Whiteboard
Keywords, and then implement another Bugzilla Frontend that uses the
XML-RPC interface of Bugzilla to provide a Frontend that can be better
used for Fedora.

Regards
Till

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michael Cronenworth]

Till Maas wrote:
>  Maybe it would be enough to somehow store the information in
> Bugzilla,
>  e.g. using a flag for each supported release or some Whiteboard
>  Keywords, and then implement another Bugzilla Frontend that uses the
>  XML-RPC interface of Bugzilla to provide a Frontend that can be better
>  used for Fedora. 
*ding* *ding* *ding* Correct.

Check out a Firefox or Thunderbird BZ flags for a good example. Properly 
adding some Fedora flags should not affect RHEL.

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 14:56 -0500, Michael Cronenworth wrote:
>  Till Maas wrote:
>  > Maybe it would be enough to somehow store the information in Bugzilla,
>  > e.g. using a flag for each supported release or some Whiteboard
>  > Keywords, and then implement another Bugzilla Frontend that uses the
>  > XML-RPC interface of Bugzilla to provide a Frontend that can be better
>  > used for Fedora.
>  
>  *ding* *ding* *ding* Correct.
>  
>  Check out a Firefox or Thunderbird BZ flags for a good example. Properly 
>  adding some Fedora flags should not affect RHEL. 
This still smells like a messy workaround to me. Not only the web
interface is used to access Bugzilla. We'd have to patch everything else
- python-bugzilla, Fedora Community, etc - to properly 'interpret' the
flags. But hey, it'd be better than nothing, if someone wants to do the
work...
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Till Maas]

On Wed, Mar 31, 2010 at 01:09:51PM -0700, Adam Williamson wrote:
>  On Wed, 2010-03-31 at 14:56 -0500, Michael Cronenworth wrote:
>  > Till Maas wrote:
>  > > Maybe it would be enough to somehow store the information in Bugzilla,
>  > > e.g. using a flag for each supported release or some Whiteboard
>  > > Keywords, and then implement another Bugzilla Frontend that uses the
>  > > XML-RPC interface of Bugzilla to provide a Frontend that can be better
>  > > used for Fedora.
>  > 
>  > *ding* *ding* *ding* Correct.
>  > 
>  > Check out a Firefox or Thunderbird BZ flags for a good example. Properly 
>  > adding some Fedora flags should not affect RHEL.
>  
>  This still smells like a messy workaround to me. Not only the web
>  interface is used to access Bugzilla. We'd have to patch everything else
>  - python-bugzilla, Fedora Community, etc - to properly 'interpret' the
>  flags. But hey, it'd be better than nothing, if someone wants to do the
>  work... 
Any change from the current situation will require changes in the
dependent tools to interpret whatever is used for a new workflow. E.g.
if bugs are cloned, that the tools should also identify the bugs as
cloned ones.

Regards
Till

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Felix Miata]

On 2010/03/31 21:47 (GMT+0200) Till Maas composed:

>  On Wed, Mar 31, 2010 at 12:29:26PM -0700, Adam Williamson wrote:
> > It'd be nice to have better handling for this in a future
> Bugzilla
> > release, but I think it might require considerable internal changes,
> > though I'm not an expert; it doesn't strike me as something simple to
> > patch in. 
>  Maybe it would be enough to somehow store the information in
> Bugzilla,
>  e.g. using a flag for each supported release or some Whiteboard
>  Keywords, and then implement another Bugzilla Frontend that uses the
>  XML-RPC interface of Bugzilla to provide a Frontend that can be better
>  used for Fedora. 
Bugzilla is OSS. Those with the talent and inclination to do so could try
lending a hand to existing efforts to improve branch/release handling:
https://bugzilla.mozilla.org/show_bug.cgi?id=55970

I found that bug quickly by searching in comments for string "launchpad" in
product "Bugzilla": http://tinyurl.com/yl5pkdz
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409

Felix Miata  ***  http://fm.no-ip.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Wed, 2010-03-31 at 16:54 -0400, Felix Miata wrote:

>  Bugzilla is OSS. Those with the talent and inclination to do so could
> try
>  lending a hand to existing efforts to improve branch/release handling:
>  https://bugzilla.mozilla.org/show_bug.cgi?id=55970
>  
>  I found that bug quickly by searching in comments for string "launchpad" in
>  product "Bugzilla": http://tinyurl.com/yl5pkdz 
Yeah, I'm aware of it. I check in on it regularly...once a year. It's
one of those 'long timescale' bugs =)

I unfortunately don't have the talent to help much, as I mentioned.
Mostly I bring it up in this thread to emphasize that the current Fedora
system is inherently compromised and, until the underlying tool is
improved, _always will be_: I want people to realize that, within the
current system, we cannot Solve Everything, only pick one trade-off or
another. Whichever trade-off we pick will annoy somebody, so simply
saying 'this trade-off annoys me!' is ultimately futile; I think it's
important to be aware of the big picture, which is that Bugzilla
currently simply can't cover all the things we're trying to do with it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Mon, 2010-03-29 at 14:11 +0200, Jaroslav Reznik wrote:
>  On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
>  > 2010/3/29 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  > > 2010/3/29 Oliver Falk <oliver(a)linux-kernel.at&gt;:
>  > >> I had similar issues already and I totally agree with Christoph!
>  > >> The maintainer should not redirect the bugreporter to the upstream
>  > >> bugreporting plattform. I already have plenty of accounts on upstream
>  > >> bugzillas because of exactly this...
>  > > 
>  > > I don't see any problem here if KDE SIG just declare "we don't fix
> KDE
>  > > bugs, we just update packages".
>  > > 
>  > > They are not KDE developers, so they don't know how to fix these bugs.
>  > 
>  > This response regardless, as a downstream user of a package, if i
>  > report a bug, it's nice to know if it's going to be fixed in a current
>  > release or not. Until the upstream bugfix lands in a package
>  > downstream, downstream should leave the bug open. 
>  
>  Current Bugzilla policy says CLOSED as UPSTREAM is correct resolution. It's 
>  just terminology - I would prefer another one - like just UPSTREAM status, or 
>  ON_DEV UPSTREAM or something similar. CLOSED UPSTREAM does not mean that 
>  nobody cares! It's still tracked! 
There's an 'Upstream' keyword you can use instead of the UPSTREAM
resolution. The choice of which to use is currently left up to
maintainer discretion.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Josephine Tannhäuser]

2010/3/29, Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
>  I don't see any problem here if KDE SIG just declare "we
> don't fix KDE
>  bugs, we just update packages". 
wtf? You can not be serious!
It's the duty of every maintainer to accept responsibility for his/her
package(s).
If there is no responsibility granted for packages in an important
distribution like fedora, they should be kicked out (the packages and
the maintainers)!
I'm happy that this sentence is not an official statement...

BTW: The update marathon of the KDE-SIG in stable releases is wholly
unacceptable for me.

>  They are not KDE developers, so they don't know how to fix these
> bugs. 
This is tbs, they don't need to be a developer or a super coder to fix
a bug, a good communication with upstream will help to fix bugs asap.

>  Regards,
>  Michal 
Please don't post crap like this any more. This is a seriously list
and not a troll paradise.
Here's your red herring <°)))o><
-- 
Josephine "Fine" Tannhäuser

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Michał Piotrowski]

2010/3/29 Josephine Tannhäuser <josephine.tannhauser(a)googlemail.com&gt;:
>  2010/3/29, Michał Piotrowski <mkkp4x4(a)gmail.com&gt;:
> > I don't see any problem here if KDE SIG just declare "we don't fix KDE
> > bugs, we just update packages".
>  wtf? You can not be serious!
>  It's the duty of every maintainer to accept responsibility for his/her
>  package(s).
>  If there is no responsibility granted for packages in an important
>  distribution like fedora, they should be kicked out (the packages and
>  the maintainers)!
>  I'm happy that this sentence is not an official statement...
>
>  BTW: The update marathon of the KDE-SIG in stable releases is wholly
>  unacceptable for me.
>
> > They are not KDE developers, so they don't know how to fix these bugs.
>  This is tbs, they don't need to be a developer or a super coder to fix
>  a bug 
Do you remember a famous Debian OpenSSL bug fix made by qualified
Debian developer?

IMO program developer is most qualified to fix bugs.

You may not agree with this.

> , a good communication with upstream will help to fix bugs asap.
But still bugs are fixed by program developers not Fedora developers.

Regards,
Michal

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Matthias Clasen]

On Mon, 2010-03-29 at 15:10 +0200, Michał Piotrowski wrote:

>  
>  But still bugs are fixed by program developers not Fedora developers. 
IMO 'Fedora developers' (really, what you mean here are packagers, I
guess) should strive to become 'program developers' for the packages
they maintain.

Getting stuck in package maintenance should not be the end-goal of
Fedora contributors...

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Monday 29 March 2010 15:13:56 Matthias Clasen wrote:
>  On Mon, 2010-03-29 at 15:10 +0200, Michał Piotrowski wrote:
>  > But still bugs are fixed by program developers not Fedora developers.
>  
>  IMO 'Fedora developers' (really, what you mean here are packagers, I
>  guess) should strive to become 'program developers' for the packages
>  they maintain.
>  
>  Getting stuck in package maintenance should not be the end-goal of
>  Fedora contributors... 
It isn't - we try to contribute upstream as much as possible - our goal - but 
you never can understand everything in a such a big project(s). Even core 
developers sometimes are not sure about consequences of the bug fix. But that's 
the nice thing on open source - collaboration! You are never alone ;-)

Jaroslav

-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Mon, 2010-03-29 at 09:13 -0400, Matthias Clasen wrote:
>  On Mon, 2010-03-29 at 15:10 +0200, Michał Piotrowski wrote:
>  
>  > 
>  > But still bugs are fixed by program developers not Fedora developers.
>  
>  IMO 'Fedora developers' (really, what you mean here are packagers, I
>  guess) should strive to become 'program developers' for the packages
>  they maintain.
>  
>  Getting stuck in package maintenance should not be the end-goal of
>  Fedora contributors...  
I don't agree with this. Packaging is not developing; the two are really
rather different. I'm reasonably good at packaging, and terrible at
developing. Becoming a good developer isn't terribly high on my priority
list. I don't think that packaging is just a 'gateway' to development,
it's an important task in itself.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Ralf Corsepius]

On 03/29/2010 01:38 PM, Oliver Falk wrote:
>  I had similar issues already and I totally agree with Christoph!
Me too.

Except that I would not want to restrict this complaint to Fedora KDE.

There are many other maintainers who apply a similar strategy and 
therefore deserve the same amount of flaming.

>  The maintainer should not redirect the bugreporter to the upstream
> bugreporting plattform. I already have plenty of accounts on upstream bugzillas because of
> exactly this... 
This still would require
a) "reporter" to be interested in getting involved upstream
b) "reporter" to be "technically able" to get involved upstream.

In many cases, one or both considerations do not apply.

Ralf

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Mon, 2010-03-29 at 13:59 +0200, Ralf Corsepius wrote:
>  On 03/29/2010 01:38 PM, Oliver Falk wrote:
>  > I had similar issues already and I totally agree with Christoph!
>  Me too.
>  
>  Except that I would not want to restrict this complaint to Fedora KDE.
>  
>  There are many other maintainers who apply a similar strategy and 
>  therefore deserve the same amount of flaming.
>  
>  > The maintainer should not redirect the bugreporter to the upstream bugreporting
> plattform. I already have plenty of accounts on upstream bugzillas because of exactly
> this...
>  This still would require
>  a) "reporter" to be interested in getting involved upstream
>  b) "reporter" to be "technically able" to get involved upstream.
>  
>  In many cases, one or both considerations do not apply. 
I don't think there's ever an absolute answer to this question.
Sometimes it makes more sense for the original reporter to report
upstream - in which case the maintainer should politely ask them to;
sometimes it makes more sense for the maintainer to report upstream. It
very much depends on the circumstances of the bug.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jef Spaleta]

On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson <awilliam(a)redhat.com&gt; wrote:
>  I don't think there's ever an absolute answer to this
> question.
>  Sometimes it makes more sense for the original reporter to report
>  upstream - in which case the maintainer should politely ask them to;
>  sometimes it makes more sense for the maintainer to report upstream. It
>  very much depends on the circumstances of the bug. 
For me it comes down to one test. If I can reproduce it, I can be the
one to carry the torch to upstream and I can invite the original
reporter to come along for the ride.

If I can't reproduce it, I have to get upstream and someone who can
reproduce the problem talking somehow or  the report is just going to
bitrot. That means one of several things:

*getting the reporter to file upstream or have them submit a patch
that I can review and forward.
*getting another user who can reproduce to act on the behalf of the reporter
*drawing upstream attention to the Fedora ticket and having the
conversation there.

-jef

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Adam Williamson]

On Tue, 2010-03-30 at 15:56 -0800, Jeff Spaleta wrote:
>  On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson
> <awilliam(a)redhat.com&gt; wrote:
>  > I don't think there's ever an absolute answer to this question.
>  > Sometimes it makes more sense for the original reporter to report
>  > upstream - in which case the maintainer should politely ask them to;
>  > sometimes it makes more sense for the maintainer to report upstream. It
>  > very much depends on the circumstances of the bug.
>  
>  For me it comes down to one test. If I can reproduce it, I can be the
>  one to carry the torch to upstream and I can invite the original
>  reporter to come along for the ride.
>  
>  If I can't reproduce it, I have to get upstream and someone who can
>  reproduce the problem talking somehow or  the report is just going to
>  bitrot. That means one of several things: 
Right. That's pretty much exactly the rule of thumb I use too.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

Upstream bugs vs. Fedora bugs: KDE people do it wrong

[Jaroslav Reznik]

On Wednesday 31 March 2010 01:56:56 Jeff Spaleta wrote:
>  On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson
> <awilliam(a)redhat.com&gt;  
wrote:
>  > I don't think there's ever an absolute answer to this
> question.
>  > Sometimes it makes more sense for the original reporter to report
>  > upstream - in which case the maintainer should politely ask them to;
>  > sometimes it makes more sense for the maintainer to report upstream. It
>  > very much depends on the circumstances of the bug.
>  
>  For me it comes down to one test. If I can reproduce it, I can be the
>  one to carry the torch to upstream and I can invite the original
>  reporter to come along for the ride.
>  
>  If I can't reproduce it, I have to get upstream and someone who can
>  reproduce the problem talking somehow or  the report is just going to
>  bitrot. That means one of several things:
>  
>  *getting the reporter to file upstream or have them submit a patch
>  that I can review and forward.
>  *getting another user who can reproduce to act on the behalf of the
>  reporter *drawing upstream attention to the Fedora ticket and having the
>  conversation there. 
Agreed. I forget to mention "be able to reproduce" - most important thing.

Jaroslav

>  -jef 
-- 
Jaroslav Řezník <jreznik(a)redhat.com&gt;
Software Engineer - Base Operating Systems Brno

Office: [phone]
Mobile: [phone]
Red Hat, Inc.                               http://cz.redhat.com/