I know people work hard on these releases, but some bugs should be obvious...
I downloaded the 5bin cds yesterday, and tried to install it in an extra partition on my disk (3.2GHz Pentium4, 945Gnt Motherboard).
Probably 8 out of 10 times the installer died while I was picking packages to install. Each time it would pop up a message box saying something to the effect 'this is a bug' and describing how to report it.
OK, with repeated beating, on at least two attempts I got by the 'picking packages' bug and got to the actual install. In both cases I got somewhere late on the 1st CD (the ribbon showed that I was about 50% installed), and now it complains about an unexpected interrupt, pops up a message box and dies.
Not nice.
And WHAT WAS WRONG WITH THE PREVIOUS install program, it seems to have worked fine ever since RedHat5 or 6. Why is it being replaced with something that is not even debugged?
Guess Ill wait and give it another try when FC5T3 is available, but this doesnt leave a very good feeling in my stomach... All I wanted to do was see if this release supports the Intel 945 Motherboards (It appears it does), but Im not going to try the support till I can at least install a system. Sigh.
Reg Clemens wrote:
And WHAT WAS WRONG WITH THE PREVIOUS install program, it seems to have worked fine ever since RedHat5 or 6. Why is it being replaced with something that is not even debugged?
You fairly obviously havn't subscribed to or read the mailing list for very long so i might suggest that you read the archives a little and you'll see why the installer is being upgraded. You raise some very good points about the instability of the package selection process and i would argue that i had very similar troubles (with equal beating) under the old system that glows fondly in your memory. Please file bug reports against the components and help fix the problems you find. A FCtest release does not equal a release candidate in the traditional sense (something else you can catch up on in this list). Best of luck and happy hunting. -mf
Hi,
Probably 8 out of 10 times the installer died while I was picking packages to install. Each time it would pop up a message box saying something to the effect 'this is a bug' and describing how to report it.
Have you put this into bugzilla? It could be anything. When booting up, try putting acpi=0 and use_dma=0 (IIRC) on the linux command line and see what happens.
OK, with repeated beating, on at least two attempts I got by the 'picking packages' bug and got to the actual install. In both cases I got somewhere late on the 1st CD (the ribbon showed that I was about 50% installed), and now it complains about an unexpected interrupt, pops up a message box and dies.
Have you tested the integrity of the CDs? It's a common problem that people create the CDs at top speed and this is not good.
And WHAT WAS WRONG WITH THE PREVIOUS install program, it seems to have worked fine ever since RedHat5 or 6. Why is it being replaced with something that is not even debugged?
Pass. There are 1001 reasons for a program not to work. By reporting the bug via bugzilla the engineers can sort out the problem quickly.
Guess Ill wait and give it another try when FC5T3 is available, but this doesnt leave a very good feeling in my stomach... All I wanted to do was see if this release supports the Intel 945 Motherboards (It appears it does), but Im not going to try the support till I can at least install a system. Sigh.
Please help FC by reporting the bugs using the mechanism shown. File against pirut (IIRC) when you do. Try reburning the ISOs at x4 on good quality CDs and then test that the CDs are functioning fine before the install proper via the CD tester.
The installer for FC5T1 left a lot to be desired, but those bugs were quickly fixed because they were reported correctly.
TTFN
Paul
Have you tested the integrity of the CDs? It's a common problem that people create the CDs at top speed and this is not good.
Well, the CDs were burnt at high speed, but they were verified, so I do have some confidence in them. I did burn this first (disc1) at a lower speed and used it for these tests,- tho I didnt go as far as x4 as was recommended by one respondent.
On Thu, 2006-01-19 at 23:52 -0700, Reg Clemens wrote:
And WHAT WAS WRONG WITH THE PREVIOUS install program, it seems to have worked fine ever since RedHat5 or 6. Why is it being replaced with something that is not even debugged?
The installer is changing how packages get installed. In order to move forward and be able to handle such things as using Extras at install time, or any other repo, the internal bits that install packages and resolve deps had to be replaced. They've been replaced with yum. So all the stuff that interacts with this has to change as well.
We did several smoke tests of test2 prior to sending it to the mirroring system. Multiple installs on multiple hardware platforms, using multiple install methods. Had we ran into something obviously wrong like what you are seeing, we would have not shipped Test2 until it got fixed. However we didn't and thus we shipped it.
The PC market is very tough to satisfy. There are an infinite number of combinations of hardware. There really isn't enough time ever to test each and every one of these platforms before shipping a release, especially a test release. We make a best effort at testing certain platforms. The only way we can touch on more combinations is to release software and let you, the community, test. If you run into bugs, GREAT! File it and we'll try to fix it so that the next person using your hardware won't run into the problem.
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door. We do, and in fact we're actively seeking to hire somebody to lead our Fedora QA efforts. If you think you've got what it takes to lead a QA effort, and engage the community to leverage community resources for QA efforts, please forward me your resume.
On 1/20/06, Jesse Keating jkeating@redhat.com wrote:
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door. We do, and in fact we're actively seeking to hire somebody to lead our Fedora QA efforts.
If only there was a way a sane way to track hardware coverage being actively tested in-house and then later on in the public test2 phase. A little more transparency as to the variety of hardware thats participating in the testing phases might headoff some of the more knee-jerk complaints. But there really isn't a sane way to track all the hardware variations even if we got system data back from testers in an automated fashion.. organizing it or mining it would be a pain.
-jef
On Fri, 2006-01-20 at 12:11 -0500, Jeff Spaleta wrote:
If only there was a way a sane way to track hardware coverage being actively tested in-house and then later on in the public test2 phase. A little more transparency as to the variety of hardware thats participating in the testing phases might headoff some of the more knee-jerk complaints. But there really isn't a sane way to track all the hardware variations even if we got system data back from testers in an automated fashion.. organizing it or mining it would be a pain.
I do believe we're exploring the use of pootypedia:
http://pootypedia.sourceforge.net/
On Fri, 2006-01-20 at 12:11 -0500, Jeff Spaleta wrote:
If only there was a way a sane way to track hardware coverage being actively tested in-house and then later on in the public test2 phase. A little more transparency as to the variety of hardware thats participating in the testing phases might headoff some of the more knee-jerk complaints.
Problem is, in many cases we really can't say what we're testing in house. While you may have a Dual-Core Xeon with an i945 chipset, and I may have a Dual-Core Xeon with an i945 chipset, and they may be *very* similar hardware, mine is almost certainly a pre-production machine covered by NDA, and I can't tell you about it. This is basically the case for 2/3 of the machines I've done the dmraid installer work on, and the same is true of other developers and many other features.
That's not something that lends itself to transparency, and I don't suspect it'll get better in any way.
But there really isn't a sane way to track all the hardware variations even if we got system data back from testers in an automated fashion.. organizing it or mining it would be a pain.
We actually did this hardware tracking in RHN[0], and it's one of the worst things we lost when RHN stopped supporting Fedora. But yes, organizing this kind of data is extraordinarily painful, and mining the data isn't really any better.
Even with all the hardware data, we need more than that -- we need to know essentially all of the info in anaconda.ks.cfg, as well as the full packageset (think NVREA) selected. Even with a really good data model, this explodes to be very large, quite quickly. And guess what? In nearly all test cases that aren't fresh installs, we're going to find out that there's some package google doesn't know about on the box. Sometimes that package will matter, sometimes it won't.
Even having all that won't help for cases like Reg's video card problems -- the problem there is almost certainly DDC failing. If the hardware probe fails, we're going to have missing (or worse) data in the list of tested hardware. And you really can't distinguish between a monitor that isn't giving us DDC vs one that's just not plugged in.
[0] See the bit about using the data up2date/rhn_register send us in aggregate? We were big fans of telling certain hardware vendors real numbers about how many RH customers really were using their hardware in Linux. Sadly, it didn't seem to have much effect.
Peter Jones wrote:
Even with all the hardware data, we need more than that -- we need to know essentially all of the info in anaconda.ks.cfg, as well as the full packageset (think NVREA) selected. Even with a really good data model, this explodes to be very large, quite quickly. And guess what? In nearly all test cases that aren't fresh installs, we're going to find out that there's some package google doesn't know about on the box. Sometimes that package will matter, sometimes it won't.
Enumerate the problems. Apply yourselves to the easy ones. Ask yourselves, "how can we do this?" for each important one.
The list will become smaller, and over time someone will have some useful ideas about the harder ones and someone might find a budget if it's important enough.
Complaining about it won't help, tho asking here for help might. For example: I have a couple of laptops, and I regularly move around between about six access points. OS X does it beautifully, whether the AP is hidden or not: when I open the lid it connects to whichever is handy, gets an IP address etc and is ready for business.
SUSE 10. which is on my new laptop because RC5T1 was an utter failure, is a great pain. It might just be documentation, but I've not found a good way to make it work.
FC3 is barely tolerable; I have to manually run the appropriate ifdown/ifup incantation.
Ubuntu I've not tested, but its plan is perfection in Dapper, to be achieved by asking users (like us), "Can you help in this thing?"
On 1/21/06, John Summerfied debian@herakles.homelinux.org wrote:
Ubuntu I've not tested, but its plan is perfection in Dapper, to be achieved by asking users (like us), "Can you help in this thing?"
Fedora isn't asking you to help? Here I'll clear that up for you.. "please pretty pretty please, help test the test releases" "please pretty pretty please, help by filing bug reports" "please pretty pretty please, help by providing patches and submitting them for review to the appropriate package maintainer" "please pretty pretty please, help by testing the installer by using the nightly builds of the boot.iso being placed in the development tree"
What exactly is Ubuntu asking users like you to do that Fedora isn't asking it testers? Unfortuntely, since you haven't actually tested Ubuntu you probably aren't informed enough about their development process to give a well-informed answer.
The fact that you hold Ubuntu's process up on a pedestal.. and yet that is the one distro you haven't personally tested in your "everything i've tried is crap" list.. tell's me a great deal about how you form your opinions. If you think Ubuntu is the project where you can make the most impact, please contribute to Ubuntu. I just hope you aren't a drag on their development.
-jef"ppc hardware and you haven't tried yellowdog....i'm so very disappointed"spaleta
Hi
Ubuntu I've not tested, but its plan is perfection in Dapper, to be achieved by asking users (like us), "Can you help in this thing?"
Oh. come on. Havent we begged enough for the user to help yet?. A few trillion times more might help I guess. Plan to perfection is what we do every single day but then pesty things like implementation, resources and time does matter.
fre, 20 01 2006 kl. 09:03 -0800, skrev Jesse Keating:
The installer is changing how packages get installed. In order to move forward and be able to handle such things as using Extras at install time, or any other repo, the internal bits that install packages and resolve deps had to be replaced. They've been replaced with yum. So all the stuff that interacts with this has to change as well.
I, for one, welcome my new installer overlords - I think it's a vast improvement over the traditional and welltested Anaconda versions. I'm quite sure Katz will have it hammered into shape come test3
We did several smoke tests of test2 prior to sending it to the mirroring system. Multiple installs on multiple hardware platforms, using multiple install methods. Had we ran into something obviously wrong like what you are seeing, we would have not shipped Test2 until it got fixed. However we didn't and thus we shipped it.
If people feel that such smoketesting is required, I would heartly encourage them to try doing a netinstall - the process is speedy (if one has a good connection) and it gives a great look at how the installer is coming along.
The PC market is very tough to satisfy. There are an infinite number of combinations of hardware. There really isn't enough time ever to test each and every one of these platforms before shipping a release, especially a test release. We make a best effort at testing certain platforms. The only way we can touch on more combinations is to release software and let you, the community, test. If you run into bugs, GREAT! File it and we'll try to fix it so that the next person using your hardware won't run into the problem.
For i386 I'm extremely impressed that I don't hit more bugs, considering the near infinite combinations of hardware out there and the decades of workarounds for maldesign and known broken behavior. I assume that everyone who hits a bug rather than retaining hatred and bile, will file a bug - how else would it go away, magic?
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door. We do, and in fact we're actively seeking to hire somebody to lead our Fedora QA efforts. If you think you've got what it takes to lead a QA effort, and engage the community to leverage community resources for QA efforts, please forward me your resume.
If only I had talent.. for now I'll settle for congratulating my buddy Jesse on a fine first release. FC5t2 is by far the best distro I have had my hands on lately.
- David Nielsen
Jesse Keating wrote:
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door.
You shouldn't be. Have you forgotten the users' perspective so soon? If one puts as much effort into installing it as the OP appears to, then the conclusion that there's been unsufficient testing is a reasonable one for a user to make.
Hinting that BZ is a good idea is fine, but I for one find it a royal pain to use, and nobody's found time to write an email (or similar) interface that Mike Harris agreed was a fine idea before he joined RH.
More important is asking for the specifics of what went wrong, and asking in _this_ forum is way more likely to get related input from others than you could hope to get with bugzilla.
On Sun, 2006-01-22 at 09:13 +0800, John Summerfied wrote:
Jesse Keating wrote:
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door.
You shouldn't be. Have you forgotten the users' perspective so soon? If one puts as much effort into installing it as the OP appears to, then the conclusion that there's been unsufficient testing is a reasonable one for a user to make.
I've probably done (well, at least started) 300 installs so far this month, if not more. Like it or not, the way humans work largely involves acclimating ourselves to patterns. So for some bugs, which I'm particularly *searching* for, I'm going to find them. But the sheer number of installs I do is going to render me blind to many things. The same holds true for many developers.
I could do 1000 installs in a month, and it wouldn't make things *better*. This is why we have test releases -- so people who don't do 10+ installs per day will see it and report what *they* see, rather than what those of us who are unquestionably acclimated to both the code and the behavior see.
Hinting that BZ is a good idea is fine, but I for one find it a royal pain to use, and nobody's found time to write an email (or similar) interface that Mike Harris agreed was a fine idea before he joined RH.
Long ago I worked in support, when you could email in a support query *with* authentication to prove you were a paying customer. That's a significantly higher of a barrier to entry than the panacea which you're suggesting. I really wish you could still email support questions and hope to get a reasonably answer. I totally disagree with the idea that this feature is even anything remotely like a good idea in a bug reporting system. All that it will accomplish is more reports. Not more legitimate bugs actually being reported.
More important is asking for the specifics of what went wrong, and asking in _this_ forum is way more likely to get related input from others than you could hope to get with bugzilla.
Have we forgotten the start of this thread? The original post included this text:
Probably 8 out of 10 times the installer died while I was picking packages to install. Each time it would pop up a message box saying something to the effect 'this is a bug' and describing how to report it.
Not exactly specifics, and the instructions (which clearly were presented) have not been followed. Nor have details emerged in response to our queries for descriptions of the particular configuration in question.
Peter Jones wrote:
On Sun, 2006-01-22 at 09:13 +0800, John Summerfied wrote:
Jesse Keating wrote:
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door.
You shouldn't be. Have you forgotten the users' perspective so soon? If one puts as much effort into installing it as the OP appears to, then the conclusion that there's been unsufficient testing is a reasonable one for a user to make.
I've probably done (well, at least started) 300 installs so far this
Um, Peter, I was addressing my remarks to Jesse.
I worked on IBM's PL/1 compiler for a time, and my major task was testing the compile against a supply of around 11,000 testcases, some of which dated back to bugs reported in the early 70s - 20 years before. I know a little about testing.
month, if not more. Like it or not, the way humans work largely involves acclimating ourselves to patterns. So for some bugs, which I'm particularly *searching* for, I'm going to find them. But the sheer number of installs I do is going to render me blind to many things. The same holds true for many developers.
I could do 1000 installs in a month, and it wouldn't make things *better*. This is why we have test releases -- so people who don't do 10+ installs per day will see it and report what *they* see, rather than what those of us who are unquestionably acclimated to both the code and the behavior see.
OTOH I have reported a memory leak in Mozilla (to Mozilla.org I think, but it could have been Debian). There is something about the way I use Mozilla that causes it to consume all of available memory and to not let it go until it ends. Others have reported the same kind of probkem, and on a variety of platforms including Windoes (no, it wouldn't have been Debian).
The bug was closed because the developers couldn't recreate the problem, and since I cannot run Mozilla without seeing the problem I cannot avoid the problem any more than they could create it.
I don't know whether the problem's fixed now; I'm running with a Gb of RAM and my usage patterns may have changed.
The point is not how much testing you're doing; more important is what you're testing, and it seems likely that you are not testing what the OP is trying to do.
If he and you can get together over a VNC session, then maybe he can show you.
Hinting that BZ is a good idea is fine, but I for one find it a royal pain to use, and nobody's found time to write an email (or similar) interface that Mike Harris agreed was a fine idea before he joined RH.
Long ago I worked in support, when you could email in a support query *with* authentication to prove you were a paying customer. That's a significantly higher of a barrier to entry than the panacea which you're suggesting. I really wish you could still email support questions and hope to get a reasonably answer. I totally disagree with the idea that this feature is even anything remotely like a good idea in a bug reporting system. All that it will accomplish is more reports. Not more legitimate bugs actually being reported.
More important is asking for the specifics of what went wrong, and asking in _this_ forum is way more likely to get related input from others than you could hope to get with bugzilla.
Have we forgotten the start of this thread? The original post included this text:
Probably 8 out of 10 times the installer died while I was picking packages to install. Each time it would pop up a message box saying something to the effect 'this is a bug' and describing how to report it.
Evidently he's doing something unlike what you're testing, Peter.
Not exactly specifics, and the instructions (which clearly were presented) have not been followed. Nor have details emerged in response to our queries for descriptions of the particular configuration in question.
I've not seen his problem; I've not yet tried to install t2, but I'm sure I saw something in its documentation telling testers to report problems here. That's what he did.
John Summerfied wrote:
Jesse Keating wrote:
So while the bug(s) may seem obvious to you, unless your exact hardware is sitting in my cube it isn't going to seem very obvious to me. I am a bit hurt at the implication that we don't even bother to test our release before we send it out the door.
You shouldn't be. Have you forgotten the users' perspective so soon? If one puts as much effort into installing it as the OP appears to, then the conclusion that there's been unsufficient testing is a reasonable one for a user to make.
Hinting that BZ is a good idea is fine, but I for one find it a royal pain to use, and nobody's found time to write an email (or similar) interface that Mike Harris agreed was a fine idea before he joined RH.
Talking about throwing the baby along with the bathwater. If Bugzilla is not optimal, lets fix that problem instead trading one set of pain with another by switching to a new tracking system unless bugzilla is non fixable. List specifically all the gripes that you have with bugzilla or even better help us fix it.
Rahul Sundaram wrote:
Talking about throwing the baby along with the bathwater. If Bugzilla is not optimal, lets fix that problem instead trading one set of pain with another by switching to a new tracking system unless bugzilla is non fixable. List specifically all the gripes that you have with bugzilla or even better help us fix it.
We'll start with "it's painfully slow."
I'm on dialup, it seems like it takes minutes to do an enquiry.
We'll proceed to "its UI is cumbersome." Especially for those not already familiar with it. If you make changes, don't rely on experienced users to evaluate it, get some tyros, people you'd like to enrol as helpers for the future. I could also mention, "it's confusing." Some of the problem, I think, is in Red Hat's implementation and the way its ordered the data. If I want to report a problem in the kernel, let me identify the kernel, maybe kernel-2.6.10-1.760_dl3, and you can match it up with your view of the "product."
I've also used Debian's BTS: while it's not brilliant, it can search for matching bugs, and it can work offline without referent to the master database. Since Debian has way more packages & architectures than RH/Fedora, I presume the size of its database isn't a problem from its performance perspective. OTOH I note Ubuntu uses BZ so maybe developers don't like it so well.
One of the things you might like about bts is that it's a script that runs on the user system which is usually the one with the problem, and it can get some basic information about the software installed and the hardware in use. For the users' peace of mind, it allows her to see what's being said, and on her okay, mails it to the bts.
Would that help Mike Harris sort out video problems? I think it would.
John Summerfied wrote:
Rahul Sundaram wrote:
Talking about throwing the baby along with the bathwater. If Bugzilla is not optimal, lets fix that problem instead trading one set of pain with another by switching to a new tracking system unless bugzilla is non fixable. List specifically all the gripes that you have with bugzilla or even better help us fix it.
We'll start with "it's painfully slow."
I'm on dialup, it seems like it takes minutes to do an enquiry.
I used it on dialup on several occasions and I dont see this problem. Of couse its slower than when being used in a T1 connection.
We'll proceed to "its UI is cumbersome." Especially for those not already familiar with it. If you make changes, don't rely on experienced users to evaluate it, get some tyros, people you'd like to enrol as helpers for the future. I could also mention, "it's confusing." Some of the problem, I think, is in Red Hat's implementation and the way its ordered the data. If I want to report a problem in the kernel, let me identify the kernel, maybe kernel-2.6.10-1.760_dl3, and you can match it up with your view of the "product."
You need to be much more specific than that. Can you produce mockups of what the interface and workflow of what you believe is needed?
I've also used Debian's BTS: while it's not brilliant, it can search for matching bugs, and it can work offline without referent to the master database. Since Debian has way more packages & architectures than RH/Fedora, I presume the size of its database isn't a problem from its performance perspective.
I am not sure. Database performance is a definite bottleneck on many occasions
OTOH I note Ubuntu uses BZ so maybe developers don't like it so well.
Maybe. We cant use presumptions to change a working product.
One of the things you might like about bts is that it's a script that runs on the user system which is usually the one with the problem, and it can get some basic information about the software installed and the hardware in use. For the users' peace of mind, it allows her to see what's being said, and on her okay, mails it to the bts.
I dont think Red Hat or Fedora is going to dump its entire history of bugs to move into bts unless bts is far more advanced and provides capabilities that cannot be inherited into bugzilla.
Would that help Mike Harris sort out video problems? I think it would.
Not sure what video problems you are talking about. Got a bug report? Why dont you ask him whether dumping bugzilla is what is needed to fix any video problems?. He is not in this list but he is on fedora-devel list and hangs out all the time in #fedora-devel.
Hi,
We'll start with "it's painfully slow."
I'm on dialup, it seems like it takes minutes to do an enquiry.
I used it on dialup on several occasions and I dont see this problem. Of couse its slower than when being used in a T1 connection.
I'm on a 4Mb connection at home and T3 at work and to me, it's slow. It could be a browser thing or something else, but I would agree that compared to the bugzilla on ximian or even Gnome, it feels sticky.
TTFN
Paul
Paul F. Johnson wrote:
Hi,
We'll start with "it's painfully slow."
I'm on dialup, it seems like it takes minutes to do an enquiry.
I used it on dialup on several occasions and I dont see this problem. Of couse its slower than when being used in a T1 connection.
I'm on a 4Mb connection at home and T3 at work and to me, it's slow. It could be a browser thing or something else
Mostly like a issue of workflow pattern. I use RSS feeds and pick up specific reports.
Rahul Sundaram wrote:
We'll start with "it's painfully slow."
I'm on dialup, it seems like it takes minutes to do an enquiry.
I used it on dialup on several occasions and I dont see this problem. Of couse its slower than when being used in a T1 connection.
<shrug> It's a problem here. I'd have ADSL except I'm out of its reach. I rarely have the luxury of a dialup line with nothing else on it.
We'll proceed to "its UI is cumbersome." Especially for those not already familiar with it. If you make changes, don't rely on experienced users to evaluate it, get some tyros, people you'd like to enrol as helpers for the future. I could also mention, "it's confusing." Some of the problem, I think, is in Red Hat's implementation and the way its ordered the data. If I want to report a problem in the kernel, let me identify the kernel, maybe kernel-2.6.10-1.760_dl3, and you can match it up with your view of the "product."
You need to be much more specific than that. Can you produce mockups of what the interface and workflow of what you believe is needed?
Not really. I've done almost no UI design in almost 30 years.
I've also used Debian's BTS: while it's not brilliant, it can search for matching bugs, and it can work offline without referent to the master database. Since Debian has way more packages & architectures than RH/Fedora, I presume the size of its database isn't a problem from its performance perspective.
I am not sure. Database performance is a definite bottleneck on many occasions
On Debian's BTS?
OTOH I note Ubuntu uses BZ so maybe developers don't like it so well.
Maybe. We cant use presumptions to change a working product.
Feel free to ask mdz @ ubuntu.com - he could tell you.
One of the things you might like about bts is that it's a script that runs on the user system which is usually the one with the problem, and it can get some basic information about the software installed and the hardware in use. For the users' peace of mind, it allows her to see what's being said, and on her okay, mails it to the bts.
I dont think Red Hat or Fedora is going to dump its entire history of bugs to move into bts unless bts is far more advanced and provides capabilities that cannot be inherited into bugzilla.
I don't think I said any thing of that kind.
Would that help Mike Harris sort out video problems? I think it would.
Not sure what video problems you are talking about. Got a bug report? Why dont you ask him whether dumping bugzilla is what is needed to fix any video problems?. He is not in this list but he is on fedora-devel list and hangs out all the time in #fedora-devel.
As I recall, Mike spends most of his life these days fighting bugs in xorg software, much as he has since he was hired, I little before Valhalla I think. Whenever anyone has a hardware-related problem (or question), the first question is "What's the hardware?" I know, I ask it on fedora-list often enough, two or three times today at a guess. Surely, Mike asks it too?
Hi
You need to be much more specific than that. Can you produce mockups of what the interface and workflow of what you believe is needed?
Not really. I've done almost no UI design in almost 30 years.
Well we need to corner down issues into a much more specific level somehow.
I am not sure. Database performance is a definite bottleneck on many occasions
On Debian's BTS?
Not specific to one tracking system.
Maybe. We cant use presumptions to change a working product.
Feel free to ask mdz @ ubuntu.com - he could tell you.
Done ;-)
I dont think Red Hat or Fedora is going to dump its entire history of bugs to move into bts unless bts is far more advanced and provides capabilities that cannot be inherited into bugzilla.
I don't think I said any thing of that kind.
What are you suggesting then?
Would that help Mike Harris sort out video problems? I think it would.
Not sure what video problems you are talking about. Got a bug report? Why dont you ask him whether dumping bugzilla is what is needed to fix any video problems?. He is not in this list but he is on fedora-devel list and hangs out all the time in #fedora-devel.
As I recall, Mike spends most of his life these days fighting bugs in xorg software, much as he has since he was hired, I little before Valhalla I think. Whenever anyone has a hardware-related problem (or question), the first question is "What's the hardware?" I know, I ask it on fedora-list often enough, two or three times today at a guess. Surely, Mike asks it too?
Solution to that problem is fixing the darn client interface like bugbuddy and the messaging system like XMLRPC to gather information from system hardware when bugs are filed. No amount of fiddling bugzilla or any other bug tracking system is likely to help there.
Rahul Sundaram wrote:
I am not sure. Database performance is a definite bottleneck on many occasions
On Debian's BTS?
Not specific to one tracking system.
Maybe. We cant use presumptions to change a working product.
Feel free to ask mdz @ ubuntu.com - he could tell you.
Done ;-)
I dont think Red Hat or Fedora is going to dump its entire history of bugs to move into bts unless bts is far more advanced and provides capabilities that cannot be inherited into bugzilla.
I don't think I said any thing of that kind.
What are you suggesting then?
I don't like Bugzilla, at least as RH has it implemented. I suggested bts as a bug tracking system I've found usable.
You could transfer your stuff to bts, but it's probably more sensible to look at bts and learn from it.
Would that help Mike Harris sort out video problems? I think it would.
Not sure what video problems you are talking about. Got a bug report? Why dont you ask him whether dumping bugzilla is what is needed to fix any video problems?. He is not in this list but he is on fedora-devel list and hangs out all the time in #fedora-devel.
As I recall, Mike spends most of his life these days fighting bugs in xorg software, much as he has since he was hired, I little before Valhalla I think. Whenever anyone has a hardware-related problem (or question), the first question is "What's the hardware?" I know, I ask it on fedora-list often enough, two or three times today at a guess. Surely, Mike asks it too?
Solution to that problem is fixing the darn client interface like bugbuddy and the messaging system like XMLRPC to gather information from system hardware when bugs are filed. No amount of fiddling bugzilla or any other bug tracking system is likely to help there.
If you make bugbuddy talk to BZ that's fine by me. I've not used it as, when I first saw it, it was set up to talk to Gnome and I didn't think it the right place to report problems in software shipped by RH. Similarly, I've not used KDE's crash hander.
If bugbuddy works (or can be made to work) online and offline, and doesn't require (but can benefit from) a GUI that would be good and should well perform well from the users's POV.
Hi
I don't like Bugzilla, at least as RH has it implemented. I suggested bts as a bug tracking system I've found usable.
You could transfer your stuff to bts, but it's probably more sensible to look at bts and learn from it.
Ya right but since you already seem to be familiar with bts I would appreciate a good comparison of features that can be implemented in Bugzilla
If you make bugbuddy talk to BZ that's fine by me. I've not used it as, when I first saw it, it was set up to talk to Gnome and I didn't think it the right place to report problems in software shipped by RH. Similarly, I've not used KDE's crash hander.
If bugbuddy works (or can be made to work) online and offline, and doesn't require (but can benefit from) a GUI that would be good and should well perform well from the users's POV.
Thats what I would shoot for
søn, 22 01 2006 kl. 19:22 +0530, skrev Rahul Sundaram:
Solution to that problem is fixing the darn client interface like bugbuddy and the messaging system like XMLRPC to gather information from system hardware when bugs are filed. No amount of fiddling bugzilla or any other bug tracking system is likely to help there.
For your enjoyment, the bug-buddy branch mail[1]
Highlights for bug-buddy roadmap: * XML-RPC method for submitting bugs replacing ancient sendmail * Some UI rework * Maybe trying to integrate a new way to submit bug ala liblaunchpad-integration
It seems you might get your wish, pending if(beengoodboy(2005))
- David
[1] http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00047.html
David Nielsen wrote:
søn, 22 01 2006 kl. 19:22 +0530, skrev Rahul Sundaram:
Solution to that problem is fixing the darn client interface like bugbuddy and the messaging system like XMLRPC to gather information from system hardware when bugs are filed. No amount of fiddling bugzilla or any other bug tracking system is likely to help there.
For your enjoyment, the bug-buddy branch mail[1]
Highlights for bug-buddy roadmap:
- XML-RPC method for submitting bugs replacing ancient sendmail
- Some UI rework
- Maybe trying to integrate a new way to submit bug ala liblaunchpad-integration
It seems you might get your wish, pending if(beengoodboy(2005))
- David
[1] http://mail.gnome.org/archives/desktop-devel-list/2006-January/msg00047.html
Oh great but RH bugzilla is "special. I hope bug-buddy can work with it because a client interface like that is what is needed for good bug reporting.
søn, 22 01 2006 kl. 20:17 +0530, skrev Rahul Sundaram:
Oh great but RH bugzilla is "special. I hope bug-buddy can work with it because a client interface like that is what is needed for good bug reporting.
We can't be that special that a small patch to bug-buddy couldn't adjust it to the RH bugzilla.. unless someone invoked the evil bit.
- David
David Nielsen wrote:
søn, 22 01 2006 kl. 20:17 +0530, skrev Rahul Sundaram:
Oh great but RH bugzilla is "special. I hope bug-buddy can work with it because a client interface like that is what is needed for good bug reporting.
We can't be that special that a small patch to bug-buddy couldn't adjust it to the RH bugzilla.. unless someone invoked the evil bit.
- David
Might be. You never know how many evil dudes are lurking around the corner just to crap out bugzilla. /me should stop watching horror movies.
On Thu, 2006-19-01 at 23:52 -0700, Reg Clemens wrote:
I know people work hard on these releases, but some bugs should be obvious...
I downloaded the 5bin cds yesterday, and tried to install it in an extra partition on my disk (3.2GHz Pentium4, 945Gnt Motherboard).
...snip...
Guess Ill wait and give it another try when FC5T3 is available, but this doesnt leave a very good feeling in my stomach... All I wanted to do was see if this release supports the Intel 945 Motherboards (It appears it does), but Im not going to try the support till I can at least install a system. Sigh.
Worked fine the first time on my i945.
-
David Nielsen -
Guy Fraser -
Jef Spaleta -
Jesse Keating -
Jesse Keating -
John Summerfield -
Michael Favia -
Paul F. Johnson -
Peter Jones -
Rahul Sundaram -
Reg Clemens