I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream.
I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions?
Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions?
It is (imo) generally the package maintainer's discretion. Obviously, if it's something they are interested in or is important, it likely is in their best interest to help move feature requests upstream. If not, well, then that burden is probably best left to you (or some other interested party).
-- rex
On 06/17/2013 12:40 PM, Rex Dieter wrote:
Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers, so bugzilla.redhat.com as a single point of contact is very helpful to me. Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions?
It is (imo) generally the package maintainer's discretion. Obviously, if it's something they are interested in or is important, it likely is in their best interest to help move feature requests upstream. If not, well, then that burden is probably best left to you (or some other interested party)
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
JBG
* "Jóhann B. Guðmundsson" [17/06/2013 12:49] :
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
Even when upstream has requested that their bug tracker be the only one used?
Emmanuel
Emmanuel Seyman píše v Po 17. 06. 2013 v 15:39 +0200:
- "Jóhann B. Guðmundsson" [17/06/2013 12:49] :
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
Even when upstream has requested that their bug tracker be the only one used?
Well, I think Red Hat Bugzilla should always be the default option. We really can't require users to report in other bugzillas. Of course, if someone is more experienced, more into testing, and want to help developers/packagers, then they can do whatever works better for them. For example, I know that our maintainers of GNOME appreciate bugs reported directly to GNOME bugzilla because there is a little or zero delta between upstream and Fedora. So if it's a bug that doesn't influence Fedora release or something, I report it directly to GNOME bugzilla. If it's something I found during focused testing of Fedora or if it might be a release blocker, I always report it to the Red Hat bugzilla, too. But I do believe that the general rule should be to report bugs in RH bugzilla. And that's what we should advertise among users and what maintainers should be ready for.
Jiri
On 06/17/2013 01:39 PM, Emmanuel Seyman wrote:
- "Jóhann B. Guðmundsson" [17/06/2013 12:49] :
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
Even when upstream has requested that their bug tracker be the only one used?
Yes it's the distribution maintainers responsibility to forward that request upstream if that is the case followed by notifying the reporter they have done so with a link to the upstream report in the relevant bug report in bugzilla.redhat.com.
We do not forward reporters to upstream bugzilla's so if packagers/maintainers refuse to use our own bug tracker ( Like the Red Hat's Gnome developers do ) we spread the word amongst report not to file *any* report against Gnome because it wont be look at anyway.
We have ca 15000 components in distribution so we dont waist time and energy having reporters file reports on components in the distribution which wont be looked at anyway regardless if you are only using the upstream tracker or simply dont respond to bug reports et all.
JBG
On 06/17/2013 02:52 PM, Colin Walters wrote:
On Mon, 2013-06-17 at 14:34 +0000, "Jóhann B. Guðmundsson" wrote:
refuse to use our own bug tracker ( Like the Red Hat's Gnome developers do )
Stop saying that, it's not true.
What's not true that Red Hat Gnome developers having been trying to push Fedora reporters upstream for years and that their attitude is not well known in the QA community?
Yeah sure maybe not all of you ( and reporters quickly learn who respond to bug reports and who dont ) but here's this development cycle remarks of it...
[1] From Martin...
"
Please developers have a look at the following bugs (if you didn't yet) as one of motivations for users to attend Test Days is that found bugs will be fixed soon via updates after installation.
Note, after almost 3 months there are lot of NEW bugs in Red Hat Bugzilla in contrast to many RESOLVED in Gnome Bugzilla. If you need any help with triaging bugs and testing bugfixes, feel free to contact me."
And Adam...
"Desktop team...I know you have this thing about not reading RH bugs...but it really does mean you miss out on what looks like some valuable information. Can't it be re-considered? Couldn't you at least task someone to take a sweep through the Test Day bugs?"
Maybe you should accept the truth that is instead of accusing others of lying here.
JBG
1. https://lists.fedoraproject.org/pipermail/desktop/2013-June/008096.html
On Mon, 2013-06-17 at 15:16 +0000, "Jóhann B. Guðmundsson" wrote:
Maybe you should accept the truth that is instead of accusing others of lying here.
I was not accusing you of lying, merely of perpetuating what I consider an inaccurate characterization of reality.
Could the team do more? Of course.
Do some Red Hat GNOME maintaners almost completely ignore RH Bugzilla? Probably.
But there are others who do respond to bugs? Yes, even a brief investigation with a list of email addresses and the Bugzilla search page would show that.
Could we do with less hyperbole? Definitely.
On 06/17/2013 03:47 PM, Colin Walters wrote:
Maybe you should accept the truth that is instead of accusing others of lying here.
I was not accusing you of lying, merely of perpetuating what I consider an inaccurate characterization of reality.
Could the team do more? Of course.
Do some Red Hat GNOME maintaners almost completely ignore RH Bugzilla? Probably.
But there are others who do respond to bugs? Yes, even a brief investigation with a list of email addresses and the Bugzilla search page would show that.
Could we do with less hyperbole? Definitely.
We as a community in whole cannot deal with issues like these ( and others ) until we have the means to properly health ( reports vs resolve + the time it took ) monitor a component in the distribution.
Once we have that the QA community could do the triaging work to reduce the reports while it was being advertised in the community if some other maintainers could step up and assist if the component maintainership was in "bad shape"
We probably could implement some kind of time,share process at that time as well to prevent maintainers to overload themselves which has a tendency to lead to maintainers either burning out or simply ignore all work and us loosing reporters and what not.
JBG
On Mon, 17 Jun 2013 15:39:30 +0200, Emmanuel Seyman wrote:
- "Jóhann B. Guðmundsson" [17/06/2013 12:49] :
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
Even when upstream has requested that their bug tracker be the only one used?
That's why one either forwards bugs or asks the [Fedora] user to open an upstream ticket for better communication about the problem. One may link information present in the Fedora bz. But if the original reporter refuses to join the upstream ticket for answering questions or providing further details, that can easily become tedious or even a dead end.
* Michael Schwendt [17/06/2013 17:20] :
But if the original reporterrefuses to join the upstream ticket for answering questions or providing further details, that can easily become tedious or even a dead end.
In the case I'm facing now, the problem is trying to submit patches that have been submitted in brc without taking credit for the real reporter's work and/or making upstream's life harder by having them work in two different bug trackers.
Emmanuel
On Mon, Jun 17, 2013 at 7:49 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
I think that this is a fantasy that is not going to happen unless every package maintainer's primary employment is maintaining said packages (not necessarily employed by Red Hat).
I'm sure that I'm representative of many packagers out there - I'm not paid to maintain packages in Fedora, in fact any open source I get to use at work is because I've been successful at asking for forgiveness instead of permission.
I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community?
It drives me absolutely bonkers when people open bugs on the RedHat bugzilla and then insist that I do the work of coordinating with upstream because they are "too busy" or they "don't want to create a bunch of accounts in the upstream bugtracker". I mean it drives me absolutely bonkers to the point I have trouble remaining polite. In fact I've completely ignored a bug in RedHat's bugzilla for months because of the reporter's attitude that their time was so much more valuable than mine that I can't read the bug, much less post a response without resorting to nasty four-letter words.
The work that I do in maintaining my packages is my contribution back to the community that has given me so much already. For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied. But to expect me to take a significant amount of time to work with upstream to find the bug and patch it is unrealistic because:
1) There's a 99.999% chance that I don't have the resources (either hardware or software) to reproduce the bug.
2) There's a 100% chance that I don't have the time between work and family obligations.
3) Even though I'm an excellent programmer, well versed in C and Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug.
4) Most software is complex enough that even configuration problems are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it.
All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to.
-- Jeff Ollie
On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
On Mon, Jun 17, 2013 at 7:49 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
It's package maintainers responsibility to act as the liason between upstream and Fedora thus reporters only need to report in our Bugzilla instance.
I think that this is a fantasy that is not going to happen unless every package maintainer's primary employment is maintaining said packages (not necessarily employed by Red Hat).
I'm sure that I'm representative of many packagers out there - I'm not paid to maintain packages in Fedora, in fact any open source I get to use at work is because I've been successful at asking for forgiveness instead of permission.
I'm not getting paid to work on Fedora and consider myself lucky for the very few thanks I get for my work.
I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community?
Because if you cannot properly maintain the component in the distribution the community is better of without it.
It drives me absolutely bonkers when people open bugs on the RedHat bugzilla and then insist that I do the work of coordinating with upstream because they are "too busy" or they "don't want to create a bunch of accounts in the upstream bugtracker". I mean it drives me absolutely bonkers to the point I have trouble remaining polite. In fact I've completely ignored a bug in RedHat's bugzilla for months because of the reporter's attitude that their time was so much more valuable than mine that I can't read the bug, much less post a response without resorting to nasty four-letter words.
The work that I do in maintaining my packages is my contribution back to the community that has given me so much already. For most bug reports, I'm willing to take a little bit of time and see if there's a new release I've missed or if the bug has been already identified upstream and there's a patch that can be applied. But to expect me to take a significant amount of time to work with upstream to find the bug and patch it is unrealistic because:
- There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
Then you should not be maintaining that component
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
- Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug.
If you aren't familiar with the component you are packaging and maintaining why are you doing it et all?
- Most software is complex enough that even configuration problems
are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it.
All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to.
It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of.
JBG
On Mon, 2013-06-17 at 15:55 +0000, "Jóhann B. Guðmundsson" wrote: [...]
In a community of volunteers there are two ways to treat someone's work when you are no satisfied with it: a) tell him/her, his/her work matters and push him/her to improve where you think it should be improved (eventually by getting your hands dirty to show the way). b) tell him/her that his/her work sucks but he/she is not following what you believe should be the way.
I do not believe you grow a nice and healthy community by doing the second and your last email was, imho, really oriented to the option b. Please be careful with the wording you use, that's also what's implied by "be nice to each other".
Pierre
On Mon, Jun 17, 2013 at 10:55 AM, "Jóhann B. Guðmundsson" < johannbg@gmail.com> wrote:
On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
- Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al. I probably don't have the
familiarity with the codebase to even know where to start looking for a bug.
If you aren't familiar with the component you are packaging and maintaining why are you doing it et all?
I think that's a bit unfair. While it's certainly helpful, it's not a requirement, to be a programmer in order to be a packager. I know very little C, some python, but I've learned quite a bit about building and packaging over the last few years.
You often end up with packages that you need for various reasons, but that doesn't mean you're intimately familiar with all of them.
Richard
On Mon, 17 Jun 2013 15:55:57 +0000, Jóhann B. Guðmundsson wrote:
Because if you cannot properly maintain the component in the distribution the community is better of without it.
Such rude comments don't meet the "be excellent to eachother" guidelines anymore, I'm afraid. Stop here, please.
[Jeffrey Ollie]
- There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
Then you should not be maintaining that component
Hmmm, I find what Jeffrey has written above is phrased in an unfortunate way and may be misunderstood. But actually, for some types of software there is a higher rate of bugs which one cannot reproduce (or one isn't told how to reproduce the issue - e.g. ABRT makes it easy for users to dump such reports into bugzilla), and the backtrace isn't sufficient either to draw conclusions, and the reporter doesn't mention that other programs crash in the same way due to hardware instabilities. Enough upstreams ignore forwarded bug reports which lack details and where _they_ feel that they won't be able to reproduce the issue and where _they_ don't see a connection to mistakes in the code. In other cases they would ask with NEEDINFO queries, but downstream (in Fedora bz), the reporter doesn't respond. Spending time on such tickets is a waste of time.
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
You forget upstream's part. The software (and the packages) may work well enough for enough users to justify offering them in the package collection. The next release may fix lurking bugs, because one single user has shown enough interest and effort in helping with getting a bug fixed. The "user" may be the Fedora packager, but it's better if more users support the software (and packages) like that.
OK, so this post is going to be rather long and rambling, and hopefully respectful, but I'm passionate about this subject (and Fedora). The tl;dr summary is that there shouldn't be a single standard for what we expect of packagers, especially in the context of what to expect when bugs are filed against their packages on Red Hat's bugzilla. My view is that expectations are going to depend on the criticality of the package to Fedora (kernel, installer, default desktop stack) and the packager (are they being paid to maintain the package in Fedora or are they volunteering their time).
Also, where some of us seem to be at odds is the definition of "proper maintenance" for packages. My definition:
1) Ensure that packages meet all of the packaging guidelines. 2) Fix packaging related bugs in a timely manner. 3) Incorporate new upstream releases, in accordance with packaging guidelines (e.g. packages shouldn't be updated to a new major version in a released version of Fedora). 4) Incorporate patches that fix security issues or critical bugs.
In my view these expectations imply that a packager has some involvement with upstream. I think that the level of involvement is going to depend on the packager and the package. I don't think that a hard and fast rule can be developed to cover every case without becoming ridiculously long and complex. Other than generally encouraging packagers to become involved with upstream development it should be left up to the conscience of the packager.
In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves).
OK, so with that out of a way, I'm hopefully going to respectfully (if wordily) respond to Jóhann's comments.
On Mon, Jun 17, 2013 at 10:55 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community?
Because if you cannot properly maintain the component in the distribution the community is better of without it.
- There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
Then you should not be maintaining that component
In some cases you may be right. But in most cases I was the only person to step up and package a particular piece of software. Also, in most cases I'm willing to step aside as the owner of a package if someone wants to take over the responsibility. In every case I've been willing to take on co-maintainers to help out with the packaging duties.
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
Again, our key disagreement here is on the definition of "proper maintenance". I have more than enough time to keep up with new versions as they are released (most of the time) or to pull a patch out of the upstream's version control and add it to the package. But even if I had the hardware I don't have the kind of time it takes to set up test environments to reproduce a bug, and then dig into the code and find the bug, develop a fix and then test it.
- Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug.
If you aren't familiar with the component you are packaging and maintaining why are you doing it et all?
Well, let's take Asterisk. First off, there are a lot of components that require specific (and expensive) hardware like ISDN & POTS adapters. And if I had the Asterisk-specific hardware I'd need ISDN or POTS lines to connect to which would mean sending lots of my money to the local telco or spending lots of money on other telephony hardware to set up a lab environment. Then you've got to worry about country-specific setups. ISDN and POTS lines work differently depending on what country you're in, and I've only had minimal experience with such lines in the US and none at all in other countries.
Asterisk provides support many VoIP protocols, each with their own quirks. A number of them only talk to proprietary hardware (which I don't own). Even if you're using SIP, it's one of those protocols whose specification is fuzzy enough that every implementation that you come across does things a little differently especially when users start reconfiguring things for their particular needs.
Then there are all of the modules that Asterisk includes for providing functionality like voice mail or conference calling. Some are fairly simple, but many have complex configurations and can interact with other parts of the system in non-trivial ways.
Oh, and did I mention that Asterisk has *two* domain-specific programming languages built into it (they are probably Turing-complete too). And it embeds Lua, has an embedded HTTP server for exposing REST APIs, as well as subsystems that expose other APIs.
So outside of Digium (the company that controls upstream development), there's practically *no one* that has the resources or knowledge to provide support at the level that you seem to be expecting, especially for complex or subtle cases. And even inside Digium there isn't a single individual that can meet your standards, which is why Digium employs quite a few people to handle support and development.
Digium itself hasn't seen fit to get involved with Fedora, at least not in an official way. There are at least a couple ex-Digium employees that are involved with Fedora, but they have their own jobs/lives/interests. One has stepped up to be a co-maintainer but I've been quick enough with updates that he hasn't had much to do yet. I'm appreciative nonetheless.
If you look at the history of the Asterisk package, I spent over a year getting the package through the review process, including packaging related dependencies and I've spent the past 7+ years maintaining it. At times I've fallen behind a bit in the updates but I don't think that you can seriously question my long-term commitment to maintenance of the package.
In the past I've written patches and even whole modules for Asterisk and had them accepted upstream, although with the pace of Asterisk development and the amount of time that's elapsed there's probably not much evidence of that left in current versions. Asterisk has had a lot of it's core code restructured in that time, and even more so in the next major version that's in development so much of what I knew about the internals is no longer relevant.
I follow the Asterisk development and security lists (I don't look at every code review that's posted, but I do look at a few) to see what's coming in the next release or to get notified of security issues. In a few cases I've packaged up new security fix releases and gotten them into -testing even before the Red Hat/Fedora security team can create the bugs in bugzilla. I've also met a number of Digium employees IRL...
I guess that I could change the package to include only the parts of Asterisk that I'm familiar with, but that seems like a rather anti-social thing to do.
So by my standards, I'm the best person *right now* to maintain the Asterisk package. In the future someone else may show up that's willing to do end-user support or upstream development in addition to package maintenance. A number of people find having Asterisk packaged in Fedora useful (no idea how many) but if there's more than just me I think it's worth having the package in Fedora.
- Most software is complex enough that even configuration problems
are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it.
All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to.
It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of.
Playing "man in the middle" is inefficient. Unless it's an issue with packaging or Fedora-specific patches the reporter should work with the upstream developers to identify and fix the issue. Once a fix is available then it's the package maintainers responsibility to pull that fix into Fedora (either as a patch or a new release). That way the upstream developers can work directly with the user that is having the problem and ultimately every distribution benefits from the bug fix. The package maintainer should certainly be kept in the loop so that they know an update/patch is imminent.
I personally think that the level of involvement/contact that a package maintainer needs to have with upstream depends on the component. For core components like the kernel or the Gnome stack expecting there to be a package (or packagers) that are intimately involved upstream is reasonable. It's also reasonable to expect that you're not going to find those people unless they're being paid for the work because of the large time commitment needed (and sometime financial commitment, e.g. for hardware to test on or to fund travel to a conference). It's nice when someone dedicates a large chunk of their free time to packaging software and working with upstream but I don't think that you can expect it.
For complex non-core packages (like Asterisk), I think it's reasonable to expect a packager to keep an eye on upstream development so that they're aware of what's going on (pending new releases, especially new releases that break compatibility or provide major new features, security issues, etc.)
For everything else, it's less clear cut. Guidelines can be given but every case is going to be different and we'll need to work with packagers to help them do their best.
-- Jeff Ollie
On Mon, Jun 17, 2013 at 1:57 PM, Jeffrey Ollie jeff@ocjtech.us wrote:
In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves).
I agree. For some of the packages I maintain, I am able to do some bug fixing myself, and forward the patches upstream. For other packages, I have done the packaging because I use the software, but I am not at all knowledgeable about the innards, and get lost quickly trying to fix any bugs. I think it's reasonable in those cases to advise that the user report the bugs upstream.
If there was consensus that handling it that way was bad, and that the package maintainer had to accept more responsibility for bug fixing, then I'd be happy to hand over the package maintenance duties to another Fedora package maintainer that was willing to do that.
Well, let's take Asterisk. First off, there are a lot of components
That's a good example, but I think there are a lot of packages far simpler than that which are still too complicated to necessarily expect the Fedora packager to do all of the software maintenance.
Eric
On 06/17/2013 07:57 PM, Jeffrey Ollie wrote:
OK, so this post is going to be rather long and rambling, and hopefully respectful, but I'm passionate about this subject (and Fedora).
As am I.
The tl;dr summary is that there shouldn't be a single standard for what we expect of packagers, especially in the context of what to expect when bugs are filed against their packages on Red Hat's bugzilla.
I disagree and from my pov it should be.
But I agree that RHEL customers somehow expect the same customer treatment RHEL provides them for bug filed agains Fedora.
I filed a ticket with the board where I asked them to come up with and write a wiki page which clarified that for them ( RHEL customers ) but that ticket has been laying in that tracker for a about 2 years now without any kind of movement. ( takes them maybe half an hour for them to come up with and wikify it )
My view is that expectations are going to depend on the criticality of the package to Fedora (kernel, installer, default desktop stack) and the packager (are they being paid to maintain the package in Fedora or are they volunteering their time).
It should not matter if you get paid or not for working on Fedora because in the end of the day this boils down to time and by that I mean the time you as an employee get paid to spend on maintaining your package in Fedora or the free time you have to dedicate to maintain your package Fedora however the time required to maintain the package properly in the distribution still remains the same.
We should be able to provide a minimum time it takes to just package and provided minimum maintenance on a component along with calculate the average maintenance time for an existing component in the distribution, which in turn should provide both the employer and or the volunteer with the estimated time he/she needs to spend maintaining the component per day/week/month in the distribution
Also, where some of us seem to be at odds is the definition of "proper maintenance" for packages. My definition:
- Ensure that packages meet all of the packaging guidelines.
- Fix packaging related bugs in a timely manner.
- Incorporate new upstream releases, in accordance with packaging
guidelines (e.g. packages shouldn't be updated to a new major version in a released version of Fedora). 4) Incorporate patches that fix security issues or critical bugs.
The only difference is that I would add step number five acting as the liaison between upstream and downstream for reporters which to me is unavoidable for a packager/maintainer from my pov.
In my view these expectations imply that a packager has some involvement with upstream. I think that the level of involvement is going to depend on the packager and the package. I don't think that a hard and fast rule can be developed to cover every case without becoming ridiculously long and complex. Other than generally encouraging packagers to become involved with upstream development it should be left up to the conscience of the packager.
From my point of view If you are not involved with upstream ( at least subscribed to their mailing list and have a account in their upstream tracker ) you should not be maintaining package in the distribution but should instead just be maintaining it in a side repo.
In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves).
Agreed but at least they should know how to debug their own components which when I started the how to debug initiative a while back in QA revealed many of them did not even know how to do that.
OK, so with that out of a way, I'm hopefully going to respectfully (if wordily) respond to Jóhann's comments.
On Mon, Jun 17, 2013 at 10:55 AM, "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 06/17/2013 03:42 PM, Jeffrey Ollie wrote:
I maintain packages in Fedora because it allows me to get what I want to do done, whether at work or at home. Since I've done the work of making these packages, why not share them with the Fedora community?
Because if you cannot properly maintain the component in the distribution the community is better of without it.
- There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
Then you should not be maintaining that component
In some cases you may be right. But in most cases I was the only person to step up and package a particular piece of software. Also, in most cases I'm willing to step aside as the owner of a package if someone wants to take over the responsibility. In every case I've been willing to take on co-maintainers to help out with the packaging duties.
So here is where I see things go wrong for many packagers they fail to understand or rather we fail to provide proper info on how much time it takes to maintain a package in the distribution.
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
Again, our key disagreement here is on the definition of "proper maintenance". I have more than enough time to keep up with new versions as they are released (most of the time) or to pull a patch out of the upstream's version control and add it to the package. But even if I had the hardware I don't have the kind of time it takes to set up test environments to reproduce a bug, and then dig into the code and find the bug, develop a fix and then test it.
When you decide to maintain a component in the distribution you need to ensure that you have enough time to perform steps a) b) c) d) and e) not only steps a),b) and c).
The load or rather the time of the maintenance can however be distributed between co-maintainers and between existing sub communites in the distribution or for packagers/maintainers themselves by building a sub-community surrounding the component(s) in question.
It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of.
Playing "man in the middle" is inefficient. Unless it's an issue with packaging or Fedora-specific patches the reporter should work with the upstream developers to identify and fix the issue. Once a fix is available then it's the package maintainers responsibility to pull that fix into Fedora (either as a patch or a new release). That way the upstream developers can work directly with the user that is having the problem and ultimately every distribution benefits from the bug fix. The package maintainer should certainly be kept in the loop so that they know an update/patch is imminent.
Agreed that's inefficient but it's still a necessary and unavoidable part of maintainers responsibility from my point of view. ( even if we could link two bugzilla instances and fully automate the process that step would still be required by the downstream packager )
I personally think that the level of involvement/contact that a package maintainer needs to have with upstream depends on the component. For core components like the kernel or the Gnome stack expecting there to be a package (or packagers) that are intimately involved upstream is reasonable.
I personally dont make distinction between components or the role they play and if you package or otherwise maintain a component in the distribution then you need to at least be subscripted to their mailing list and have an upstream bug tracker account and promptly respond to reports and or when you are being directly contacted since the component you maintain will automatically affect QA/Releng community and potentially the feature process and security sub community as well.
Maintaining a package in the distribution is way much more then coming up a with a spec file and rolling out releases when ever upstream does...
JBG
On 06/17/2013 04:49 PM, "Jóhann B. Guðmundsson" wrote:
The only difference is that I would add step number five acting as the liaison between upstream and downstream for reporters which to me is unavoidable for a packager/maintainer from my pov.
+1
I think that this is where a Fedora packager can add a ton of value, even without deep knowledge of the code being packaged.
A lot of open source development communities are -- dare I say it -- fairly cliquish. A random end-user's bug reports or questions are often pretty much ignored. (I recognize that this isn't out of malice, BTW. Everyone is busy and we all have to do a sort of "social triage" to stay sane.) In many cases, the Fedora packager has built up a level of credibility with the development community that could get a bug report the attention that it deserves.
On Mon, Jun 17, 2013 at 09:49:37PM +0000, "Jóhann B. Guðmundsson" wrote:
On 06/17/2013 07:57 PM, Jeffrey Ollie wrote:
In my view these expectations imply that a packager has some involvement with upstream. I think that the level of involvement is going to depend on the packager and the package. I don't think that a hard and fast rule can be developed to cover every case without becoming ridiculously long and complex. Other than generally encouraging packagers to become involved with upstream development it should be left up to the conscience of the packager.
From my point of view If you are not involved with upstream ( at least subscribed to their mailing list and have a account in their upstream tracker ) you should not be maintaining package in the distribution but should instead just be maintaining it in a side repo.
That is your opinion. Others can have their own opinions about the matter.
In no way should packagers be expected to provide end-user support for packages, be an expert in every aspect of a package, or be expected to work with upstream to debug issues because the end user is unwilling to do the work themselves (in essence becoming an upstream developer themselves).
Agreed but at least they should know how to debug their own components which when I started the how to debug initiative a while back in QA revealed many of them did not even know how to do that.
And how is this relevant here?
- There's a 99.999% chance that I don't have the resources (either
hardware or software) to reproduce the bug.
Then you should not be maintaining that component
In some cases you may be right. But in most cases I was the only person to step up and package a particular piece of software. Also, in most cases I'm willing to step aside as the owner of a package if someone wants to take over the responsibility. In every case I've been willing to take on co-maintainers to help out with the packaging duties.
So here is where I see things go wrong for many packagers they fail to understand or rather we fail to provide proper info on how much time it takes to maintain a package in the distribution.
Because there is no way to quantify that. Because the world is not black and white and it differs from package to package.
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
Again, our key disagreement here is on the definition of "proper maintenance". I have more than enough time to keep up with new versions as they are released (most of the time) or to pull a patch out of the upstream's version control and add it to the package. But even if I had the hardware I don't have the kind of time it takes to set up test environments to reproduce a bug, and then dig into the code and find the bug, develop a fix and then test it.
When you decide to maintain a component in the distribution you need to ensure that you have enough time to perform steps a) b) c) d) and e) not only steps a),b) and c).
What are these steps?
The load or rather the time of the maintenance can however be distributed between co-maintainers and between existing sub communites in the distribution or for packagers/maintainers themselves by building a sub-community surrounding the component(s) in question.
I see two interpretations of the above paragraph: 1. You imply that the solution is to put every existing maintainer into several groups/sub-communities. 2. You think that there are hordes of people eager to become co-maintaineres, if only we had given them the chance.
Both are wrong.
It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of.
Playing "man in the middle" is inefficient. Unless it's an issue with packaging or Fedora-specific patches the reporter should work with the upstream developers to identify and fix the issue. Once a fix is available then it's the package maintainers responsibility to pull that fix into Fedora (either as a patch or a new release). That way the upstream developers can work directly with the user that is having the problem and ultimately every distribution benefits from the bug fix. The package maintainer should certainly be kept in the loop so that they know an update/patch is imminent.
Agreed that's inefficient but it's still a necessary and unavoidable part of maintainers responsibility from my point of view.
It is by no means unavoidable. In fact, it is very easy to avoid.
I personally think that the level of involvement/contact that a package maintainer needs to have with upstream depends on the component. For core components like the kernel or the Gnome stack expecting there to be a package (or packagers) that are intimately involved upstream is reasonable.
I personally dont make distinction between components or the role they play and if you package or otherwise maintain a component in the distribution then you need to at least be subscripted to their mailing list and have an upstream bug tracker account and promptly respond to reports and or when you are being directly contacted
Says who? The people around here are _volunteers_, not slaves. One does not create a community by forcing rules on others.
Maintaining a package in the distribution is way much more then coming up a with a spec file and rolling out releases when ever upstream does...
This is purely your interpretation.
D.
On 06/18/2013 06:24 AM, David Tardon wrote:
On Mon, Jun 17, 2013 at 09:49:37PM +0000, "Jóhann B. Guðmundsson" wrote:
From my point of view If you are not involved with upstream ( at least subscribed to their mailing list and have a account in their upstream tracker ) you should not be maintaining package in the distribution but should instead just be maintaining it in a side repo.
That is your opinion. Others can have their own opinions about the matter.
I never said they could not are you implying that I cant?
Agreed but at least they should know how to debug their own components which when I started the how to debug initiative a while back in QA revealed many of them did not even know how to do that.
And how is this relevant here?
This for example is relevant to debug the component in question and or provide that reporter with that debug information encase he needs to provide the packager with the proper report so the packager can forward the proper information upstream.
Basic triage stuff really...
So here is where I see things go wrong for many packagers they fail to understand or rather we fail to provide proper info on how much time it takes to maintain a package in the distribution.
Because there is no way to quantify that. Because the world is not black and white and it differs from package to package.
Yes there is a way to quantify that and provide an base time at best conditions
- There's a 100% chance that I don't have the time between work and
family obligations.
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
Again, our key disagreement here is on the definition of "proper maintenance". I have more than enough time to keep up with new versions as they are released (most of the time) or to pull a patch out of the upstream's version control and add it to the package. But even if I had the hardware I don't have the kind of time it takes to set up test environments to reproduce a bug, and then dig into the code and find the bug, develop a fix and then test it.
When you decide to maintain a component in the distribution you need to ensure that you have enough time to perform steps a) b) c) d) and e) not only steps a),b) and c).
What are these steps?
The once that you conveniently cut out when responding to this.
The load or rather the time of the maintenance can however be distributed between co-maintainers and between existing sub communites in the distribution or for packagers/maintainers themselves by building a sub-community surrounding the component(s) in question.
I see two interpretations of the above paragraph:
- You imply that the solution is to put every existing maintainer into several groups/sub-communities.
- You think that there are hordes of people eager to become co-maintaineres, if only we had given them the chance.
Both are wrong.
No you interpretation of my response is wrong.
Agreed that's inefficient but it's still a necessary and unavoidable part of maintainers responsibility from my point of view.
It is by no means unavoidable. In fact, it is very easy to avoid.
Yes at this point in time you can ignore bugs all you want and nobody said you could not but rather you should not.
Says who? The people around here are _volunteers_, not slaves. One does not create a community by forcing rules on others.
Trying to follow your logic hence the question do o you think we increase our user and contributing pool by delivering broken components in the hands of our userbase?
Anyway just because you are volunteering does not mean that you are an slave, cannot follow a set or rule or we cant have one.
This is purely your interpretation.
Yes this is my interpretation and findings after being over 5 years in the QA community, working on feature that spans multiple packages and more.
I'm allowed to have one right?
JBG
On Tue, Jun 18, 2013 at 09:13:23AM +0000, "Jóhann B. Guðmundsson" wrote:
On 06/18/2013 06:24 AM, David Tardon wrote:
Agreed but at least they should know how to debug their own components which when I started the how to debug initiative a while back in QA revealed many of them did not even know how to do that.
And how is this relevant here?
This for example is relevant to debug the component in question and or provide that reporter with that debug information encase he needs to provide the packager with the proper report so the packager can forward the proper information upstream.
Or the packager can send the reporter upstream, where there are people who understand the package.
Basic triage stuff really...
All right, if you want triaging, you can try to resurrect the old BugTriagers SIG... Btw, in libreoffice upstream it is QA who is doing the triaging (Hint .-)
So here is where I see things go wrong for many packagers they fail to understand or rather we fail to provide proper info on how much time it takes to maintain a package in the distribution.
Because there is no way to quantify that. Because the world is not black and white and it differs from package to package.
Yes there is a way to quantify that and provide an base time at best conditions
So, since you are so confident about it and since you are part of the "we" who fail to provide proper info to packagers, would you care to do it?
When you decide to maintain a component in the distribution you need to ensure that you have enough time to perform steps a) b) c) d) and e) not only steps a),b) and c).
What are these steps?
The once that you conveniently cut out when responding to this.
I thought so, but that list was denoted by numbers, not letters... So I was not sure if there was another list.
The load or rather the time of the maintenance can however be distributed between co-maintainers and between existing sub communites in the distribution or for packagers/maintainers themselves by building a sub-community surrounding the component(s) in question.
I see two interpretations of the above paragraph:
- You imply that the solution is to put every existing maintainer into several groups/sub-communities.
- You think that there are hordes of people eager to become co-maintaineres, if only we had given them the chance.
Both are wrong.
No you interpretation of my response is wrong.
What is the right interpretation then? Neither co-maintainers nor sub-communities can be created without _new_ packagers. Otherwise the load on the _current_ packagers will not be alleviated, just shuffled around a bit. And new packagers are not there. That is the main fallacy in your reasoning.
Says who? The people around here are _volunteers_, not slaves. One does not create a community by forcing rules on others.
Trying to follow your logic hence the question do o you think we increase our user and contributing pool by delivering broken components in the hands of our userbase?
Which components are broken, concretely? That a packager does not respond to bugs reported to his component does not mean anything is broken, except maybe your idea about how package maintenance works.
This is purely your interpretation.
Yes this is my interpretation and findings after being over 5 years in the QA community, working on feature that spans multiple packages and more.
I'm allowed to have one right?
Yes, you are.
D.
On Mon, Jun 17, 2013 at 9:57 PM, Jeffrey Ollie jeff@ocjtech.us wrote:
The tl;dr summary is that there shouldn't be a single standard for what we expect of packagers, especially in the context of what to expect when bugs are filed against their packages on Red Hat's bugzilla.
That's certainly true, with an open source project and volunteers contributing we can't require _packagers_ to commit to a specific workload. However, I think there should be a single standard for what we expect of _packages_.
That's not to say a package that doesn't meet that standard must not be allowed in Fedora - still, I would very much like to achieve a consensus that high-quality, qualified, in-Fedora maintenance is desirable. Then we can perhaps discuss ways to get closer to this desirable state, either by expanding the set of contributors or with our existing community.
For example, right now the easiest way to become a Fedora packager is still to learn RPM packaging (only) and add a new package (which will, by now, fairly often be something obscure with a few hundred of users), when quite a few existing packages with hundreds of thousands of users could use much help with debugging/bug fixing/programming, with fairly little focus on RPM. Mirek
"MT" == Miloslav Trmač mitr@volny.cz writes:
MT> For example, right now the easiest way to become a Fedora packager MT> is still to learn RPM packaging (only) and add a new package (which MT> will, by now, fairly often be something obscure with a few hundred MT> of users),
That is actually quite untrue, you know. You can see various routes to becoming a package maintainer at https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
MT> when quite a few existing packages with hundreds of MT> thousands of users could use much help with debugging/bug MT> fixing/programming, with fairly little focus on RPM.
Then if they want additional maintainers, why not use the existing procedure for that? It only takes one trac ticket.
- J<
On Mon, Jun 17, 2013 at 03:55:57PM +0000, "Jóhann B. Guðmundsson" wrote:
Because if you cannot properly maintain the component in the distribution the community is better of without it.
...
Then you should not be maintaining that component
...
We do not need unresponsive or poor maintained packages in the distribution and if there is really need or demand for the component you maintain, co-maintainers will appear or people to pick it up if you drop it so if you dont have the time to properly maintain your component(s) in the distribution then either find yourself co-maintainers or drop the package.
You have this persistent idea that there are hordes of potential new maintainers out there. Well, there are not. Trust me. I looked.
In all likelihood, what is going to happen if someone orphans a package is that some other _existing_ maintainer picks it up. Either because he uses it or because one of his packages depends on it (I had been a "maintainer" of bsh for more than a year. I have never used it and have only a vague idea what it does. All I know is that it is used by libreoffice's scripting framework.)
- Even though I'm an excellent programmer, well versed in C and
Python, and decent in Perl, Ruby, et. al. I probably don't have the familiarity with the codebase to even know where to start looking for a bug.
If you aren't familiar with the component you are packaging and maintaining why are you doing it et all?
Have you even read the sentence? He does not talk about using something, but about _debugging_ it. We do not expect maintainers to be developers. And even if they are, we definitely do not expect them to be faimiliar with the source code of every package they maintain.
- Most software is complex enough that even configuration problems
are best handled by upstream because I'd be familiar with a small set of configuration scenarios, but everyone's situation is unique and understanding what exactly a configuration option does (especially in edge cases) often requires an understanding of the code behind it.
All of this means that I'm a speedbump in the way of getting the bug fixed, at least until there's a patch that needs to be applied to the package, or a new release to upgrade to.
It's component's owner responsibility to be in touch and contact with upstream and the man in the middle role of the packager/maintainer can never be entirely gotten rid of.
Yes, it can.
D.
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
so bugzilla.redhat.com as a single point of contact is very helpful to me.
I wish life was that easy!
Is the web page I mentioned outdated, or are package maintainers expected to handle upstream bug tracker interactions?
Basically, if it is RPM packaging specific enhancement/bug, or if upstream uses bugzilla.redhat.com as their primary bugtracker (some do), then definitely bugzilla.redhat.com. Otherwise, common sense (and thoughtfulness :) ).
Cheers, Orcan
On 06/17/2013 01:00 PM, Orcan Ogetbil wrote:
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
It's your responsibility as an maintainer in the distribution to be in contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution...
JBG
On Mon, 17 Jun 2013 13:02:04 +0000, Jóhann B. Guðmundsson wrote:
On 06/17/2013 01:00 PM, Orcan Ogetbil wrote:
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
It's your responsibility as an maintainer in the distribution to be in contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution...
Let's not argue about it again and again, please. What works well for some packages and some software projects, isn't always feasible.
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Work_with...
Oh, and btw, we need more (co-)maintainers for packages.
On Jun 17, 2013 9:04 AM, Jóhann B. Guðmundsson wrote:
On 06/17/2013 01:00 PM, Orcan Ogetbil wrote:
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug
trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
It's your responsibility as an maintainer in the distribution to be in
contact with upstream, subscribed to their mailing lists, have an account in their upstream tracker and participate in their upstream community so yes that comes with the territory of being a responsible maintainer in the distribution..
The emphasis of my sentence was "playing the middle man", rather than "gazillion upstream trackers". Sorry for not being clear.
As a package maintainer, being the medium to transfer messages back and forth between upstream and the user is an extremely inefficient way to get things done. We are package maintainers, not email clients or web browsers. Please don't be so cruel to us :)
Orcan (Attempting to send this from android, I hope I did the formatting right.)
Am 17.06.2013 15:00, schrieb Orcan Ogetbil:
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
i expect a *package maintain er* has already a account in the upstream tracker of packages he maintains - nobody says he needs a gazillion accounts, but usually he has for the packages he maintains
the ordinary user has a few thousand packages installed
so bugzilla.redhat.com as a single point of contact is very helpful to me.
I wish life was that easy!
it should be that easy
answering in a bugreport "file the bugreport upstream" is the best way after the third time never ever get any bugrpeort from this person
Basically, if it is RPM packaging specific enhancement/bug
does not matter from the viewpoint of a *ordinary user* nor is he able to know if it is the case
or if upstream uses bugzilla.redhat.com as their primary bugtracker
does not matter from the viewpoint of a *ordinary user*
----- Original Message -----
Am 17.06.2013 15:00, schrieb Orcan Ogetbil:
On Mon, Jun 17, 2013 at 4:52 AM, Florian Weimer wrote:
I would like to avoid creating accounts in gazillion upstream bug trackers,
Aha! Should the package maintainers play the middle man in the gazillion upstream bug tracker accounts? This sounds neither very thoughtful nor quite efficient.
i expect a *package maintain er* has already a account in the upstream tracker of packages he maintains - nobody says he needs a gazillion accounts, but usually he has for the packages he maintains
the ordinary user has a few thousand packages installed
so bugzilla.redhat.com as a single point of contact is very helpful to me.
I wish life was that easy!
it should be that easy
answering in a bugreport "file the bugreport upstream" is the best way after the third time never ever get any bugrpeort from this person
I really don't want to repeat this neverending thread again but it's all about attitude of maintainer. If you get "file the bugreport upstream DOT" - without explanation, without reason. Yes - it's definitely the last report from that person. If you politely ask to report bug upstream, as it's really upstream job, you don't want to be man in the middle, but you CC on the bug and offer a help in case of problems or just say - if you can't report upstream, we will help you, you will actually get one more contributor. And I'd say it's our job too.
And yeah, I'm not saying it's easy - different bug reporting tools, different workflows. Especially for very specific ones without any documentation, maintainer should be that one who offers help first.
My 1 CZK.
Jaroslav
On Mon, Jun 17, 2013 at 10:52 AM, Florian Weimer fweimer@redhat.com wrote:
I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream.
The only way I can read https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Deal_with... is that bugzilla.redhat.com should be used and not ignored. OTOH that's the written policy, not the actual state, which is that some package maintainers disagree - usually, for what is, from an individual point of view, a good reason.
In general I'd say that packages where the maintainer that don't have the time, interest or willingness to handle bugzilla.redhat.com reports, should get comaintainers if at all possible. Mirek
Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit :
I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream.
I would like to avoid creating accounts in gazillion upstream bug trackers,
If only more bug trackers would accept openid, this would make the issue less problematic for all.
There is a plugin for that : https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin
So is there any reason to not offer it, or I can start filling bug to request it ?
On Mon, 17 Jun 2013 17:29:55 +0200 Michael Scherer misc@zarb.org wrote:
Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit :
I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream.
I would like to avoid creating accounts in gazillion upstream bug trackers,
If only more bug trackers would accept openid, this would make the issue less problematic for all.
There is a plugin for that : https://wiki.mozilla.org/Bugzilla:OpenID_Auth_Plugin
So is there any reason to not offer it, or I can start filling bug to request it ?
In bugzilla.redhat.com? Feel free to request it, but I don't think it will be much of a priority. ;(
Upstream bugzilla has moved to 'persona' instead of openid, and this openid plugin is pretty dead/unmaintained sadly.
kevin
On 06/17/2013 03:29 PM, Michael Scherer wrote:
Le lundi 17 juin 2013 à 10:52 +0200, Florian Weimer a écrit :
I'm wondering what the current guidelines for filing bugs on bugzilla.redhat.com are. https://fedoraproject.org/wiki/Bugs_and_feature_requests welcomes filing enhancement requests, but some package maintainers disagree and require filing bugs upstream.
I would like to avoid creating accounts in gazillion upstream bug trackers,
If only more bug trackers would accept openid, this would make the issue less problematic for all.
No it would not.
This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time.
JBG
Le 17/06/2013 17:37, "Jóhann B. Guðmundsson" a écrit :
No it would not.
This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time.
JBG
If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
Best regards, H.
On 06/17/2013 05:19 PM, Haïkel Guémar wrote:
If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
If we move we should remove epel since it's RHEL specific ( it belongs in RH Bugzilla ) well any arguments containing RHEL are moot Fedora != RHEL
The argument could be made we should use that instance instead of all tracker instances on fedora hosted and I would recommend we stick with mozilla ( since many upstream use it ) and or apply for [1] and move to atlassian jira maybe since we have a strong java team.
1. http://www.atlassian.com/software/views/open-source-license-request
On Mon, 17 Jun 2013 18:29:11 +0000 "Jóhann B. Guðmundsson" johannbg@gmail.com wrote:
On 06/17/2013 05:19 PM, Haïkel Guémar wrote:
If using Red Hat Bugzilla instance is the problem, then it's worth taking a look at having our own bugtracker. In fact, it's already been examined by our awesome infrastructure team and i personnally believe that we should help them fixing that. https://fedoraproject.org/wiki/Infrastructure_Fedora_bug_tracker
If we move we should remove epel since it's RHEL specific ( it belongs in RH Bugzilla ) well any arguments containing RHEL are moot Fedora != RHEL
I don't follow your logic there, but yes we would have to determine what we want to do with epel bugs if we moved anything.
The argument could be made we should use that instance instead of all tracker instances on fedora hosted and I would recommend we stick with mozilla ( since many upstream use it ) and or apply for [1] and move to atlassian jira maybe since we have a strong java team.
No go. http://fedoraproject.org/wiki/Infrastructure_Licensing
I'd like to note that we were/are just exploring this idea, there's nothing decided or set in stone. If you have constructive, concrete things to consider, please do add them to the wiki page.
kevin
On Mon, 17 Jun 2013 11:46:13 -0600 Eric Smith brouhaha@fedoraproject.org wrote:
Is the source code of the Red Hat Bugzilla instance published somewhere? A quick search didn't turn it up.
On Mon, Jun 17, 2013 at 1:18 PM, Kevin Fenzi kevin@scrye.com wrote:
It's very close to upstream bugzilla 4.4 at this point I think.
Thanks! It seems quite a bit different than other Bugzillas I use, but they're all significantly older versions, so I'll try 4.4.
* "Jóhann B. Guðmundsson" [17/06/2013 15:37] :
This can be solved technically and I have already explain how to do so in the past at least between two mozilla bugzilla instances and there was some bugzilla maintainer from Red Hat ( we are not running our own bugzilla instance so we cannot hack as we please but are forced to abide to what ever internal RH bugzilla admins have set that nobody in the community knows about ) looking into it but then he quit and that effort died with him as I understood it from James at that time.
If "This" refers to inter-bugzilla communication, I'ld love to have references to any efforts done to accomplish this.
Emmanuel
Is it possible to add a virtual team for each package(or only some packages with a lot of bugs)?
I mean, since upstream may ignore the bugs in bugzilla, we can add a maintainer team like kernel, or a sig like java, to cope with many bugs reported everyday if some programs really have so many. And this team/sig contains email address of upstream developers if they are willing to get notifications of bugs in bugzilla but don't wish to create an account.
Is it possible to add a virtual team for each package(or some packages with a lot of bugs)?
I mean, since upstream may ignore the bugs in bugzilla, we can add a maintainer team like kernel, or a sig like java, to cope with many bugs reported everyday if some programs really have so many. And this team/sig contains email address of upstream developers if they are willing to get notifications of bugs in bugzilla but don't wish to create an account.
I think being a liaison is not only I wish abrt can report bugs to external bug trackers, but it's impossible. And some upstream developers may not interested in bugzilla, too.
On Tue, 18 Jun 2013 08:58:04 +0800 Christopher Meng cickumqt@gmail.com wrote:
Is it possible to add a virtual team for each package(or some packages with a lot of bugs)?
yes, we have done so for a number of places. Currently the 'teams' are just an alias however. Hopefully in pkgdb2.0 we will finally have some real support for groups of people.
I mean, since upstream may ignore the bugs in bugzilla, we can add a maintainer team like kernel, or a sig like java, to cope with many bugs reported everyday if some programs really have so many. And this team/sig contains email address of upstream developers if they are willing to get notifications of bugs in bugzilla but don't wish to create an account.
I suppose, but creating an account is pretty easy, doing things with an alias means they actually will have less control over what is sending them email, so I suspect not many people would go for this.
I think being a liaison is not only I wish abrt can report bugs to external bug trackers, but it's impossible. And some upstream developers may not interested in bugzilla, too.
Sure, there's no one true answer here. Every package/upstream is different, IMHO.
kevin
-
Christopher Meng -
Colin Walters -
David Tardon -
Emmanuel Seyman -
Eric Smith -
Florian Weimer -
Haïkel Guémar -
Ian Pilcher -
Jaroslav Reznik -
Jason L Tibbitts III -
Jeffrey Ollie -
Jiri Eischmann -
Jóhann B. Guðmundsson -
Kevin Fenzi -
Michael Scherer -
Michael Schwendt -
Miloslav Trmač -
Orcan Ogetbil -
Pierre-Yves Chibon -
Reindl Harald -
Rex Dieter -
Richard Shaw