for my info, when a bug can be defined orphaned, i.e. which is the grace period not to be sorpassed???
On Tue, Jul 21, 2015 at 06:53:12PM +0200, antonio montagnani wrote:
for my info, when a bug can be defined orphaned, i.e. which is the grace period not to be sorpassed???
I don't know what sorpassed means. But....
* When a Fedora release reaches end-of-life, bugs filed against that release are automatically closed as "EOL". If you know that bug still exists in a supported version, please reopen these and reassign them to the current version or to rawhide.
* If a package maintainer appears to be totally unresponsive to bug reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
On 07/21/2015 11:09 AM, Matthew Miller wrote:
On Tue, Jul 21, 2015 at 06:53:12PM +0200, antonio montagnani wrote:
for my info, when a bug can be defined orphaned, i.e. which is the grace period not to be sorpassed???
I don't know what sorpassed means. But....
- When a Fedora release reaches end-of-life, bugs filed against that
release are automatically closed as "EOL". If you know that bug still exists in a supported version, please reopen these and reassign them to the current version or to rawhide.
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
It seems like if bugs against rel 1 are still open just before EOL, and closed thereafter, AND, these bugs are no longer in rel 2, does release 2 have any document stating that the bugs was fixed? How can a user trace that fix and then try to back-port it?
I suspect that the bug is never fixed even in rel 2, nor do the lease notes make any mention of the fix re: the automatically ignored bugs from the previous rel.
On 07/21/2015 10:18 AM, jd1008 wrote:
I suspect that the bug is never fixed even in rel 2, nor do the lease notes make any mention of the fix re: the automatically ignored bugs from the previous rel.
When a bug is closed at EOL but still exists, you can reopen it and change the version to a supported one. I know of one bug in Alacarte that spanned four different Fedora versions. If memory serves, it was closed as FIXED several times and re-opened because the various patches were ineffective.
On 07/21/2015 11:35 AM, Joe Zeff wrote:
On 07/21/2015 10:18 AM, jd1008 wrote:
I suspect that the bug is never fixed even in rel 2, nor do the lease notes make any mention of the fix re: the automatically ignored bugs from the previous rel.
When a bug is closed at EOL but still exists, you can reopen it and change the version to a supported one. I know of one bug in Alacarte that spanned four different Fedora versions. If memory serves, it was closed as FIXED several times and re-opened *because the various patches were ineffective*.
Indeed - this method has been the whole history of fixing the 4GB limit in TB.
Just for fun, here's one that originated in fedora 9 and is still there:
On Tue, Jul 21, 2015 at 11:18:09AM -0600, jd1008 wrote:
It seems like if bugs against rel 1 are still open just before EOL, and closed thereafter, AND, these bugs are no longer in rel 2, does release 2 have any document stating that the bugs was fixed?
Sometimes? Usually not.
How can a user trace that fix and then try to back-port it?
Well, if the new package works, you can try and rebuild it on the new release. Or... just upgrade.
I suspect that the bug is never fixed even in rel 2, nor do the lease notes make any mention of the fix re: the automatically ignored bugs from the previous rel.
Sometimes true. That's why it really helps to retest.
On 07/21/2015 10:09 AM, Matthew Miller wrote:
- When a Fedora release reaches end-of-life, bugs filed against that
release are automatically closed as "EOL". If you know that bug still exists in a supported version, please reopen these and reassign them to the current version or to rawhide.
You can pretty well tell that a program's not really maintained when you open a bug less than a month after a new Fedora version comes out and the second comment on it is that it's being closed at EOL for the version. And before anybody asks, I've had that happen more than once.
On Tue, Jul 21, 2015 at 10:20:32AM -0700, Joe Zeff wrote:
- When a Fedora release reaches end-of-life, bugs filed against that
release are automatically closed as "EOL". If you know that bug still exists in a supported version, please reopen these and reassign them to the current version or to rawhide.
You can pretty well tell that a program's not really maintained when you open a bug less than a month after a new Fedora version comes out and the second comment on it is that it's being closed at EOL for the version. And before anybody asks, I've had that happen more than once.
Yes -- it's hard to keep up. And while many Fedora package maintainers *do* try to facilitate when this happens, many of these bugs are upstream problems which are hard to fix at the Fedora level. It's best to file these with the upstream project. Of course, that's asking a lot more of users (track down upstream project, figure out their bug system, etc.), but... short of someone paying a lot more for Fedora package maintenance, it's hard to know a good solution.
Matthew Miller ha scritto il 21/07/2015 alle 19:09:
On Tue, Jul 21, 2015 at 06:53:12PM +0200, antonio montagnani wrote:
for my info, when a bug can be defined orphaned, i.e. which is the grace period not to be sorpassed???
I don't know what sorpassed means. But....
- When a Fedora release reaches end-of-life, bugs filed against that
release are automatically closed as "EOL". If you know that bug still exists in a supported version, please reopen these and reassign them to the current version or to rawhide.
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
On Fri, Jul 24, 2015 at 08:36:05AM +0200, antonio montagnani wrote:
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
On Fri, Jul 24, 2015 at 7:58 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jul 24, 2015 at 08:36:05AM +0200, antonio montagnani wrote:
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
responsive |riˈspänsiv| adjective 1 reacting quickly and positively
I'd say a maintainer who responds to an email saying not to contact him on that email, is non-responsive.
On Fri, Jul 24, 2015 at 08:47:26AM -0600, Chris Murphy wrote:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
responsive |riˈspänsiv| adjective 1 reacting quickly and positively I'd say a maintainer who responds to an email saying not to contact him on that email, is non-responsive.
I agree, and sorry if this wasn't clear from the link above. If the bugzilla address isn't valid, there's a short circuit process. And I agree that if the address is functionally disabled in this way, it's not really valid.
Chris Murphy ha scritto il 24/07/2015 alle 16:47:
On Fri, Jul 24, 2015 at 7:58 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jul 24, 2015 at 08:36:05AM +0200, antonio montagnani wrote:
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here: https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
responsive |riˈspänsiv| adjective 1 reacting quickly and positively
I'd say a maintainer who responds to an email saying not to contact him on that email, is non-responsive.
I find really silly that when you are encharged of a bug, there is no kind of supervisor checking if you are are working on it and any problem arising....Imagine it at Nasa, ehi guy, I have no time to check your bug and don't bother me :-)
You are assuming that the maintainers are employed/paid to maintain that project. In quite a number of cases they are not paid for it, so given that you may or may not get it fixed. And if I was a volunteer for a project and my "supervisor" started harassing me, then you would need a new maintainer for that project. Remember they are not being paid and you are not paying for the product. Even when one has an expensive paid support contract getting some things fix is still often impossible/difficult and in that case there is some limited contract requirements for the support organization to help you.
Remember most of the less used parts are volunteers they may or may not have time to fix the bug. I have fixed a few bugs that were in stuff that I used and that I was pretty sure there was no paid person to maintain. I submitted the fix/patch back to fedora and they fairly quickly put that patch into an update. This is how open source generally can work, others see the bug, figure out the fix and submit the fix.
On Sat, Jul 25, 2015 at 4:02 AM, antonio montagnani antonio.montagnani@alice.it wrote:
Chris Murphy ha scritto il 24/07/2015 alle 16:47:
On Fri, Jul 24, 2015 at 7:58 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jul 24, 2015 at 08:36:05AM +0200, antonio montagnani wrote:
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
responsive |riˈspänsiv| adjective 1 reacting quickly and positively
I'd say a maintainer who responds to an email saying not to contact him on that email, is non-responsive.
I find really silly that when you are encharged of a bug, there is no kind of supervisor checking if you are are working on it and any problem arising....Imagine it at Nasa, ehi guy, I have no time to check your bug and don't bother me :-)
-- Antonio M Skype: amontag52
Linux Fedora F22 (Twenty two) on Fujitsu Lifebook A512
http://lugsaronno.altervista.org http://campingmonterosa.altervista.org
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Roger Heflin ha scritto il 25/07/2015 alle 17:54:
You are assuming that the maintainers are employed/paid to maintain that project. In quite a number of cases they are not paid for it, so given that you may or may not get it fixed. And if I was a volunteer for a project and my "supervisor" started harassing me, then you would need a new maintainer for that project. Remember they are not being paid and you are not paying for the product. Even when one has an expensive paid support contract getting some things fix is still often impossible/difficult and in that case there is some limited contract requirements for the support organization to help you.
Remember most of the less used parts are volunteers they may or may not have time to fix the bug. I have fixed a few bugs that were in stuff that I used and that I was pretty sure there was no paid person to maintain. I submitted the fix/patch back to fedora and they fairly quickly put that patch into an update. This is how open source generally can work, others see the bug, figure out the fix and submit the fix.
On Sat, Jul 25, 2015 at 4:02 AM, antonio montagnani antonio.montagnani@alice.it wrote:
Chris Murphy ha scritto il 24/07/2015 alle 16:47:
On Fri, Jul 24, 2015 at 7:58 AM, Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Jul 24, 2015 at 08:36:05AM +0200, antonio montagnani wrote:
- If a package maintainer appears to be totally unresponsive to bug
reports, follow the process here:
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers
and when you contact him, you get the answer not to contact him on his personal mail (that is the same as in bugzilla)???
https://fedoraproject.org/wiki/Policy_for_nonresponsive_package_maintainers#...
responsive |riˈspänsiv| adjective 1 reacting quickly and positively
I'd say a maintainer who responds to an email saying not to contact him on that email, is non-responsive.
no, I am not assuming that maintainers are paid, but when you are a volunteer you must be honest to you and other people to say when you cannot continue to be a volunteer. And the circle is broken when the final user reports a bug but nobody seems to be working on it for a long time and you have no feedback
Hi
On Sat, Jul 25, 2015 at 1:15 PM, antonio montagnani wrote:
no, I am not assuming that maintainers are paid, but when you are a volunteer you must be honest to you and other people to say when you cannot continue to be a volunteer
This is much more tricky than you apparently assume it to be. Here is just a few different cases to consider from my own experience:
1) When a package becomes orphaned, sometimes you pick it up because you are using it or a component you are using it depends on it but then updates start coming in and people report bugs and you realize you don't have the time for maintaining the library itself even though the software that you do want to maintain, depends on it.
2) You bring a new package into Fedora with the idea that you are going to use it actively. A few months later, something better suited for you pops out and you aren't paying as much attention to the package you brought in.
3) Your volunteer time decreases because you switched jobs, moved places, got promoted etc and you don't have the time but you don't want to cut off involvement either. You look for co-maintainers but your package is obscure enough that only a few people even use it and noone is interested in maintaining it with you. Your choice is between abandoning the package with the understanding that you are going to have to maintain it privately for your own use (private repo before or copr these days) or maintain it with the understanding that you aren't going to have the time to answer every bug report immediately.
Rahul
On Sat, 25 Jul 2015 11:02:11 +0200 antonio montagnani antonio.montagnani@alice.it wrote:
I find really silly that when you are encharged of a bug, there is no kind of supervisor checking if you are are working on it and any problem arising....Imagine it at Nasa, ehi guy, I have no time to check your bug and don't bother me :-)
Thats not how open source projects work. ;)
Keep in mind that maintainers of Fedora packages are largely doing so in their spare time for their own reasons. They may like/use the package, or they may want to help out other people who do, or any of a number of other reasons.
Additionally, bugs/issues are present in all software, and maintainers need to figure out where to spend their time.
I find http://www.rants.org/2010/01/10/bugs-users-and-tech-debt/ to be a great read on this. :)
As to the responsive question and emails, personally I would surely respond to a personal email asking if I was still around/working on some package, but I would very much dislike getting bugs directly on personal email. It's bad for a lot of reasons for bug fixing purposes:
* It doesn't allow easy filtering into one place so you can work on bugs in the time you have set aside to do so.
* It cuts out all co-maintainers of a package from the conversation, some of which may be more active or know the solution to your bug.
* It's hard to notify anyone who might be interested in a fix.
* It doesn't allow easy transfer. If a maintainer decides to hand a package off to another maintainer(s) they may not have those emails or know anything about those bugs.
So, please do file bugs or issues in bugzilla.
kevin
On Sat, Jul 25, 2015 at 11:02:11AM +0200, antonio montagnani wrote:
I find really silly that when you are encharged of a bug, there is no kind of supervisor checking if you are are working on it and any problem arising....Imagine it at Nasa, ehi guy, I have no time to check your bug and don't bother me :-)
Note that this basically _is_ the case when you pay for Red Hat Enterprise Linux and create a support request through the official channels for that. And, for Red Hatters where _that_ is their primary job but they work on Fedora too, those cases will therefore always necessarily take precedence. That doesn't mean that people don't care about the bug reports from other channels, but they can't always be the top priority. And that's just for maintainers who happen to work at Red Hat — for others, it's not their day-job at all.
Maintainers _should_ address bugs — that's why we have that unresponsive maintainer process, after all — but there's no SLA. There's really no way you can get that *anywhere* without paying for it.
-
antonio montagnani -
Chris Murphy -
JD -
Joe Zeff -
Kevin Fenzi -
Matthew Miller -
Rahul Sundaram -
Roger Heflin -
Tom Horsley