2008/2/29, Sebastien Bacher <[EMAIL PROTECTED]>: > > Not clear the CD doesn't boot for most users and not easy to change > because it would mean to have access to the hardware of every > configuration concerned
Nobody expects the ubuntu devs to fix all the bugs in a specific kernel version. Off course, it does make sense to use kernel versions that are known to work. So, if there are mission critical (unable to install/random crashes/etc.) type of bugs for a not that small minority it would make sense to default to a proven kernel early on. For hardy, which in every alpha release note, still warns about a simerlar problem, it is already too late to switch back. And you don't have al the hardware of every configuration available. So, this might end up being a release bug. Yikes. > dunno where you are getting your number but it's most likely a very > wrong estimation, sound works correctly on most configurations It was a known bug in Rhythmbox. The workaround was easy: turn volume of rhythmbox to the maximum, or, switch to the crossfade backend. The actual cause has been fixed after the release, but the release did not even enable the workaround by default. So people had to go to launchpad or ask their friends to find out all they had to do was enable the crossfade or keep the volume at the max. Again, nobody is expecting anybody to fix the issue. Resources are limited, etc. But is the amount of effort to default to the crossfade backend, really quantifiable? Those are things which have been coded by upstream and not the ubuntu > team, packaging them didn't take a lot of ressources avoid from bug > fixing, you are speaking to the wrong persons there. And people who have > worked on that most likely did it because that's what they want to do > and would not have worked on other bugs anyway You might be very right about that. But that was exactly my point. There is little interest, even in fixing default configurations. We're not even talking code here. Just a different /etc file or gconf settings. You seem to not undersand how opensource is working, ubuntu is mostly > doing packaging work and bug fixing, shipping code written by other > people is not what prevent fixing all those bugs, the issue is just the > small number of people doing the work and the huge workload there. I _do_ understand. I'm not demanding this works. I just expect the maintainers to either remove it from the default install or add a 'perhaps-not-the-most-perfect' fix that is a single line to a configuration file. Because from where I am standing, the biggest problem of samba being configured wrong is the confusion. People see an interface to enable it, but it doesn't work. Until it actually works, why is this interface even offered? People are going to check their network cables. Spent hours on forums finding the solution. How would you quantify the effort to just remove the .desktop file? Shipping a completely broken piece of software is much worse than not shipping it at all. It decreases the quality of the total desktop. Not to mention the people I support would call me when they want file-sharing, rather than waste their own time unsuccesfully. Now the code is available and you can make a difference and start > contributing and fixing issues too I sincerely doubt it would decrease the workload of the developers. But if you think so, I will provide a patch to change the default smb.conf to use Bad user=guest? Perhaps add a line to the gnome-shared-folders interface as well to add that in. Somebody, I assume the maintainer, will still need to verify what I did. Which combined with downloading my patch and applying seems to take up a lot more time, than just adding the line themselves. But that's just my guess. I will also be more than happy to provide a patch to remove the .desktop file from gnome-shared-folders capplet if the current suggested 'fix' is not perfect enough. (it never seems to be). This way you the .desktop file can be added in about 5 years when the perfect solution arrives. Again, if this would save you guys some time.. sure, i'll do it. But let's get real here. It is a major packaging issue which requires almost zero effort to fix. There could have been a thousands bugs like this fixed in just the time it took to keep arguing with bug-reporters and commenters. But the mentality often seems to be either 'we-dont-care' .. 'we-want-a-perfect-solution-and-until-then-prefer-to-keep-it-completely-broken'. Black or white. Aim too low or aim too high? It are just truly packaging issues I am referring to. Ship a version of the kernel known to have few issues. Ship those configuration interfaces that actually work. Set the default configuration of programs so that they do not crash the least amount of systems. When you get a fix that fixes it for 90% of the people, please apply the fix until a better one arrives. (esspecially when it is killing hard-drives) And i'm just talking about packages in main. The universe seems much better maintained actually. Weird, huh? Anyways, no hard feeling, but i do not feel sorry discussing what and how these frustrations build up and what could possible be done to fix them with other bug-commenters. And it isn't as simple as just using more hands. I wish it was though. I truly wish it was that simple. Perhaps if more packages are moved to universe? Take you for example. You are being paid to single-handedly take care of all the gnome-packages. That seems an absurd amount of work to me. Esspecially because you have to be in know about all those packages. The universe might have a higher packages-per-maintainer ratio, but the persons in question are free to deal with those packages they are in the know about. -- > the security parameter must be set to share, not user, in smb.conf - > Smb/Gnome sharing broken > https://bugs.launchpad.net/bugs/32067 > You received this bug notification because you are a direct subscriber > of the bug. > -- the security parameter must be set to share, not user, in smb.conf - Smb/Gnome sharing broken https://bugs.launchpad.net/bugs/32067 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs