Re: Maintainer Responsibilities
Frank Ch. Eigler wrote: > Kevin Kofler writes: > >> [...] If the bug is important enough to block one of our trackers, >> we won't close it UPSTREAM, we'll even try to fix it on our own (and >> then upstream our fix) if upstream doesn't come up with a fix soon >> enough. > > If you "CLOSE"/UPSTREAM it and force your user to report it elsewhere > instead, you won't know one way or another. Please reread the first part of the sentence you quoted. >> But we can't reserve that treatment to every single KDE bug, there >> are too many! > > Thank you for that moment of candour. It illuminates what is > really motivating the disagreement about proper process. The fact is, every large project has thousands of reported bugs. GNOME has several hundreds of thousands of bugs. KDE has more than 10, but fewer than 20. There's no way a small team of distro packagers for that project can address them all. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Kevin Kofler writes: > [...] If the bug is important enough to block one of our trackers, > we won't close it UPSTREAM, we'll even try to fix it on our own (and > then upstream our fix) if upstream doesn't come up with a fix soon > enough. If you "CLOSE"/UPSTREAM it and force your user to report it elsewhere instead, you won't know one way or another. > But we can't reserve that treatment to every single KDE bug, there > are too many! Thank you for that moment of candour. It illuminates what is really motivating the disagreement about proper process. - FChE -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Fri, 2009-06-05 at 09:01 -0700, Adam Williamson wrote: > On Thu, 2009-06-04 at 23:19 +0200, Edwin ten Brink wrote: > > > Aside from all discussions in this thread, the current Bugzilla > > documentation seems quite clear on this topic. Whatever the outcome of > > the discussion is, I think the documentation which is visible to the > > end-user (customer), should at least match the common practice/procedure. > > > > Note also that the discussion is primarily focussed on the Resolution of > > the bug report, while there are also two Keywords available with respect > > to upstream. I've quoted the full texts below for reference. > > > From https://bugzilla.redhat.com/describekeywords.cgi > > This page doesn't really cover Fedora policy or practice, it covers RHEL > policy and practice, which is not the same thing. Sorry, I mistook this: the page that's not strictly entirely applicable to Fedora is the one you link to lower down: https://bugzilla.redhat.com/page.cgi?id=fields.html#status not the keyword description page. We don't presently have a separate keyword description page for Fedora. I haven't looked yet at whether any of the keywords or descriptions are inapplicable to Fedora, if they are, we should probably 'branch' that page too. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Fri, 2009-06-05 at 10:44 +0200, Jaroslav Reznik wrote: > > In other situations, you can set the UPSTREAM keyword, so the bug > > remains open but you know it's being handled upstream and you need to > > bring the fix downstream once it's available upstream. > > I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and > CLOSED > bugs are not as easy to search for duplicates when you are reporting bug. As Edwin noted, there is in fact an Upstream keyword in RH Bugzilla (and a 'MoveUpstream' keyword). 'Upstream' appears only ever to have been used for two bugs, however. 'MoveUpstream' seems to have been used extensively in the past, but rarely lately: it does seem to fit the case I described, however. So, yeah, if you like this idea, use the 'MoveUpstream' keyword. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 23:19 +0200, Edwin ten Brink wrote: > Aside from all discussions in this thread, the current Bugzilla > documentation seems quite clear on this topic. Whatever the outcome of > the discussion is, I think the documentation which is visible to the > end-user (customer), should at least match the common practice/procedure. > > Note also that the discussion is primarily focussed on the Resolution of > the bug report, while there are also two Keywords available with respect > to upstream. I've quoted the full texts below for reference. > From https://bugzilla.redhat.com/describekeywords.cgi This page doesn't really cover Fedora policy or practice, it covers RHEL policy and practice, which is not the same thing. The next revision of Bugzilla will in fact include a link on this page, directing you to: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow for the Fedora policy and practice. That page says in passing: "The resolution UPSTREAM can be used by maintainers to denote a bug that they expect to be fixed by upstream development and naturally rolled back into Fedora as part of the update process. Ideally, a comment should be added with a link to the upstream bug report." but that's just what I wrote when updating the page, it's not based on any official discussion / agreement, so I made it intentionally vague and (hopefully) non-controversial. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 22:53 +0200, Kevin Kofler wrote: > Adam Williamson wrote: > > If, say, the bug is in a package that gets frequent releases, and was > > filed on the development release, you can just use CLOSED UPSTREAM, > > because you can rely on the fact that there'll be a new upstream release > > of the package soon after the upstream report is fixed, you (the > > maintainer) will then naturally package the new release, and the fix for > > the bug will have been rolled into the distribution package without you > > having to do anything besides your normal packaging work. > > In fact that's what happens with KDE, bugfix releases come out once a month > in most cases (the time from the last bugfix point release to the next > feature release is a bit longer though, about 2 months upstream (blame the > folks who decided *.5 releases are not needed), plus about 2 weeks of > testing in updates-testing to prevent regressions). Indeed, KDE would be exactly the kind of project I had in mind for that scenario: it's very actively maintained and bugfix releases show up and are packaged into Fedora frequently. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 20:23:01 Adam Williamson escribió: > On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: > > I'll happily raise upstream bugs myself but it irks me when maintainers > > close Fedora bugs with the UPSTREAM resolution without actually taking > > the upstream fix and bringing it into Fedora. > > > > If I've reported a bug in Fedora bugzilla it's because the bug is > > present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a > > bug closed UPSTREAM doesn't help at all if I have a real problem with a > > Fedora package. > > In Mandriva I had it set up so Bugzilla has both an UPSTREAM > *resolution* and an UPSTREAM *keyword*. This handles this situation. > > If, say, the bug is in a package that gets frequent releases, and was > filed on the development release, you can just use CLOSED UPSTREAM, > because you can rely on the fact that there'll be a new upstream release > of the package soon after the upstream report is fixed, you (the > maintainer) will then naturally package the new release, and the fix for > the bug will have been rolled into the distribution package without you > having to do anything besides your normal packaging work. > > In other situations, you can set the UPSTREAM keyword, so the bug > remains open but you know it's being handled upstream and you need to > bring the fix downstream once it's available upstream. I like idea of some TRACKING_UPSTREAM keyword - it's easy to search and CLOSED bugs are not as easy to search for duplicates when you are reporting bug. Jaroslav > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Reindl Harald, Thu, 04 Jun 2009 20:45:21 +0200: > I think it is simple BAD to close bugreports with "upstream"! For me as > "enduser" of fedora i have one bugzilla and i really like to help with > bugreports, try things if maintainer needs better explains what happens. As you can see from this thread, there are as many opinions on this issue as there are packages in Fedora ;-). It all depends from the style of packager's work. E.g., openoffice.org maintainer prefers to move all non- packaging bugs upstream ASAP (he does the moving) and then he works on them upstream (firefox maintainers have similar attitude). Advantage (and one of the foundational pieces of Red Hat philosophy) is that a) our work can be shared with others, b) we can use results of others work. And yes, whole process of upstreaming should be invisible and painless to reporter of RH bug, but our tooling in this area is non-existent. Join the party at https://bugzilla.redhat.com/show_bug.cgi?id=452962 :) Matej -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
於 四，2009-06-04 於 07:23 +0200，Ralf Corsepius 提到：
> Steven M. Parrish wrote:
>
> > Many people have mentioned that it is not right to ask the users to file
> > their
> > bug reports upstream. I ask why not?
>
> Let me summarize what I already wrote elsewhere in this thread:
> * Users aren't necessarily developers.
> * Users aren't necessarily interested in getting involved upstream.
> * Users are reporting bugs against your product (your package in
> Fedora), not against upstream's work (somebody else's product).
>
>
> Let me try an analogy: How do you handle defects/malfunctions with your
> car?
>
> You'll visit your car dealer/a garage and report the issue to them.
> You'll expect them to identify the problem and to take appropriate steps
> to solve your issue. You don't expect them to direct you to the car's
> manufacturer or a component manufacturer and to discuss technical
> details you have no knowledge about with them ("Is the stuttering engine
> cause by triac 7 in a component A you haven't heard about before" or by
> the hall sensor in component B you also haven't heard about before).
Using your analogy:
If the car workshop does not have sufficient knowledge and material,
yes, that's right, the parts are ordered from upstream (the car
manufacturer).
If you want to, say, make a suggestion for your Ford, giving the
suggestion to the car workshop does not help much, unless it is one of
Ford's branch.
Some bugs need to go upstream, some bugs need not.
> Ralf
>
--
Ding-Yi Chen
Software Engineer
Internationalization Group
Red Hat, Inc.
Looking to carve out IT costs?
www.apac.redhat.com/promo/carveoutcosts/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Message: 1 > Date: Thu, 04 Jun 2009 23:26:12 +0200 > From: Kevin Kofler > Subject: Re: Maintainer Responsibilities > To: fedora-devel-list@redhat.com > Message-ID: > Content-Type: text/plain; charset=us-ascii > Your misunderstanding is there: it's US maintainers that are helping YOU > reporters by fixing your bugs. If you think you don't need our help because > you don't care about the bug anyway, we can just close it as > INSUFFICIENT_DATA and stop there. > > Kevin Kofler YOU missunderstand You really believe a normal user ever registers at bugzilla for every piece of software he uses? The truth is the MOST upstream-bugzillas are fu**ing ignored and/or arrogant and thats the reason why i gave up in the meantime because i have better things to do as registering and be ignored or in the best cases i must discuss per private mail that some stupid upstream-developer repopens a bug after understanding "oh yes this is really a bug" PHP: http://bugs.php.net/bug.php?id=42836 Bogus? Not a problem in php when it mixes per-host-configuration? I'm php-developer and serveradmin for long enough to be sure that this IS a bug OK PHP6 is pre-alpha but thats not the point - how will tey get away them They do not need help? the do not got help upstream any longer You can be sure if a @redhat.com-address or a known maintainer reports this it would not be closed as "bogus". For unknown users the developers have a reflex "close as soon as possible" PHP: http://bugs.php.net/bug.php?id=42077 Closed with "read why there in the archive" and at this time you could not comment a closed bug and you hace to mail this crazy peopole until he understands this is a bug - sorry but if this would not be a showstopper for our whole company if released this way i would se "leave me fuck in peace and do what you want" Firefox: I NEVER got any response from upstream bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=495196 I do not like to search older ones but if i trie to report bugs there should be any response and i got never ever any response from firefox-bugzilla eaccelerator: http://eaccelerator.net/ticket/307 WTF - New snapshot introduces a new problem, repoorted a year ago, a workaround is no solution and its not really funny to get ignored in such way ffmpeg-php https://sourceforge.net/tracker/?func=detail&aid=2017954&group_id=122353&atid=693224 does not compile after ffmpeg-upgrade from livna, livna-bugtracker told i should make a bugreport against upstream and they ignores it since nearly a year, some other reporters got "svn has fixes" but svn-version also not compiles _ Only in the last 2 years i can search a lot of such frustrating things and only the time spent for registering in the bugzillas should be used for drink some beer to make more sense and yes it is a BIG different if a nobody or a well known maintainer from a distribution reports something upstream So please leave me in peace with "report upstream" and take the love for the software and help from users that way they are able and willing to give or you lose them in many cases with no response in rh-bugzilla AND do not get the bug reported upstream -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkooi9AACgkQhmBjz394AnnT1QCglPGy7GBT8AfmAC/XIsXOKyQM ayAAn2xp4iRoeRcJsEUcgBSdMMuZ28eN =nhRF -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 11:26:12PM +0200, Kevin Kofler wrote: > Reindl Harald wrote: > > If you want that the enduser report bugs upstream you get no repsonse > > in many cases because the user will say "WTF i wanted to help and you > > want to say me exactly how i have to help" and after this happens > > trhee times he is frustrated and will never ever report bugs > > Your misunderstanding is there: it's US maintainers that are helping YOU > reporters by fixing your bugs. If you think you don't need our help because > you don't care about the bug anyway, we can just close it as > INSUFFICIENT_DATA and stop there. Careful with that "we". I'd rather have a large list of open but low priority and difficult to reproduce bugs than have users who never bother reporting bugs in the first place - I may never get round to fixing them myself, but having that bug open makes it easier for other people who hit the same issue to determine that it is a bug and perhaps save themselves some time. And if it ever does get fixed, then that's even better. Flagging it closed means that's less likely to happen, and the quality of the software that we ship (and, as a result, the perceived usefulness of Fedora) is lower as a result. -- Matthew Garrett | mj...@srcf.ucam.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On 06/04/2009 01:30 PM, Kevin Kofler wrote: > Jud Craft wrote: >> Support != upstream. It's a symptom of the fact that the open source >> community is where people who create goods often don't do top-down >> support of those goods to end-users, the final recipient. >> >> Here's the problem: You all agree that end-users should seek out >> support. The reason why "they should go to upstream" is split isn't >> because Seeking Support = Bad. Seeking Support = Good. You're split >> because Having Outsiders Navigate Two/Three Layers of Community >> Indirection = Bad. > > Fixing bugs is a service we do to end users. If they don't want to use the > service the way we provide it, that's fine with me, we can just close their > stuff as INSUFFICIENT_DATA and move on. > This is where a lot of us disagree with you. There's several ways to look at this: * Maintainers are providing a service to users. Users are consuming programs. Maintainers are fixing the bugs in those programs as a service to the user. * Maintainers are providing a service to upstream. Upstream writes programs. Maintainers get their programs exposure, filter out things that aren't really bugs, help to write good bug reports, write patches to the software, etc. * Users are providing a service to the development of the program. All code has bugs. If there's bugs that you don't know about but your users are running into, they could just choose to not use it and use a different program. If they report the bug, they're trying to make the program better. I think failing to realize that all of these services are being rendered simultaneously is a grave mistake for us. We all benefit from a healthy ecosystem around bug reporting. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Reindl Harald wrote: > If you want that the enduser report bugs upstream you get no repsonse > in many cases because the user will say "WTF i wanted to help and you > want to say me exactly how i have to help" and after this happens > trhee times he is frustrated and will never ever report bugs Your misunderstanding is there: it's US maintainers that are helping YOU reporters by fixing your bugs. If you think you don't need our help because you don't care about the bug anyway, we can just close it as INSUFFICIENT_DATA and stop there. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: Does a maintainer's responsibilities end with packaging bugs? IOW, if there is a problem in the package that is _broken code_ do they need to do something about it or is it acceptable for them to close the bug and say talk to upstream? Do we want those bugs open to track when the bug is fixed in the distro? Aside from all discussions in this thread, the current Bugzilla documentation seems quite clear on this topic. Whatever the outcome of the discussion is, I think the documentation which is visible to the end-user (customer), should at least match the common practice/procedure. Note also that the discussion is primarily focussed on the Resolution of the bug report, while there are also two Keywords available with respect to upstream. I've quoted the full texts below for reference. Regards, Edwin From https://bugzilla.redhat.com/describekeywords.cgi Keyword: MoveUpstream Bugs with this keyword are slated to be filed in the upstream bug tracker or reported to the upstream mailing list, then closed UPSTREAM on the Red Hat level. This typically includes almost all feature requests and enhancements, and most bugs that we don't consider release showstoppers. (moving a bug upstream typically increases the chance that someone will have time to look at it, and often the upstream developer or bug owner even works at Red Hat - moving things upstream simply allows us to keep everything in one place, and work better with open source community developers outside of Red Hat. We only keep bugs open on redhat.com to track our immediate short-term TODO items, or issues with our patches/packaging, or because the upstream package in question has poor bug tracking. The main focus of development for most packages is the upstream community, even when Red Hat is a big contributor to the community.) Some upstream bug trackers: http://bugzilla.gnome.org http://bugzilla.kde.org http://bugzilla.mozilla.org If a bug has this keyword, feel free to go ahead and move it upstream, add a link to the upstream report in our report, and then close the bug. Or we typically do this ourselves in batches. Keyword: Upstream This keyword means that the feature or bug fix in this bugzilla was already accepted upstream and will be inherited by a RHEL release. From https://bugzilla.redhat.com/page.cgi?id=fields.html#status Resolution: UPSTREAM This resolution should not be used for RHEL bugs. Otherwise, bugs closed with this resolution are filed in the upstream bugs tracker or reported to the upstream mailing list. This typically includes almost all feature requests and enhancements, and most bugs that we don't consider release showstoppers. (moving a bugs upstream typically increases the chance that someone will have time to look at it, and often the upstream developer or bug owner even works at Red Hat - moving things upstream simply allows us to keep everything in one place, and work better with open source community developers outside of Red Hat. We only keep bug open on redhat.com to track our immediate short-term TODO items, or issues with our patches/packaging, or because the upstream package in question has poor bug tracking. The main focus of development for most packages is the upstream community, even when Red Hat is a big contributor to the community.) Some upstream bug trackers: http://bugzilla.gnome.org http://bugs.kde.org http://bugzilla.mozilla.org. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Adam Williamson wrote: > If, say, the bug is in a package that gets frequent releases, and was > filed on the development release, you can just use CLOSED UPSTREAM, > because you can rely on the fact that there'll be a new upstream release > of the package soon after the upstream report is fixed, you (the > maintainer) will then naturally package the new release, and the fix for > the bug will have been rolled into the distribution package without you > having to do anything besides your normal packaging work. In fact that's what happens with KDE, bugfix releases come out once a month in most cases (the time from the last bugfix point release to the next feature release is a bit longer though, about 2 months upstream (blame the folks who decided *.5 releases are not needed), plus about 2 weeks of testing in updates-testing to prevent regressions). You're also welcome to reopen bugs if upstream has a fix and you want us to backport it (but please don't do this if the fixed release is coming soon anyway and the bug is not critical). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Mary Ellen Foster wrote: > Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say > that the process works pretty well for me. Of course, I'm probably > somewhat more engaged in the process than average (e.g., I maintain a > few packages myself, and I've had an account at bugs.kde.org for > years). I do occasionally wish that I didn't have to do the upstream > report myself, but I can see the reasons for it. Oh, by the way, if you see an upstream bug with a matching Fedora bug and no Fedora folks CCed on it, feel free to CC me on it (the e-mail address I use on the KDE Bugzilla is the same showing up in the "From" header of this mail). AFAIK, Rex (rdieter at math.unl.edu) also likes to be CCed on those bugs. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: > When bugs are closed, they disappear from the reporter's bz frontpage. That's a Bugzilla misfeature (not to say "bug"). Bugzilla should default to showing closed bugs. Not just for this case, but also to avoid duplicate reports for: * NOTABUG reports (which keep getting duplicates because people don't notice the bugs closed as NOTABUG), * issues which are fixed in supported releases, but not in the EOL release the user is still using, * issues which are fixed in Rawhide, but cannot be fixed in existing releases for technical reasons etc. > Its far easier to leave the bug open and close it when the fixed package > gets pushed through bodi. That assumes we know when the bug got fixed in the first place, which isn't always the case (see my reply to Till Maas). > Yes. Many times when I am evaluating a package I look in bz to see what > bugs are open against it as a test sniff of what its quality might be > like. If the maintainer is closing everything as upstream bugs, I might be > installing a steaming hot pile of awful and not knowing its got lots of > problems. Then you need to fix your search to include closed bugs. > Also by closing unresolved bugs you are inviting duplicate bug reports. Because Bugzilla is broken. See above. Let's fix Bugzilla. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius wrote: > Then better be consequent: Shut down Fedora's bugzilla. We need the Bugzilla for issues which are actually Fedora's fault. But most of them are bugs in upstream code and upstream's to fix. They hit all distributions the same way, why should they be tracked in a random distribution's bug tracker? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Till Maas wrote: > If the new bugfix release update is created, do you include there all RH > bugs that are closed UPSTREAM but fixed with this update? Well, we try to reference fixed bugs, but often we don't even know that a bug was fixed by an upstream bugfix release until after the fact. In fact upstream themselves don't always realize it, upstream bugs occasionally get closed only weeks after the release as "seems fixed, can't reproduce with 4.x.y" or "apparently the fix for kde#123456 also fixed this one". Large projects like KDE have way too many bug reports to keep track of all of them. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Jud Craft wrote: > Support != upstream. It's a symptom of the fact that the open source > community is where people who create goods often don't do top-down > support of those goods to end-users, the final recipient. > > Here's the problem: You all agree that end-users should seek out > support. The reason why "they should go to upstream" is split isn't > because Seeking Support = Bad. Seeking Support = Good. You're split > because Having Outsiders Navigate Two/Three Layers of Community > Indirection = Bad. Fixing bugs is a service we do to end users. If they don't want to use the service the way we provide it, that's fine with me, we can just close their stuff as INSUFFICIENT_DATA and move on. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
I think a package maintainers responsibilities should be to incorporate any back-ported bug fixes, and ensure the package is reasonably fit for end users... if they can't do this, I don't think they should be packaging that software (whether it be due to individual skill set, or simply the upstream state). I wish Bugzilla had a way to track bugs in different instances of itself, that way once a package maintainer has figured out it's not a packaging issue, he can simply send it upstream, and have it all tracked as one bug from there - propagating that to whatever other instances have linked to it (read other distros with the same bug). This would simplify a lot of things for maintainers, and save them a lot of time also. Things like the auto-crash handler will help with users that don't wish to learn technical details, with the debugfs simplifying everything fairly well to ensure bug reports are useful. This often results in repeated bug reports though, so I hope they take lessons learned from apport into account here. Overall, I do not believe that package maintainers need to necessarily be programmers, and I believe upstream should have some say in most bug fixes. Of course it helps if they actually know the software, rather than just being competent with the packaging tools, but that starts to raise the barrier for contribution, so I don't know if requiring that is a good idea... what I state above goes a long way to ensuring they don't need to be programmers though. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 08:45:21PM +0200, Reindl Harald wrote: > I think it is simple BAD to close bugreports with "upstream"! +1 That's one step away from just ignoring the user. > So i think the maintainer should play as "relay", taking fedora-bugreports > and in many cases report them with much more knowing about the software > upstream. This is what I posted yesterday. The package maintainer should act as the face for their package(s) to the user. If the maintainer is not the upstream, then part of their job as maintainer should be to relay those bugs to the upstream, opening the bugs there, and then ensuring any patches or updates are moved into Fedora as soon as they're available. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste ná Béarla cliste. pgpppanvjrW1A.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 4, 2009 at 11:37 AM, Ralf Corsepius wrote: > David Tardon wrote: >> >> Let me try another analogy: How do you handle health problems? >> >> You'll visit your doctor. You'll expect him to identify the problem and >> to take appropriate steps to solve your issue--that may well be just him >> sending you to a specialist. Would you expect your doctor to serve as a >> proxy between you and the specialist? Or even substitute you for >> checkup? I wouldn't. That, in fact...is...exactly how it works. There's too much knowledge. A general-specialized entity has to forward clients to a super-specialized entity for super-specialized service. You can't expect one entity (when the entity = human) to be able to do everything. Don't use that analogy. It doesn't help. In my opinion, you're all missing the big picture. And in my audacity, let me suggest it. 1. End-users should be able to seek out support when they need it. You all agree. 2. End-users should be expected to go to upstream with their issues. You are split. 3. Maintainers should be expected to go to upstream with end-user's issues. You are split. Support != upstream. It's a symptom of the fact that the open source community is where people who create goods often don't do top-down support of those goods to end-users, the final recipient. Here's the problem: You all agree that end-users should seek out support. The reason why "they should go to upstream" is split isn't because Seeking Support = Bad. Seeking Support = Good. You're split because Having Outsiders Navigate Two/Three Layers of Community Indirection = Bad. In terms of navigating the community, open-source is as bad as any bureaucracy. It says "Let me forward you to X", when getting to X is appropriately daunting, and by the time you do you don't even know what to tell X. It's not "who should do it", it's "what do these users have to go through?" That's your problem, so rephrasing it in terms of "who should have to do the upstream contact?" is not the problem. That's delegating everything to one entity. End-users, package maintainers, upstream. One has the user experience. One delivers the user experience. One creates the user experience. Sadly, 2 and 3 aren't the same person. There must be a system that can allow 1 and 3 to talk directly, easily, without worrying about any adverse factors that 2 might have stuck into the works. (It does no good for end-users to work with upstream on packages that upstream doesn't even understand). Until someone is a genius enough to come up with these ideas, you're always going to have problems. So for the here and now: 1. Assume the average end-user will be of no help -- he should be expected to seek support, but he cannot be expected to navigate the open source community. A few will, but to be super-effective the barrier to entry must be drastically lowered. 2. Maintainers must realize that de facto -- even though it isn't ideal -- they'll have to take on some burden of upstream contact. And accept it. (While being a little grumpy. That's probably okay.) 3. You need an easier way for users to file for issues. All necessary metadata information gathering (versions, kernel, package names) should be automatic. The system should be smart enough to do that. (It seems like Fedora is getting there with its new reporting tools and on-demand debug utility.) Let the end-user do the only thing he can: describe what went wrong in plain english in a text-box, and then don't burden him with anything else. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Just to chime in here... I personally try and do the following with my bugs: - Look over the inital report. - Move to ASSIGNED and ask the reporter any further info I need to try and figure out if it's a packaging issue or upstream or bug or enhancement or what. - If its a packaging issue, I try and fix it. - If it's an enhancement/difficult upstream issue/etc I ask the reporter: "Hey, would you like to report this upstream and see if they can fix it?" If they say they don't want to for whatever reason, I do so. If they do, I get the bug # and add myself upstream to help out. I think the point is that one size doesn't fit all here. I don't think we can have a single policy to cover this. It depends on many factors, like: - Is upstream responsive? - Is the reporter responsive? - Is the bug something that the maintainer really feels should get fixed, even if the reporter is no longer responsive? - Is the bug something the maintainer can't duplicate for whatever reason? (ie, the reporter is needed to try fixes). I agree it's the role for maintainers to maintain their packages and work to help the reporters get their issues fixed. Whatever way they feel is best to do so. kevin signature.asc Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 4 Jun 2009, Reindl Harald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think it is simple BAD to close bugreports with "upstream"! For me as "enduser" of fedora i have one bugzilla and i really like to help with bugreports, try things if maintainer needs better explains what happens. I am the packager for some pkgs and I'm also one of the upstream maintainers. I'll close bugs 'upstream' when I've fixed them in the upstream tree but not yet pushed them out to fedora. -sv -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think it is simple BAD to close bugreports with "upstream"! For me as "enduser" of fedora i have one bugzilla and i really like to help with bugreports, try things if maintainer needs better explains what happens. But i have no time and no energy to register on the bugzilla of every piece of software i have installed and i can not look at bugzilla from rsync, kde, amarok. the whole time. Should the enduser try patches and svn-versions? NO he is user and that was it If someone maintains a package he can test this much better and understands many things the normal user never can and want to konw I know the maintainer can't too for all BUT he get's only bugs for packages which he maintains, he konws (or should know) the software he maintains and normally i think he/she have a watch at upstream-bugzilla and knows MUCH more about the upstream project as the most users So i think the maintainer should play as "relay", taking fedora-bugreports and in many cases report them with much more knowing about the software upstream. If you want that the enduser report bugs upstream you get no repsonse in many cases because the user will say "WTF i wanted to help and you want to say me exactly how i have to help" and after this happens trhee times he is frustrated and will never ever report bugs As poweruser you could use many applications and find mny small bugs in all of them - If you try to handle all of that stuff in the upstream-project and have a fulltimejob and a family you would egt a problem - reporting bugs on fedora-bz or lost your life and deal with all upstream-projects you know Forget it - I think this is maintainers work or you will lost respnses time after time -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkooFkEACgkQhmBjz394AnlLzgCglDQ465W4reprEmCbmoiYgw48 X1MAoJj3mdTmlo+SCD+kC/myICY3V+SP =b+9R -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, Jun 3, 2009 at 9:46 AM, Ralf Corsepius wrote: > Michael Schwendt wrote: >> >> On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: >> >>> I consider users (esp. bug reporters) not to be "the dumb pigs eating the >>> hog wash they get for free", or "clueless comsumer masses" aborbing anything >>> they don't pay for with money, but them to be the foundation of your work >>> and them to be valuable business partners, paying in immaterial payment >>> (e.g. feedback, such as bug reports). >> >> That's an idealistic [over-simplified] point of view which I don't want to >> agree with. > > Well, whether it's idealistic or not is irrelevant. It's one of the > foundations of open source. > > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to upstream. > Wrt. evolution, I was an ordinary user and am not interested in getting > further involved. > > As simple as it is: I felt sufficiently pissed of by this guy to leave him > and his upstream alone, ... so be it, he wanted it this way. > > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. > Bz #'s? You seem to like to complain a lot about how crappy of a job us Red Hatters do, but don't offer any concrete evidence. I would be very much interested in seeing these "many" people at RH who exhibit this behaviour. One anecdotal interaction where we only have your word about what happened does not count as sufficient evidence for the sweeping generalization that @RH people don't care about bugs. Josef -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 04:57:32 pm Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). When bugs are closed, they disappear from the reporter's bz frontpage. Its far easier to leave the bug open and close it when the fixed package gets pushed through bodi. > Until then, why do we need to have the bug open in 2 places? Yes. Many times when I am evaluating a package I look in bz to see what bugs are open against it as a test sniff of what its quality might be like. If the maintainer is closing everything as upstream bugs, I might be installing a steaming hot pile of awful and not knowing its got lots of problems. Also by closing unresolved bugs you are inviting duplicate bug reports. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 17:27 +0100, Paul Howarth wrote: > I'll happily raise upstream bugs myself but it irks me when maintainers > close Fedora bugs with the UPSTREAM resolution without actually taking > the upstream fix and bringing it into Fedora. > > If I've reported a bug in Fedora bugzilla it's because the bug is > present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a > bug closed UPSTREAM doesn't help at all if I have a real problem with a > Fedora package. In Mandriva I had it set up so Bugzilla has both an UPSTREAM *resolution* and an UPSTREAM *keyword*. This handles this situation. If, say, the bug is in a package that gets frequent releases, and was filed on the development release, you can just use CLOSED UPSTREAM, because you can rely on the fact that there'll be a new upstream release of the package soon after the upstream report is fixed, you (the maintainer) will then naturally package the new release, and the fix for the bug will have been rolled into the distribution package without you having to do anything besides your normal packaging work. In other situations, you can set the UPSTREAM keyword, so the bug remains open but you know it's being handled upstream and you need to bring the fix downstream once it's available upstream. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 14:18 +0200, Nicolas Mailhot wrote: > Last time I reported this problem in the bugzilla component of redhat > bugzilla (I complained about all the columns in list view no one uses > when "last change" is not even displayed) the answer was that the > people in charge did not want to deviate from upstream (bugzilla) > defaults. > > Which, given all the historic redhat bugzilla customization, was a bit > rich Key word there is 'historic'. The experience with all that historic customization is the reason why, currently, the Bugzilla maintainers are trying to avoid having customization :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Kevin Kofler wrote: Ralf Corsepius wrote: Signing up for an upstream Bugzilla account takes at most 5 minutes, ... when being interested in an upstream ... wasting much more time on investigating issues ... There are other packages and packagers (noteworthy many of the @RH) who exhibit the same "push reporters around" behavior. That's because that's our policy, and rightfully so. I disagree. It's a serious management error. Now combine this with the "report bugs" phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. Then let's say: Report bugs, to the right place of course (usually upstream)! Then better be consequent: Shut down Fedora's bugzilla. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed June 3 2009, Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). > > Until then, why do we need to have the bug open in 2 places? The ball is in > upstream's court as long as we're waiting for them to fix the issue, we've > done our part as packagers, so as far as we're concerned the issue is > closed. As for those cases where the upstream maintainer is the same as the If the new bugfix release update is created, do you include there all RH bugs that are closed UPSTREAM but fixed with this update? Keeping the bugs open to not forget to add the to the update is imho the most important reason for bugs that are already reported upstream. Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Jaroslav Reznik wrote:
You can ask our users if they are satisfied or not. From comments and posts I
think they ARE!
It's the nature of bugs that they often only affect a minority ("power
users", "corner cases").
If they are affecting the majority of users, they are likely to be
caught early and thus not to be "exposed to the wild".
Check our fedora-kde list, IRC channel #fedora-kde as most of
bugs are solved there even before they hit BZ...
Well, I only have to look into my fc11 test system's /var/log/messages
to watch kde and other bugs ...
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On 06/04/2009 02:01 AM, Tim Waugh wrote: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. > > One reason for my belief is that I've seen the situation from the other > side: as an upstream maintainer for a package, getting bug reports > directly from users of a packaged version in another operating system. > > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. > > My point is that it isn't only the people reporting bugs that get > frustrated by "go report it upstream", it is also the larger free > software community. +1 For an upstream taking in bugs, a package maintainer reporting bugs is usually a much better resource than a random user. Random users disappear. They switch software to escape bugs. They switch distros. They report a bug that they encounter once but don't have the persistence to write down the exact steps that they used to create it. Good package maintainers do. It's much easier to collaboratively fix issues with a package maintainer because the package maintainer has invested time in getting the package into their distribution and wants the software to be bug-free as much as upstream. The end user is more fickle. -Toshio signature.asc Description: OpenPGP digital signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
David Tardon wrote:
On Thu, Jun 04, 2009 at 07:23:05AM +0200, Ralf Corsepius wrote:
Steven M. Parrish wrote:
Many people have mentioned that it is not right to ask the users to
file their bug reports upstream. I ask why not?
Let me summarize what I already wrote elsewhere in this thread:
* Users aren't necessarily developers.
* Users aren't necessarily interested in getting involved upstream.
* Users are reporting bugs against your product (your package in
Fedora), not against upstream's work (somebody else's product).
Let me try an analogy: How do you handle defects/malfunctions with your
car?
You'll visit your car dealer/a garage and report the issue to them.
You'll expect them to identify the problem and to take appropriate steps
to solve your issue.
Let me try another analogy: How do you handle health problems?
You'll visit your doctor. You'll expect him to identify the problem and
to take appropriate steps to solve your issue--that may well be just him
sending you to a specialist.
Correct.
Would you expect your doctor to serve as a
proxy between you and the specialist? Or even substitute you for
checkup? I wouldn't.
Of course, but in this case "the human" am "the product", which need to
go through the "bug fixing process".
You don't expect them to direct you to the car's
manufacturer or a component manufacturer and to discuss technical
details you have no knowledge about with them ("Is the stuttering engine
cause by triac 7 in a component A you haven't heard about before" or by
the hall sensor in component B you also haven't heard about before).
Who spoke about technical details?
I do, because analyzing bugs often requires a deep understanding of a
package's infrastructure/details/etc.. You can't expect end-users to be
able to have this understanding (nor to be interested in them), but you
can expect a Fedora packager to have it and to act as relay.
Have you ever been asked to look into
the source code of some project? I don't think so.
Oh, many times ...
An upstream developer
can ask better/more detailed questions than a packager, but that's only
to be expected.
Theoretically, yes ... in practice ... not always.
Btw, I'm really interested to hear why answering questions of an
upstream developer through a packager as a proxy is better than
answering the same questions directly...
I never said this - Upstreams contacting reporters, with a package
maintainer acting as proxy is an option.
Demanding end-users to get involved into upstreams and rendering Fedora
packagers into "stupid packaging robots", like Kevin's proposal implies,
is simply absurd.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Mary Ellen Foster wrote: 2009/6/4 Kevin Kofler : Michal Hlavinka wrote: Yes, but how will you notice reporter needs (your) help if bug is closed upstream? By CCing ourselves on the upstream bug when we close ours. Kevin Kofler Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say that the process works pretty well for me. Of course, I'm probably somewhat more engaged in the process than average (e.g., I maintain a few packages myself, and I've had an account at bugs.kde.org for years). I do occasionally wish that I didn't have to do the upstream report myself, but I can see the reasons for it. I'll happily raise upstream bugs myself but it irks me when maintainers close Fedora bugs with the UPSTREAM resolution without actually taking the upstream fix and bringing it into Fedora. If I've reported a bug in Fedora bugzilla it's because the bug is present in Fedora and I'd like to see it fixed *in Fedora*. So seeing a bug closed UPSTREAM doesn't help at all if I have a real problem with a Fedora package. Paul. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
2009/6/4 Kevin Kofler : > Michal Hlavinka wrote: >> Yes, but how will you notice reporter needs (your) help if bug is closed >> upstream? > > By CCing ourselves on the upstream bug when we close ours. > > Kevin Kofler Speaking as a semi-frequent reporter of Fedora KDE bugs, I can say that the process works pretty well for me. Of course, I'm probably somewhat more engaged in the process than average (e.g., I maintain a few packages myself, and I've had an account at bugs.kde.org for years). I do occasionally wish that I didn't have to do the upstream report myself, but I can see the reasons for it. MEF -- Mary Ellen Foster -- http://homepages.inf.ed.ac.uk/mef/ ICCS, School of Informatics, University of Edinburgh The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Tim Waugh wrote: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. +1, for the most part, but distributing the load (to users, triagers, whatever) for doing so isn't wrong either, imo. Unreproducible bugs are where the "fun" begins. -- Rex -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Michal Hlavinka wrote: > Yes, but how will you notice reporter needs (your) help if bug is closed > upstream? By CCing ourselves on the upstream bug when we close ours. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Nils Philippsen wrote: On Thu, 2009-06-04 at 08:54 +0200, Ralf Corsepius wrote: Conrad Meyer wrote: On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: Conrad Meyer wrote: On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: Let me try an analogy: How do you handle defects/malfunctions with your car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? Have you ever seen an open source car? The Fedora "car" manufacturer is the "fedora community", assembling it from "upstream" components. Ralf That's the idea, opensource behaves completely different from a car manufacturer. Wrong. It doesn't. I don't think we have the power to (nor would we want to) force upstream to do certain things in a certain way, for ridiculously low prices and "no we won't pay you on delivery" but 3 months later. The relationship between us and upstream is significantly different from a car manufacturer and its suppliers. I am talking about "customer"<->"manufacturer" and "manufacturer"<->"component supplier" relations. Wrt. this the relations are not any different: * manufacturer buys parts at supplier. ... Fedora "buys-in parts from upstreams". * in case of problems. customer contacts "point of sale" (garage/car dealer), point of sale processes request ... Fedora users contact Fedora/RH BZ, ... What Kevin proposes is equal to demanding car drivers to a) First identify the defective component b) Then to identify and contact the component's supplier This procedure is ridiculous. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
> > What if upstream answers: ok, thanks for bug report, please try this > > patch... or I've fixed it in repo, please try svn snapshot, if it's > > fixed for you? > > In that case we can roll a fixed package (e.g. as a scratch build). (If > upstream says "try a current snapshot, it should be fixed", I'll usually > try to find the actual commit and, if I don't find it, ask "can you please > point me to the commit that fixed it so we can backport it?". But for some > packages, just upgrading to the newer snapshot is the better solution.) But > until that happens, there's no reason for the packager to be involved. Yes, but how will you notice reporter needs (your) help if bug is closed upstream? -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, 2009-06-04 at 08:54 +0200, Ralf Corsepius wrote: > Conrad Meyer wrote: > > On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: > >> Conrad Meyer wrote: > >>> On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > Let me try an analogy: How do you handle defects/malfunctions with your > car? > >>> Did a bunch of hobbyists from around the world build your car by > >>> communicating over the internet? > >> Have you ever seen an open source car? > >> > >> The Fedora "car" manufacturer is the "fedora community", assembling it > >> from "upstream" components. > >> > >> Ralf > > > > That's the idea, opensource behaves completely different from a car > > manufacturer. > Wrong. It doesn't. I don't think we have the power to (nor would we want to) force upstream to do certain things in a certain way, for ridiculously low prices and "no we won't pay you on delivery" but 3 months later. The relationship between us and upstream is significantly different from a car manufacturer and its suppliers. Nils -- Nils Philippsen "Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety." -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Kevin Kofler wrote: Ralf Corsepius wrote: Me thinks, your are just being lazy and are trying to rudely push around Fedora's user base. "customer-friendliness" is something entirely different from your attitude. Fedora's "customers" aren't paying us anything, That's the way it was\is setup. so they can't expect to get the equivalent of paid support. We're doing what we can to help people. +1 But expecting unpaid volunteers to relieve the user of even the slightest chore when he/she can easily do it him/herself and to spend his/her volunteer time playing proxy between user and upstream is quite rude. The users are getting something for free, it's not their right to complain about the gift horse saying they wanted a pony instead. But they are entitled to know the horse can walk. Who wants a lame horse paid for or not. However as I studied Customer Affairs, I will chime in. People aka users, can be thick. But paid or not, it is not the Packagers place to tell them so. One Disgruntled Customer\User\Person, is bad publicity. Especially if the Project wants users to both *Use and test* the Offerings. What may be worth looking into, is an expanded version of the Anaconda reported. Whereby if a bug happens, a window will pop up encouraging user to report bug's. If necessary at that point sign user up to bugzilla Packageer\Maintainer will determine if Fedora Problem\ with Project help if necessary. If upstream problem, ask reporter if they are *OK*, with bug going upstream, and have a generic helpful text ready to help them. Which could be C&P into bug comment. Frank -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Michal Hlavinka wrote: > What if upstream answers: ok, thanks for bug report, please try this > patch... or I've fixed it in repo, please try svn snapshot, if it's fixed > for you? In that case we can roll a fixed package (e.g. as a scratch build). (If upstream says "try a current snapshot, it should be fixed", I'll usually try to find the actual commit and, if I don't find it, ask "can you please point me to the commit that fixed it so we can backport it?". But for some packages, just upgrading to the newer snapshot is the better solution.) But until that happens, there's no reason for the packager to be involved. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Adam Williamson wrote: > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. If the bug is important enough to block one of our trackers, we won't close it UPSTREAM, we'll even try to fix it on our own (and then upstream our fix) if upstream doesn't come up with a fix soon enough. But we can't reserve that treatment to every single KDE bug, there are too many! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Matej Cepl wrote: > I am quite surprised to totally agree with you this time ;-), and I am > even more surprised to finally a situation where actually technology > could help to resolve interpersonal problems, but I think if somebody > skilled in programming Perl (hint, hint) would work on https:// > bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream > counterparts), situation of our reporters COULD improve. If that got implemented, that would indeed make this whole discussion moot. I agree it'd be great, I just don't see it happening soon. A big issue is how upstream would validate the e-mail addresses we're entering in the CC list if we forward our bug (including CC) into their Bugzilla instance. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius wrote: > Me thinks, your are just being lazy and are trying to rudely push around > Fedora's user base. "customer-friendliness" is something entirely > different from your attitude. Fedora's "customers" aren't paying us anything, so they can't expect to get the equivalent of paid support. We're doing what we can to help people. But expecting unpaid volunteers to relieve the user of even the slightest chore when he/she can easily do it him/herself and to spend his/her volunteer time playing proxy between user and upstream is quite rude. The users are getting something for free, it's not their right to complain about the gift horse saying they wanted a pony instead. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
>> You are still presuming your users to be interested in developing and >> working on your package. >> >> This simply does not apply - They want to use your package. > > I see 2 possibilities: > * either the user wants his/her bug fixed, in that case he/she is > responsible for reporting it to the appropriate place, > * or the user does not care about having the bug fixed, that's fine with me, > we can just close it, less work for me. ;-) If somebody actually cares, > he/she'll report it upstream. If nobody cares, why bother fixing it? And why can't this "somebody" be the package maintainer ? I mean, a package maintainer should care about the software he packages, otherwise, why is he packaging it ? :-/ -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Tim Waugh wrote: > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. We can build a patched package if there's a fix to try, but that doesn't mean the user shouldn't be CCed on or the reporter of the upstream bug as well, it just means we should be CCed too (which we usually are, unless we forget for some reason, we're just human too). Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius wrote: > You are still presuming your users to be interested in developing and > working on your package. > > This simply does not apply - They want to use your package. I see 2 possibilities: * either the user wants his/her bug fixed, in that case he/she is responsible for reporting it to the appropriate place, * or the user does not care about having the bug fixed, that's fine with me, we can just close it, less work for me. ;-) If somebody actually cares, he/she'll report it upstream. If nobody cares, why bother fixing it? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
* Till Maas [04/06/2009 13:41] : > > In conclusion, more than 66% of the form elements can be removed for the > unexperienced bug reporter. Also the component selection process could be > made You are seeing some of these elements because you are in the 'editbugs' group. Unexperienced bug reporters will probably not be. Emmanuel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On 06/04/2009 05:48 PM, Nicolas Mailhot wrote: > > Last time I reported this problem in the bugzilla component of redhat > bugzilla (I complained about all the columns in list view no one uses > when "last change" is not even displayed) the answer was that the > people in charge did not want to deviate from upstream (bugzilla) > defaults. > > Which, given all the historic redhat bugzilla customization, was a bit > rich If you notice, Red Hat is steadily moving away from that and the customizations are either being upstream or removed and with new releases. So it matches the current direction. However it should be possible to turn off features we don't use in our bugzilla instance. Rahul -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Till Maas wrote: > On Wed June 3 2009, Kevin Kofler wrote: > >> And I don't think we can make bug reports any easier, the point is that the >> information is required, those "complicated" forms are there to request the >> information we need. > > I disagree: > > On https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora there are around > 29 form elements and the majority of these elements does not need to be used > by the non experienced bug reporter or are not used at all. > > Absolutely required are imho: component, version, summary, description, > security sensitive bug, External Bug and sometimes attachments or URL (8 > elements). Rarely the platform is required, but there does not need to be such > a long list of different archs for the normal user. > There are also some elements that are not used at all: OS, Target Milestone, > QA Contact, Estimated Hours and Deadline (5 elements) or not yet always used: > severity and priority. Also the "Fedora Project Contributors" checkbox seems > not to be used. > > The other elements are only used by experienced bug reporters or within the > triage process, e.g. Assign To, CC, Alias, Whiteboard, Clone Of, Keywords, > Depends on, blocks, 4 flags (12 elements). > > In conclusion, more than 66% of the form elements can be removed for the > unexperienced bug reporter. Also the component selection process could be made > easier, because the mapping from rpms to components could be made > automatically after a bug reporter supplied the name of the rpm he had > problems with. > > Regards > Till Maybe a form (like Review Request) for Simple Bug Report (or something) that's the default? I have the bug report page bookmarked in any case (the trail of links to get there from the front page is too much IMO; I haven't been able to get it below 3 or 4). - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkonu60ACgkQiPi+MRHG3qSjNQCfRThyKRYQaTh6ok55CxGDeyZ8 N4sAnRMfJm9/Qkh4IW2wgzNJ5pvazBRT =Ij9o -END PGP SIGNATURE- -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Le Jeu 4 juin 2009 12:04, Till Maas a écrit : > In conclusion, more than 66% of the form elements can be removed for > the unexperienced bug reporter. Last time I reported this problem in the bugzilla component of redhat bugzilla (I complained about all the columns in list view no one uses when "last change" is not even displayed) the answer was that the people in charge did not want to deviate from upstream (bugzilla) defaults. Which, given all the historic redhat bugzilla customization, was a bit rich -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 11:01:56 Tim Waugh escribió: > My own opinion is that the package maintainer is responsible for > reporting bugs upstream when they are able to reproduce them. > > One reason for my belief is that I've seen the situation from the other > side: as an upstream maintainer for a package, getting bug reports > directly from users of a packaged version in another operating system. > > It can be a frustrating experience because the person reporting the bug > can never be quite sure which version they are using (due to additional > patches used in packaging), and generally are not able to try out > suggested patches or pull from a source code repository. As I said - I don't want to left user in upstream jungle :-) It's more like moving bug closer to developer - user which report it is in contact with developer (that real upstream developer) and we can provide for upstream more details from Fedora side + prepare package for user to test it etc. Simple - collaboration - open source :-) Aim is fix the bug - then user is happy, we are happy and upstream is happy! > My point is that it isn't only the people reporting bugs that get > frustrated by "go report it upstream", it is also the larger free > software community. > > Another reason for maintainers to give bug reports due diligence is that > it is hard to report bugs. Package maintainers may not always > appreciate this, since they do it all the time, but look at bugzilla as > though you've never seen it before (or just remember back to when you > first saw it) -- it is hard to fill out a huge form, and if the problem > is not severe enough to warrant your time on it (or you aren't even sure > if it's a bug) you may just not bother. But this is another problem - BZ is really big monster (every time I'm reporting bug I'm scared :D). I have small PyGtk RHBZ reporter, maybe I'll release it some day (there are hardcoded passwords etc...). > Bug reporters are absolutely essential to healthy free software and > should be treated with respect. They are our eyes. > > Roll on ABRT. And new Dr. Konqui with nice guide to report crash - directly upstream. I talked with ABRT developers about closer collaboration, we'll see. Jaroslav > > Tim. > */ -- Jaroslav Řezník Associate Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 731 455 332 Red Hat, Inc. http://cz.redhat.com/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Adam Williamson, Wed, 03 Jun 2009 14:35:07 -0700: > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. For an exmaple see https://bugzilla.redhat.com/show_bug.cgi?id=494985 and why it doesn't work https://bugzilla.redhat.com/show_bug.cgi?id=452962 (and yes, it would be wonderful if we could go even further ... blocking our bugs by upstream ones). Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed June 3 2009, Kevin Kofler wrote: > And I don't think we can make bug reports any easier, the point is that the > information is required, those "complicated" forms are there to request the > information we need. I disagree: On https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora there are around 29 form elements and the majority of these elements does not need to be used by the non experienced bug reporter or are not used at all. Absolutely required are imho: component, version, summary, description, security sensitive bug, External Bug and sometimes attachments or URL (8 elements). Rarely the platform is required, but there does not need to be such a long list of different archs for the normal user. There are also some elements that are not used at all: OS, Target Milestone, QA Contact, Estimated Hours and Deadline (5 elements) or not yet always used: severity and priority. Also the "Fedora Project Contributors" checkbox seems not to be used. The other elements are only used by experienced bug reporters or within the triage process, e.g. Assign To, CC, Alias, Whiteboard, Clone Of, Keywords, Depends on, blocks, 4 flags (12 elements). In conclusion, more than 66% of the form elements can be removed for the unexperienced bug reporter. Also the component selection process could be made easier, because the mapping from rpms to components could be made automatically after a bug reporter supplied the name of the rpm he had problems with. Regards Till signature.asc Description: This is a digitally signed message part. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Matej Cepl wrote: but I think if somebody skilled in programming Perl (hint, hint) would work on https:// bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream counterparts), situation of our reporters COULD improve. Matěj Is it time then to setup programming-l...@fedoraproject.org as distinct from Packaging\Maintaining Where those involved in the project and aspiring programmers\students can maybe be sent. For both mentoring\ and practical involvement with some sort of wiki page\wishlist. Frank -- msn: frankly3d skype: frankly3d Mailing-List Reply to: Mailing-List Still Learning, Unicode where possible -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius, Wed, 03 Jun 2009 14:01:46 +0200: >> We are not forcing anyone to do anything but we think direct >> communication between user and developer is much more better > > I consider maintainers redirecting arbitrary reporters to upstreams to > be rude and hostile, because they are presuming the reporter to be > * interested in tracking down bugs > * interested in getting involved into upstreams > * technically able to do so. > > This occasionally applies to developers - To normal users it usally > doesn't apply, they want "to have their issue fixed". I am quite surprised to totally agree with you this time ;-), and I am even more surprised to finally a situation where actually technology could help to resolve interpersonal problems, but I think if somebody skilled in programming Perl (hint, hint) would work on https:// bugzilla.redhat.com/show_bug.cgi?id=189813 (and its upstream counterparts), situation of our reporters COULD improve. Matěj -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Jaroslav Reznik, Wed, 03 Jun 2009 13:01:01 +0200: > Most bugs are filled by quite technically skilled users. It doesn't seem so from my point of view. Depends on the importance of the bug (when Xorg doesn't start at all, they find a way to bugzilla). Moreover, we want to move from fora to bugzilla ... my personal hatred to fora is comparable only with my disgust for dušený mozeček (intentionally not translating to English to protect innocent ;-)). Matej -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
My own opinion is that the package maintainer is responsible for reporting bugs upstream when they are able to reproduce them. One reason for my belief is that I've seen the situation from the other side: as an upstream maintainer for a package, getting bug reports directly from users of a packaged version in another operating system. It can be a frustrating experience because the person reporting the bug can never be quite sure which version they are using (due to additional patches used in packaging), and generally are not able to try out suggested patches or pull from a source code repository. My point is that it isn't only the people reporting bugs that get frustrated by "go report it upstream", it is also the larger free software community. Another reason for maintainers to give bug reports due diligence is that it is hard to report bugs. Package maintainers may not always appreciate this, since they do it all the time, but look at bugzilla as though you've never seen it before (or just remember back to when you first saw it) -- it is hard to fill out a huge form, and if the problem is not severe enough to warrant your time on it (or you aren't even sure if it's a bug) you may just not bother. Bug reporters are absolutely essential to healthy free software and should be treated with respect. They are our eyes. Roll on ABRT. Tim. */ signature.asc Description: This is a digitally signed message part -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 2009-06-03 at 15:46 +0200, Ralf Corsepius wrote: > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to > upstream. Wrt. evolution, I was an ordinary user and am not interested > in getting further involved. +1 (Though not related to evolution, mbarnes has been great to me) I would like to report bugs that I happen to stumble over even when I dont need it fixed or dont even need the package. I want to report that the bug is there and provide the details that I can, so that fedora knows that the bug exists. I dont want to go around chasing developers upstream if I dont really care about the bug/package. However, on a few instances I have been met with a negative attitude stating that "You MUST report this " (...to upstream). This has stopped me from sending bug reports to fedora unless I really do need the bug fixed or actually use the package. The program in this particular case was one I was just testing out of curiosity (one of several). I found a bug and reported it. I dont have time to chase every bug upstream. This was a close-to-f11-rawhide version. It did get "CLOSED UPSTREAM". I dont want to go personal on this because I know this is a matter of opinion and several other maintainers are also following this routine, so I wont post the bug number here. However any sufficiently interested parties would have no problem searching through my reported bugs to find it. (The others would however be harder since they were posted from a different email address) I do hope this gets changed, because I believe it is valuable to fedora to know what bugs do exist, especially when about to release a new version. Sincerly Hans K. Rosbach -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 23:35:07 Adam Williamson escribió: > On Wed, 2009-06-03 at 22:57 +0200, Kevin Kofler wrote: > > Steve Grubb wrote: > > > And then should the bug be closed hoping that one day you pull in a > > > package that solves the user's problem? > > > > If the bug is fixed upstream, the Fedora report can be reopened with a > > request to backport the fix (but that should only be done if it's > > important enough that it cannot wait for the next bugfix update getting > > pushed anyway). > > > > Until then, why do we need to have the bug open in 2 places? > > There's an obvious answer to this question: we track the importance of > issues to Fedora via the Fedora bug tracker, not via upstream bug > trackers. There's no way I can mark a bug in the KDE bug tracker as > blocking the release of Fedora 12. Yes, there's the way to do it - we always have tracker bug for most important issues we have found! And not only for new releases like Fedora 12, but for even for new versions in older releases (like current Qt 4.5.1 tracker [1] which blocks this release nearly about one month). If you think your bug is so important and it's blocker, talk to us, we add it to our tracker and then we are discussing progress on every KDE SIG meeting - you can join, you're welcome! If you join us, you can drive Fedora/KDE development even as users and only users... These important blocking bugs are never closed without working solution. [1] https://bugzilla.redhat.com/show_bug.cgi?id=497658 Jaroslav > (longer email on the whole thread coming.) > -- > Adam Williamson > Fedora QA Community Monkey > IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org > http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Miércoles 03 Junio 2009 22:27:13 Kevin Kofler escribió: > Jaroslav Reznik wrote: > > Most bugs are filled by quite technically skilled users. For average > > users it doesn't depend if it is RH bugzilla or upstream's bugzilla - > > it's too complicated for them. I know - it's another story... For these > > people forums are much more better. > > Uh, forums are a horrible place for bug reports. For one because developers > usually won't read them. It's no use complaining about bugs in front of an > audience of other newbies, the bugs must be reported to the people who > actually care, and that's what bug trackers are for. Another issue is that > forums are freeform, they don't have any sort of form which tells users > what information is required. For bug reports - indeed. But to help users - forums/mailing list are great. > > I hate lazy idiots whining about bugs in forums when they never bothered > reporting them to the developers. Yes, some users are lazy, asking stupid questions and fighting in forum. But for users it's not easy to report bug, power users should help them (and I'm trying as much I can) > > And I don't think we can make bug reports any easier, the point is that the > information is required, those "complicated" forms are there to request the > information we need. Bug report can't be easier ever but it's responsible of us to help people but first they have to know about BZ at least :D I'm helping people on some Czech forums everyday, often they PM to contact me directly and 99% of the problems (they think it's a bug) are not actually bugs... > Kevin Kofler Jaroslav -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
> Hello, > > I don't want to start a long thread, but just to ask a couple questions for > my own clarification. Does a maintainer's responsibilities end with > packaging bugs? IOW, if there is a problem in the package that is _broken > code_ do they need to do something about it or is it acceptable for them to > close the bug and say talk to upstream? Do we want those bugs open to track > when the bug is fixed in the distro? I'll accept whatever the answer is, > I'm just curious. I think it depends on what type of users we want. If we want only skilled users (programmers) we can close most bugs upstream. But this is not a good way if we want also less skilled users (and bug reports from them). There are tons of packages in fedora, most of them have own upstream. For every package you need usually some kind of bugzilla registration (or mailing list subscription), which is (at least) a little bit odd - expecting users are willing to have so many subscriptions/registrations. The second problem are less skilled users. What if upstream answers: ok, thanks for bug report, please try this patch... or I've fixed it in repo, please try svn snapshot, if it's fixed for you? We can't expect all users are skilled for this. Michal -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Jueves 04 Junio 2009 08:59:23 Ralf Corsepius escribió: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> Not if its closed. How would I be notified that the fix is in Fedora? If > >> the bug is severe enough, shouldn't the upstream commit be applied to > >> Fedora's package and the package pushed out for testing? Is all this > >> going to happen if the bug is closed? > > > > You're supposed to be the reporter of or CCed on the upstream bug, then > > you'll get notified of the fix and can reopen our bug asking for a > > backport of the fix if it's really that important (but keep in mind that > > Fedora packages often get upgraded to a bugfix release anyway, for > > example our KDE gets upgraded to a bugfix release about once a month). > > You are still presuming your users to be interested in developing and > working on your package. Yes and no - most of our bugs come from well known contributors - it's safe to them to say - please, report it upstream. They just ask as - is it downstream or upstream issue? Are you aware of this issue? If we know/we can see that bugreporter is ordinary user, we're trying to help him report this issue or we simply do it. It's not - upstream, close, shut your mouth, don't bother us! My final conclussion - there are power users, there are ordinary users, some of them of better knowledge, some worst - and we should help them, guide them - it's our work and we have to take care about them individually... There can't be one policy to match all cases... > This simply does not apply - They want to use your package. > > > As maintainers, we will also try to CC ourselves on those upstream bugs > > to track their status, but utilimately it's the reporter who cares the > > most about seeing his/her bug fixed. > > I could not disagree more. People with this kind of attude should lable > themselves maintainer and stop packaging packages in Fedora. You can ask our users if they are satisfied or not. From comments and posts I think they ARE! Check our fedora-kde list, IRC channel #fedora-kde as most of bugs are solved there even before they hit BZ... Jaroslav > Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 08:59:23AM +0200, Ralf Corsepius wrote: > Kevin Kofler wrote: >> Steve Grubb wrote: >>> Not if its closed. How would I be notified that the fix is in Fedora? If >>> the bug is severe enough, shouldn't the upstream commit be applied to >>> Fedora's package and the package pushed out for testing? Is all this going >>> to happen if the bug is closed? >> >> You're supposed to be the reporter of or CCed on the upstream bug, then >> you'll get notified of the fix and can reopen our bug asking for a backport >> of the fix if it's really that important (but keep in mind that Fedora >> packages often get upgraded to a bugfix release anyway, for example our KDE >> gets upgraded to a bugfix release about once a month). > You are still presuming your users to be interested in developing and > working on your package. > I think it has been already mentioned in this thread, but I'm going to mention it again (in, probably void, hope you'll understand it): One of principles of open source development is a relationship between the developer and the user. If the relationship be functioning rightly, the user should be willing _to give_ something back, not just _to take_. > This simply does not apply - They want to use your package. If you don't accept that, go on and buy RHEL or SLED or MacOS X or even MS Windows and you'll get the attendance you expect. Maybe. Maybe not. Maybe product management decides your bug is not important enough or your request for enhancement wouldn't be wanted by majority of users and rejects it... As a last instance, you can always hire a free lance programmer to fix the bugs for you, provided you have the sources and rights to modify them. David -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Kevin Kofler wrote: Ralf Corsepius wrote: I consider maintainers redirecting arbitrary reporters to upstreams to be rude and hostile, because they are presuming the reporter to be * interested in tracking down bugs If you don't care about your bug, why are you reporting it in the first place? Because it's not "my bug", it's a bug in a package, which I am using, which is exposing a bug. Only very few people report bugs just to be nice (and those will be happy to do anything to help us), most people report bugs because they want them fixed. Yes, they want to have them fixed ... and they use b...@rh to communicate it, because Fedora is the product they are using. * interested in getting involved into upstreams * technically able to do so. If they're able to report the bug to us, they're also able to report it to upstream, the information they need to provide is basically the same (e.g. for KDE, they just need to pick "Fedora packages" from a dropdown to let upstream know what distro they're using, other than that, the requested information is exactly the same AFAICT). Non-sense. A bug is fixed in Fedora when a package maintainer ships fixed packages, not when upstream "starts looking into it" or "acknowledges it". This occasionally applies to developers - To normal users it usally doesn't apply, they want "to have their issue fixed". Then they need to do what it takes to get their issue fixed. Talking to upstream, helping with tracking the bug down etc. are all part of that. Non-sense. Me thinks, your are just being lazy and are trying to rudely push around Fedora's user base. "customer-friendliness" is something entirely different from your attitude. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Thu, Jun 04, 2009 at 07:23:05AM +0200, Ralf Corsepius wrote:
> Steven M. Parrish wrote:
>
>> Many people have mentioned that it is not right to ask the users to
>> file their bug reports upstream. I ask why not?
>
> Let me summarize what I already wrote elsewhere in this thread:
> * Users aren't necessarily developers.
> * Users aren't necessarily interested in getting involved upstream.
> * Users are reporting bugs against your product (your package in
> Fedora), not against upstream's work (somebody else's product).
>
>
> Let me try an analogy: How do you handle defects/malfunctions with your
> car?
>
> You'll visit your car dealer/a garage and report the issue to them.
> You'll expect them to identify the problem and to take appropriate steps
> to solve your issue.
Let me try another analogy: How do you handle health problems?
You'll visit your doctor. You'll expect him to identify the problem and
to take appropriate steps to solve your issue--that may well be just him
sending you to a specialist. Would you expect your doctor to serve as a
proxy between you and the specialist? Or even substitute you for
checkup? I wouldn't.
> You don't expect them to direct you to the car's
> manufacturer or a component manufacturer and to discuss technical
> details you have no knowledge about with them ("Is the stuttering engine
> cause by triac 7 in a component A you haven't heard about before" or by
> the hall sensor in component B you also haven't heard about before).
>
Who spoke about technical details? Have you ever been asked to look into
the source code of some project? I don't think so. An upstream developer
can ask better/more detailed questions than a packager, but that's only
to be expected.
Btw, I'm really interested to hear why answering questions of an
upstream developer through a packager as a proxy is better than
answering the same questions directly...
David
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Kevin Kofler wrote: Steve Grubb wrote: Not if its closed. How would I be notified that the fix is in Fedora? If the bug is severe enough, shouldn't the upstream commit be applied to Fedora's package and the package pushed out for testing? Is all this going to happen if the bug is closed? You're supposed to be the reporter of or CCed on the upstream bug, then you'll get notified of the fix and can reopen our bug asking for a backport of the fix if it's really that important (but keep in mind that Fedora packages often get upgraded to a bugfix release anyway, for example our KDE gets upgraded to a bugfix release about once a month). You are still presuming your users to be interested in developing and working on your package. This simply does not apply - They want to use your package. As maintainers, we will also try to CC ourselves on those upstream bugs to track their status, but utilimately it's the reporter who cares the most about seeing his/her bug fixed. I could not disagree more. People with this kind of attude should lable themselves maintainer and stop packaging packages in Fedora. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Conrad Meyer wrote: On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: Conrad Meyer wrote: On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: Let me try an analogy: How do you handle defects/malfunctions with your car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? Have you ever seen an open source car? The Fedora "car" manufacturer is the "fedora community", assembling it from "upstream" components. Ralf That's the idea, opensource behaves completely different from a car manufacturer. Wrong. It doesn't. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 11:40:42 pm Ralf Corsepius wrote: > Conrad Meyer wrote: > > On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > >> Let me try an analogy: How do you handle defects/malfunctions with your > >> car? > > > > Did a bunch of hobbyists from around the world build your car by > > communicating over the internet? > > Have you ever seen an open source car? > > The Fedora "car" manufacturer is the "fedora community", assembling it > from "upstream" components. > > Ralf That's the idea, opensource behaves completely different from a car manufacturer. -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Conrad Meyer wrote: On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: Let me try an analogy: How do you handle defects/malfunctions with your car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? Have you ever seen an open source car? The Fedora "car" manufacturer is the "fedora community", assembling it from "upstream" components. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wednesday 03 June 2009 10:23:05 pm Ralf Corsepius wrote: > Let me try an analogy: How do you handle defects/malfunctions with your > car? Did a bunch of hobbyists from around the world build your car by communicating over the internet? If so, I think it would be safer to stop driving immediately (EBADMETAPHOR). Regards, -- Conrad Meyer -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steven M. Parrish wrote:
Many people have mentioned that it is not right to ask the users to file their
bug reports upstream. I ask why not?
Let me summarize what I already wrote elsewhere in this thread:
* Users aren't necessarily developers.
* Users aren't necessarily interested in getting involved upstream.
* Users are reporting bugs against your product (your package in
Fedora), not against upstream's work (somebody else's product).
Let me try an analogy: How do you handle defects/malfunctions with your
car?
You'll visit your car dealer/a garage and report the issue to them.
You'll expect them to identify the problem and to take appropriate steps
to solve your issue. You don't expect them to direct you to the car's
manufacturer or a component manufacturer and to discuss technical
details you have no knowledge about with them ("Is the stuttering engine
cause by triac 7 in a component A you haven't heard about before" or by
the hall sensor in component B you also haven't heard about before).
Obviously by reporting the issue to us
they feel it is important and needs to be addressed. The took the time to
open a RH bugzilla account to file the report, so I don't see why they can't
take 60 seconds and open an upstream account as well.
Here, my answer is: They are using Fedora/participating in Fedora and
therefore have RH bugzilla account. They are not participating in these
upstream projects.
Ralf
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 2009-06-03 at 11:25 +0100, David Woodhouse wrote: > On Tue, 2009-06-02 at 16:17 -0400, Steve Grubb wrote: > > > > I don't want to start a long thread, but just to ask a couple questions for > > my > > own clarification. Does a maintainer's responsibilities end with packaging > > bugs? IOW, if there is a problem in the package that is _broken code_ do > > they > > need to do something about it or is it acceptable for them to close the bug > > and say talk to upstream? > > There are _some_ kinds of bug (feature requests, etc.) which it's > reasonable for any decent maintainer to punt upstream. > > There are other kinds of bugs (crashes, security issues -- perhaps even > _anything_ that's a real bug rather than an RFE) which the maintainer > really _ought_ to deal with directly. > > Opinions vary on precisely where the boundary between those classes > should be, but I'm fairly adamant it should be 'RFE vs. bug'. I'm with David on this one. To answer the initial question, this is not explicitly codified anywhere AFAIK, and that's probably because it _can't_ be. It's just not possible to reasonably say that all issues that aren't introduced by actual Fedora packaging should or shouldn't be reported upstream. David's right in identifying the types of bug which it generally does and doesn't make sense to move upstream, and the rest of the thread obviously illustrates that we have different attitudes on the part of different maintainers about it as well. Personally with my maintainer hat on I generally like to keep reports open downstream as it helps me remember stuff, but for a guy with as much work to do as Kevin on a project as big as KDE, I can see how that would not be the case. There's a third element, which is how active upstream is. If you know damn well that upstream's been dead for six years or doesn't care about the branch you're packaging any more, you pretty much have to keep the bugs downstream (I know we try to avoid this situation in Fedora, but it does occur sometimes). I think we just have to be explicit about not being explicit here: it's a judgment call on the part of the maintainer (and the Bugzapper for that component, if there is one, working together with the maintainer). As long as everyone bears in mind that the objective is to get the problem fixed, whichever method is most likely to result in that happening is fine as long as it's consistently applied. As far as being nice to reporters goes, attitude is far more important than process. "report this upstream" may not work great. "Thanks for reporting this issue: as it's a bug in the latest version of the code, it will be fixed most quickly if you report it to the original developers. Their Bugzilla is at http://bugzilla.foobar.com, and you should report the bug against version X of component foobar." will work a lot better. You can also add "Once the issue has been resolved upstream, please re-open this bug to request we include the updated code in Fedora" if appropriate. Yes, it's a lot of text, but you only have to write it once, then stick it in a text file or the Stock Responses page on the Bugzappers wiki section or wherever, and you're good to go for all future upstreaming requests. Basically, I think that if you're worried about trying to keep reporters happy, the way you interact with them matters a lot more than exactly what it is you ask them to do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 2009-06-03 at 22:57 +0200, Kevin Kofler wrote: > Steve Grubb wrote: > > And then should the bug be closed hoping that one day you pull in a > > package that solves the user's problem? > > If the bug is fixed upstream, the Fedora report can be reopened with a > request to backport the fix (but that should only be done if it's important > enough that it cannot wait for the next bugfix update getting pushed > anyway). > > Until then, why do we need to have the bug open in 2 places? There's an obvious answer to this question: we track the importance of issues to Fedora via the Fedora bug tracker, not via upstream bug trackers. There's no way I can mark a bug in the KDE bug tracker as blocking the release of Fedora 12. (longer email on the whole thread coming.) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Either bugzilla.redhat.com works as the center bugzilla for all components in Fedora and those maintaining or are responsible for these components for being in Fedora work as the liaison between the reporter and upstream... Or We redirect reporters directly from the beginning to upstream bugzilla. The former benefits the reporters. The latter benefits ( some ) maintainers?. >From a reporters perspective I say I would rather want to have a single central point to report to that contains all the components the distro includes and thus being more productive in reporting rather then having to surf the waves of the internet and create bugzilla account for each and every component. An conciousness needs to be established on either the former or the latter which will then be followed by all maintainers so the needed work to support/enhance either one can take place. And what's up with the twisted mentality that some maintainers have, which is looking at reporters reports bug as being "complaining" when they are actually trying to help? JBG -- Viking-Ice One of my gods has a hammer your's was nailed to a cross You do the math! -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: > And then should the bug be closed hoping that one day you pull in a > package that solves the user's problem? If the bug is fixed upstream, the Fedora report can be reopened with a request to backport the fix (but that should only be done if it's important enough that it cannot wait for the next bugfix update getting pushed anyway). Until then, why do we need to have the bug open in 2 places? The ball is in upstream's court as long as we're waiting for them to fix the issue, we've done our part as packagers, so as far as we're concerned the issue is closed. As for those cases where the upstream maintainer is the same as the Fedora maintainer, in those cases the maintainer will still have an open bug, the upstream one, he/she doesn't need 2 of them either. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 2009-06-03 at 22:43 +0200, Emmanuel Seyman wrote: > * Mathieu Bridon (bochecha) [03/06/2009 22:41] : > > > > So as a package maintainer, you don't want a bug in a software you > > maintain to be fixed ? > > Not everyone agrees on what is a bug. That's a feature ;) P.Yves -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Bill Nottingham wrote: > Depends on the bug/issue. For security isses, I don't think > CLOSED->UPSTREAM is appropriate, unless it requires a major architecture > of the code base. Similarly, if an app is crashing immediately on startup, > it's not something we necessarily want to just hope upstream will fix. Of course, critical showstoppers need to be tracked within the distro. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Juha Tuomala wrote: > Would to make the report then if she says 'no'? :) We'll just close it as INSUFFICIENT_DATA as with any other ignored needinfo request. To get the bug fixed, they need to report it to the proper place. > It's a fact that knowledge increases when you move steps to upstream. Uh no, they request the exact same information we do. If you can't provide enough information for upstream, your bug report is just as incomplete and useless for us as it is for them. > If a packager don't have time to do that stuff, he would probably > need a co-maintainer(s) or less packages. So do you volunteer to be the bug forwarding monkey for KDE SIG? Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: > For the record, I agree with this sentiment. If there's a bug in my > packages, I want to fix it and not cause the reporter to have to get > upstream bz accounts or join upstream mail lists just because they > reported a problem. I will interact with the reporter until I see the > problem myself. And then I can fix it or show upstream the problem. Maybe you package only stuff you're intimately familiar with from top to bottom and you get only very few bug reports. But in KDE, we get dozens of bug reports and it's a huge codebase. While most of the bugs are probably such that I could fix any of them on its own, there's no way I can fix all of them by myself (and even considering all the KDE SIG folks, we still don't have enough time to fix everything ourselves), nor would my fix necessarily be good enough to be accepted upstream (sometimes a good fix needs significant code changes which only the upstream maintainer of the affected code base is really qualified to do, and that's usually not a Fedora developer). So I think you're getting a better deal by us insisting on having the bugs handled upstream. I guess other codebases where bugs are expected to be filed upstream (e.g. Evolution, which was also brought up in this thread) are similar. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
* Mathieu Bridon (bochecha) [03/06/2009 22:41] : > > So as a package maintainer, you don't want a bug in a software you > maintain to be fixed ? Not everyone agrees on what is a bug. Emmanuel -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius wrote: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to > upstream. Wrt. evolution, I was an ordinary user and am not interested > in getting further involved. Signing up for an upstream Bugzilla account takes at most 5 minutes, then it's just as easy to file bugs there than at bugzilla.redhat.com. Bugs need to be fixed upstream (so everyone benefits, not just Fedora users), by upstream developers (not packagers, and no, not all packagers are developers, and even those who are generally aren't experts for the entire codebase they're packaging, so upstream developers are the people most qualified for fixing most bugs), so they should also be filed upstream. > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. That's because that's our policy, and rightfully so. > Now combine this with the "report bugs" phrases certain people tend to > reiterate? ... Experiences, such as the one I encountered with the > evolution maintainer, are the cause why at least some people sense a > foul taste when listening to them. Then let's say: Report bugs, to the right place of course (usually upstream)! Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Ralf Corsepius wrote: > I consider maintainers redirecting arbitrary reporters to upstreams to > be rude and hostile, because they are presuming the reporter to be > * interested in tracking down bugs If you don't care about your bug, why are you reporting it in the first place? Only very few people report bugs just to be nice (and those will be happy to do anything to help us), most people report bugs because they want them fixed. > * interested in getting involved into upstreams > * technically able to do so. If they're able to report the bug to us, they're also able to report it to upstream, the information they need to provide is basically the same (e.g. for KDE, they just need to pick "Fedora packages" from a dropdown to let upstream know what distro they're using, other than that, the requested information is exactly the same AFAICT). > This occasionally applies to developers - To normal users it usally > doesn't apply, they want "to have their issue fixed". Then they need to do what it takes to get their issue fixed. Talking to upstream, helping with tracking the bug down etc. are all part of that. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
>> I agree. Demanding them to take any responsibility >> on that report, even testing it again makes them just >> think twice next time to report anything. > [snip] >> Exactly. If the reporter wants to take part to that >> communication, good. But that should not expected. >> >> More reports is better than more active reporters, those >> latter ones wont disapper anywhere anyway. > > The reporter is the one who wants the bug fixed, it's them asking us to do > something, they need to do their part. If you aren't willing to do anything > to help us fix your bug, you'll just have to live with it forever. So as a package maintainer, you don't want a bug in a software you maintain to be fixed ? -- Mathieu Bridon (bochecha) -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Jaroslav Reznik wrote: > Most bugs are filled by quite technically skilled users. For average users > it doesn't depend if it is RH bugzilla or upstream's bugzilla - it's too > complicated for them. I know - it's another story... For these people > forums are much more better. Uh, forums are a horrible place for bug reports. For one because developers usually won't read them. It's no use complaining about bugs in front of an audience of other newbies, the bugs must be reported to the people who actually care, and that's what bug trackers are for. Another issue is that forums are freeform, they don't have any sort of form which tells users what information is required. I hate lazy idiots whining about bugs in forums when they never bothered reporting them to the developers. And I don't think we can make bug reports any easier, the point is that the information is required, those "complicated" forms are there to request the information we need. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Juha Tuomala wrote: > I agree. Demanding them to take any responsibility > on that report, even testing it again makes them just > think twice next time to report anything. [snip] > Exactly. If the reporter wants to take part to that > communication, good. But that should not expected. > > More reports is better than more active reporters, those > latter ones wont disapper anywhere anyway. The reporter is the one who wants the bug fixed, it's them asking us to do something, they need to do their part. If you aren't willing to do anything to help us fix your bug, you'll just have to live with it forever. Reports aren't of much use if the reporter doesn't want to provide us with the necessary details, doesn't even bother checking whether the bug isn't already fixed when asked (If we can't reproduce the issue, how else are we to know whether it's fixed or whether we just don't have enough information on how to reproduce it?) and/or refuses to report the issue to the people who're actually able to fix it. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steve Grubb wrote: > Not if its closed. How would I be notified that the fix is in Fedora? If > the bug is severe enough, shouldn't the upstream commit be applied to > Fedora's package and the package pushed out for testing? Is all this going > to happen if the bug is closed? You're supposed to be the reporter of or CCed on the upstream bug, then you'll get notified of the fix and can reopen our bug asking for a backport of the fix if it's really that important (but keep in mind that Fedora packages often get upgraded to a bugfix release anyway, for example our KDE gets upgraded to a bugfix release about once a month). As maintainers, we will also try to CC ourselves on those upstream bugs to track their status, but utilimately it's the reporter who cares the most about seeing his/her bug fixed. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Matej Cepl (mc...@redhat.com) said: > > Depends on the bug/issue. For security isses, I don't think > > CLOSED->UPSTREAM is appropriate, unless it requires a major architecture > > of the code base. Similarly, if an app is crashing immediately on > > startup, it's not something we necessarily want to just hope upstream > > will fix. > > Depends also on maintainer ... we don't require packagers to be > programmers and proficient in language their package is written. Which is a bit of a shame, as we could obviously do a better job if they were. Then again, one of my packages has large chunks written in scheme. Certainly, resources are available to packagers that need them, though; if they've got crasher issues they can't solve, asking on fedora-devel-list can never hurt. Bill -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Steven M. Parrish wrote: > I can only speak for myself and not the other triagers. I work solely on > KDE issues because in addition to triage I also maintain several KDE > packages and work closely with the other maintainers. The upstream method > we use was discussed and agreed to as the best solution to make sure the > issues get to where they need to be. And I'll add that we KDE maintainers will reopen the bug if it gets closed UPSTREAM, but we feel it needs to be fixed within Fedora. It's not like mistakes can't be easily undone. Kevin Kofler -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
> On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: > > This is from the official Bugzappers page > > https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstream > >in > > So, this raises the question about bugzappers. Should they be making the > determination for maintainers that the reporter should have taken the issue > upstream? Do bug zappers take into consideration the severity of the bug > before pushing someone upstream? > > > The bug is not a packaging bug, the package maintainer has no plans to > > work on this in the near future, and there is an upstream bug tracking > > system other than the Red Hat Bugzilla. > > Is there communication between maintainer and bugzapper before doing this? I can only speak for myself and not the other triagers. I work solely on KDE issues because in addition to triage I also maintain several KDE packages and work closely with the other maintainers. The upstream method we use was discussed and agreed to as the best solution to make sure the issues get to where they need to be. I would suggest that any triager get to know the packages they triage and the maintainers and together agree to how the wish to handle this issue. > > > Maintainers should be free to either fix it locally (time permitting) and > > upstream the patch or request that the bug be filed at the upstream > > projects tracker for the upstream developers to resolve it. > > > > If it is sent upstream the bug is closed as UPSTREAM and our local report > > is cross-referenced to the upstream one. That way the maintainer and all > > interested parties can follow its progress. > > Not if its closed. How would I be notified that the fix is in Fedora? If > the bug is severe enough, shouldn't the upstream commit be applied to > Fedora's package and the package pushed out for testing? Is all this going > to happen if the bug is closed? > This is a good point. That is why we want the report filed upstream by the reporter. They are then cc'd to the upstream report and can follow it as it progresses. In the future I will work to make sure that the local BZ report is kept updated with the status in Fedora. Many people have mentioned that it is not right to ask the users to file their bug reports upstream. I ask why not? Obviously by reporting the issue to us they feel it is important and needs to be addressed. The took the time to open a RH bugzilla account to file the report, so I don't see why they can't take 60 seconds and open an upstream account as well. (Open-ID would solve that issue.) If the issue is important to them they will do it. If the reporter does not file it upstream and we feel we have enough information to go on, I will file it upstream to make sure the issue is addressed. This is an issue that needs to be addressed by the BugZappers group and a proposal taken before FESCO so an official policy can be agreed upon. I'll place this on the agenda for the next meeting. SMP -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, Jun 3, 2009 at 06:46, Ralf Corsepius wrote: > Michael Schwendt wrote: > >> On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: >> >> I consider users (esp. bug reporters) not to be "the dumb pigs eating the >>> hog wash they get for free", or "clueless comsumer masses" aborbing anything >>> they don't pay for with money, but them to be the foundation of your work >>> and them to be valuable business partners, paying in immaterial payment >>> (e.g. feedback, such as bug reports). >>> >> >> That's an idealistic [over-simplified] point of view which I don't want to >> agree with. >> > Well, whether it's idealistic or not is irrelevant. It's one of the > foundations of open source. > > Or less abstract: > I stopped reporting bugs against Fedora's evolution, because its @RH > maintainer preferred to close bugs and tried to push me around to upstream. > Wrt. evolution, I was an ordinary user and am not interested in getting > further involved. > > As simple as it is: I felt sufficiently pissed of by this guy to leave him > and his upstream alone, ... so be it, he wanted it this way. > > There are other packages and packagers (noteworthy many of the @RH) who > exhibit the same "push reporters around" behavior. > > So is still anybody wondering why Fedora is permanently lacking people? > This is one cause. > > Now combine this with the "report bugs" phrases certain people tend to > reiterate? ... Experiences, such as the one I encountered with the evolution > maintainer, are the cause why at least some people sense a foul taste when > listening to them. > As a bug reported I've come to peace with the concept that maintainers and upstream have personalities too. Sometimes people are happy to see bug reports, sometimes they ignore them and sometimes they seem to go out of their way to be unhelpful. For the same reason it can be difficult to report bugs since different packages can have wide variations in the amount of information they want you to collect, and strange incantations and commands you've never seen before. (Often of the "gee I never knew that was even possible" variety). The ones that get to me are 1) Bugs return over and over again with each new latest and greatest version or rewrite of previously working code. A few years ago it was USB devices that would mount one day on the desktop, then not mount, then mount, etc. Today it might be screen display powers off (or doesn't), battery level is correct (or reports battery-critical), sound works (or doesn't), compiz works (or doesn't), boot with graphic boot (or nomodeset yet again). 2) Bugs that get no attention, not even an acknowledgement. 3) Bugs where the maintainer (or triager) seems to go out of their way to be completely unhelpful. I think it is easy to forget how difficult and time-consuming it can be to produce a really good bug report. I'd say that 9 out of 10 bugs that I report leave me feeling that the not much was accomplished. It is that tenth bug report, the one where there is a reasonable interaction, where a problem gets resolved (and doesn't seem to reappear) that keeps me doing them. darrell -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, Jun 03, 2009 at 10:01:58AM -0400, Steve Grubb wrote: > Not if its closed. How would I be notified that the fix is in Fedora? If the > bug > is severe enough, shouldn't the upstream commit be applied to Fedora's > package > and the package pushed out for testing? Is all this going to happen if the > bug > is closed? I might be saying something most people understand or accept, but it strikes me the flow should be: 1. User reports bug against Fedora component. 2. Maintainer reviews the BZ. 2a. If it's packaging related, then the bug's handled with an update. 3. A bug is opened upstream, and the BZ somehow references that ticket. 4a. The maintainer can also work on a fix and submit that patch upstream. 4b. The patch can be applied in Fedora in the interim to fix the problem. 5. When upstream releases a fixed version, then a new release is made in Fedora, and the patch discarded from CVS. The point being, the Fedora user shouldn't have to go outside of Fedora to report their bugs. IMO the package maintainer is the person who should be liaison between the user and upstream and should be actively aware and involved in those bug reports and fixes. In steps 2-5 the maintainer's always a part of what's going on upstream. They don't have to be actively involved in solving the bug, but they do need to be aware of reported bugs by Fedora users, as well as bugs reported by other distros so they can proactively alert Fedora users. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Virtual Machine Management - http://www.ovirt.org/ Is fearr Gaeilge bhriste ná Béarla cliste. pgptj3h5l7ipy.pgp Description: PGP signature -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 06:17:02 pm Steven M. Parrish wrote: > This is from the official Bugzappers page > https://fedoraproject.org/wiki/BugZappers/StockBugzillaResponses#Upstreamin So, this raises the question about bugzappers. Should they be making the determination for maintainers that the reporter should have taken the issue upstream? Do bug zappers take into consideration the severity of the bug before pushing someone upstream? > The bug is not a packaging bug, the package maintainer has no plans to work > on this in the near future, and there is an upstream bug tracking system > other than the Red Hat Bugzilla. Is there communication between maintainer and bugzapper before doing this? > Maintainers should be free to either fix it locally (time permitting) and > upstream the patch or request that the bug be filed at the upstream > projects tracker for the upstream developers to resolve it. > > If it is sent upstream the bug is closed as UPSTREAM and our local report > is cross-referenced to the upstream one. That way the maintainer and all > interested parties can follow its progress. Not if its closed. How would I be notified that the fix is in Fedora? If the bug is severe enough, shouldn't the upstream commit be applied to Fedora's package and the package pushed out for testing? Is all this going to happen if the bug is closed? -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
Michael Schwendt wrote: On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: I consider users (esp. bug reporters) not to be "the dumb pigs eating the hog wash they get for free", or "clueless comsumer masses" aborbing anything they don't pay for with money, but them to be the foundation of your work and them to be valuable business partners, paying in immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. Well, whether it's idealistic or not is irrelevant. It's one of the foundations of open source. Or less abstract: I stopped reporting bugs against Fedora's evolution, because its @RH maintainer preferred to close bugs and tried to push me around to upstream. Wrt. evolution, I was an ordinary user and am not interested in getting further involved. As simple as it is: I felt sufficiently pissed of by this guy to leave him and his upstream alone, ... so be it, he wanted it this way. There are other packages and packagers (noteworthy many of the @RH) who exhibit the same "push reporters around" behavior. So is still anybody wondering why Fedora is permanently lacking people? This is one cause. Now combine this with the "report bugs" phrases certain people tend to reiterate? ... Experiences, such as the one I encountered with the evolution maintainer, are the cause why at least some people sense a foul taste when listening to them. Ralf -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Wed, 03 Jun 2009 14:06:45 +0200, Ralf wrote: > I consider users (esp. bug reporters) not to be "the dumb pigs eating > the hog wash they get for free", or "clueless comsumer masses" aborbing > anything they don't pay for with money, but them to be the foundation of > your work and them to be valuable business partners, paying in > immaterial payment (e.g. feedback, such as bug reports). That's an idealistic [over-simplified] point of view which I don't want to agree with. There is no clear relationship, such as a seller and a purchaser (and the "customer is king" guideline doesn't apply), since the person who produces the packages may be the one to _give_ more than he _gets_ in return by the users. Or vice versa. All that's clear to me is that the packager fills the role of a "provider", providing packaging services, and certain feedback from some package users may help with improving the quality of the provided product. In turn the provider ought to have interest in such an improvement and in boosting the relationship with the package users. Preferably, users with strong interest in a particular Fedora package sign up at the Fedora Account System, so they can subscribe to a package's watchbugzilla and watchcommit channels. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 11:09:49 pm Ralf Corsepius wrote: > Kevin Kofler wrote: > > Steve Grubb wrote: > >> I don't want to start a long thread, but just to ask a couple questions > >> for my own clarification. Does a maintainer's responsibilities end with > >> packaging bugs? IOW, if there is a problem in the package that is > >> _broken code_ do they need to do something about it or is it acceptable > >> for them to close the bug and say talk to upstream? > > > > It's the reporter's job to report the bug upstream when asked to do so. > > I disagree. Reporters are "users" - "customers" if you like to. > > You can't expect them to do anything, nor demand them to do anything, > nor force them to do anything. > > That said, I consider it to be a Fedora package's maintainer's job and > duty to act as moderator/arbiter/coordinator to initiate appropriate > communication/interaction between all different parties (reporter, > packager, upstreams) "when necessary/if required". For the record, I agree with this sentiment. If there's a bug in my packages, I want to fix it and not cause the reporter to have to get upstream bz accounts or join upstream mail lists just because they reported a problem. I will interact with the reporter until I see the problem myself. And then I can fix it or show upstream the problem. Thanks everybody for the opinions. I just wanted to raise awareness on this topic. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Maintainer Responsibilities
On Tuesday 02 June 2009 07:34:17 pm Kevin Kofler wrote: > Steve Grubb wrote: > > I don't want to start a long thread, but just to ask a couple questions > > for my own clarification. Does a maintainer's responsibilities end with > > packaging bugs? IOW, if there is a problem in the package that is _broken > > code_ do they need to do something about it or is it acceptable for them > > to close the bug and say talk to upstream? > > It's the reporter's job to report the bug upstream when asked to do so. And then should the bug be closed hoping that one day you pull in a package that solves the user's problem? > Fixing bugs often requires two-way communication, so it's important for > upstream to have a real reporter to talk to, I don't see why it should be > the maintainer's job to play the relaying monkey. Its real simple. In reporting the bug, people are asked how to reproduce the bug. If its reproducible by the maintainer, the user is no longer required to solve the problem and all you need to do is ask them to do a retest. If the bug is not reproducible, then things do get a little trickier. I would still take the bug report to upstream and see if it rings any bells, but I would not close the bug. -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
