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@googlemail.com 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_with...
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
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@googlemail.com 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
2010/3/29 Oliver Falk oliver@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.
Regards, Michal
2010/3/29 Michał Piotrowski mkkp4x4@gmail.com:
2010/3/29 Oliver Falk oliver@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. 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
On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
2010/3/29 Michał Piotrowski mkkp4x4@gmail.com:
2010/3/29 Oliver Falk oliver@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!
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
2010/3/29 Jaroslav Reznik jreznik@redhat.com:
On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
2010/3/29 Michał Piotrowski mkkp4x4@gmail.com:
2010/3/29 Oliver Falk oliver@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!
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
On Monday 29 March 2010 14:16:55 Yaakov Nemoy wrote:
2010/3/29 Jaroslav Reznik jreznik@redhat.com:
On Monday 29 March 2010 14:03:51 Yaakov Nemoy wrote:
2010/3/29 Michał Piotrowski mkkp4x4@gmail.com:
2010/3/29 Oliver Falk oliver@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!
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
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ł Piotrowskimkkp4x4@gmail.com:
2010/3/29 Oliver Falkoliver@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
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ł Piotrowskimkkp4x4@gmail.com:
2010/3/29 Oliver Falkoliver@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
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
2010/3/29 Till Maas opensource@till.name:
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
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.
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".
On Tue, Mar 30, 2010 at 8:04 PM, Ralf Corsepius rc040203@freenet.de 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 :).
2010/3/31 Stephen John Smoogen smooge@gmail.com:
On Tue, Mar 30, 2010 at 8:04 PM, Ralf Corsepius rc040203@freenet.de 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
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
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?
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
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
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
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
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?
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
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.
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
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
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
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
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
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.
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
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.
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
On Wed, Mar 31, 2010 at 4:49 AM, Rahul Sundaram metherid@gmail.com 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
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
On Wed, Mar 31, 2010 at 8:15 AM, Juha Tuomala Juha.Tuomala@iki.fi 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
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
On Wed, Mar 31, 2010 at 8:29 AM, Juha Tuomala Juha.Tuomala@iki.fi 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
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
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).
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.
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.
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
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).
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.
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
On Wed, Mar 31, 2010 at 12:30 PM, Juha Tuomala Juha.Tuomala@iki.fi 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
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
On Wed, Mar 31, 2010 at 6:35 PM, Orion Poplawski orion@cora.nwra.com 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
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.
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.
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.
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.
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
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.
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
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.
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
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.
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...
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
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
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.
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@gmail.com:
2010/3/29 Oliver Falk oliver@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!
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.
2010/3/29, Michał Piotrowski mkkp4x4@gmail.com:
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><
2010/3/29 Josephine Tannhäuser josephine.tannhauser@googlemail.com:
2010/3/29, Michał Piotrowski mkkp4x4@gmail.com:
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
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...
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
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.
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
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.
On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson awilliam@redhat.com 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
On Tue, 2010-03-30 at 15:56 -0800, Jeff Spaleta wrote:
On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson awilliam@redhat.com 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.
On Wednesday 31 March 2010 01:56:56 Jeff Spaleta wrote:
On Tue, Mar 30, 2010 at 3:33 PM, Adam Williamson awilliam@redhat.com
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