Let's ignore things earlier than 11.0, since I can't tell anything about this.
We can do that. But what happened before 11.0 is what led to the current situation of GNOME not being much appreciated in openSUSE.
Yast-gtk in 11.0: I saw you referenced a crash in the printer stuff. I never heard of this. I'm not saying I would have fixed it, but the fact that I don't know about it probably also means that other people don't know about it, which can help explain why it wasn't fixed in time. (see my reply below about the list of things to fix, btw)
It was reported by me immediately after release. My point is that no one tried to configure a printer with that module, because the crash is systematic.
PulseAudio: as Rodrigo pointed out, the issues are mostly related to the fact that it's not used by everything in openSUSE. You then reply that it might have meant that it wasn't ready. My perception is that other people didn't think it'd be useful to replace something that work for them because they didn't see an big enough immediate benefit and convincing them was really hard. I believe PA might get used by KDE too in 11.1 (not sure, though), which will tremendously help. Maybe we should have waited, but I would guess that if we had waited, we'd be in the same situation for 11.1, and we'd need to convince people to use it.
I agree when you say that a lot of people (me included) do not really see the advantage of PulseAudio right now. It just made users life harder, giving them a lot of problems with their audio system and introducing trouble with applications that do not support it. I disagree on the fact that you say now you'll be able to convince the KDE guys to use it more easily, after all the complaints received in #suse. If I were a KDE developer, I would really keep it out of my system, at least until all the third party apps (yes, I'm talking also about commercial stuff, like Skype, because we need it!) do not support it properly or the compatibility layer works out of the box without requiring "magic" solutions.
PackageKit: I'm not aware of major bugs there, but I must admit I mainly use zypper ;-) From what I can tell, though, this is more or less under control, although it was probably ready a bit too late. But then maybe having people help Scott would have helped too. And this means we need more people helping (see below too).
PackageKit is not creating any major issue. It is just an example of something added because it's "cool". The only advantage I see is that now GNOME has a nice updater instead of the ugly opensuse-updater-gnome. But this introduced a sort of inconsistency in the system, with yast on one side, and packagekit interfaces on the other.
Tasque: err. I'd hardly qualify this like a big problem since people have to look for it to use it, don't they?
Tasque is a perfect example of the principle of how things are done, at least for me, because it was introduced to replace the "to do" feature in tomboy, instead of fixing it. This means that who was using that feature, lost it while upgrading (yes, I was using it). Nice policy!
Plus, it is not a full replacement for the old feature in tomboy at all, because in the current state it requires a Remember The Milk account. To answer your question, Tasque made it on the box, as one of the key innovations of 11.0. It really seems too much to me for an application that doesn't even recognize that the RTM account was closed, and goes on sending data somewhere over the net (bug in bugzilla).
[skipping performance stuff]
Hehe, I hope someone won't skip it ;-)
I can understand why you see it as bureaucratic but the reason really is that we want to have outside people know what's going on and we also want to enable them to contribute. Maybe not with code or packaging, but with decisions or testing. Having more people can only help us. The bureaucratic look of all this is "only" a side-effect of being proactive in community building.
Yes, I think I explained I was too general in that comment. What I think is that having a lot of different sources of information makes it harder for the user/contributor to follow them and find what he needs. That's all.
About the creation of a community, I strongly believe that it is a question of trust before anything else, and creating it requires a lot of time and work. I can say, without any pun intended, that it didn't work for me, because I had too many times the sensation the community is considered something to "use" more than someone to "work with". Of course it is a personal experience, so take it for what it is.
As for my proposal: as a developer, this would *hugely* help me. Yes, I have bugs in bugzilla and they're now prioritized in a good way. But you know what? I don't look at bugs of other people. Having a small mail from time to time would help me know what are the big issues. Maybe I would be able to help with an urgent issue I'm not aware of. Now, I'm talking only about me, but if other people are in the same situation as I am, this means maybe many people could help if they were aware of the issues. And it's also a good way to put a bit more pressure, without annoying the person who's assigned to the bug :-) (maybe it would only help me, though, in which case all this can safely be ignored)
Well, I spent quite a bit of my time preparing bug lists (maybe in the wrong way, and surely of the bugs affecting me) for all the 10.1, 10.2 and 10.3 releases, without much success (read: almost none of the bugs were fixed timely). That's why I answered as I did.
I agree. That is the updates policy inherited by the SuSE, where "only security updates" were provided. I see the advantages: safer and only required updates, but I also see the disadvantages we are experiencing. I wonder if this approach is the best one for a community distribution, where maybe a little bit more flexibility would be of help.
I would agree, but discussion about this probably belongs to opensuse-project :-)
Yes. And I don't think it's a policy that is going to change anytime soon. That's why I think that the quality of the release is so important. Fixing after the final release is harder, and in openSUSE particularly slow, and in all cases, it doesn't really give a good picture. Again 11.0 was a big step forward, but the goal is not achieved, IMHO, until the final release is without bugs like the yast one cited above, or without the calculator hang. You might thing they're details, especially in an open distribution, but details are what makes the difference!