Hello, Am Donnerstag, 26. April 2012 schrieb Jos Poortvliet:
On Wednesday 25 April 2012 16:09:24 Carlos E. R. wrote:
Do you mean that we have to report all issues in Bugzilla, without asking first here our peers whether it is a read bug?
Basically, I think it is something like this: - if an experienced tester (user or developer) who is capable of determining the root cause mails here and helps dig out the issue and test possible solutions, it's appreciated
Yes, of course, but that also works inside bugzilla (or even as SR ;-) and I tend to use bugzilla (or a SR) in such cases.
- if an unexperienced newby asks about an issue he/she has, it costs a lot of time but the devs are often nice enough to work with him/her. - if hundreds of such newbies would show up we couldn't work anymore.
That's what is called a luxury problem ;-) Let me add another "basically" section ;-) If something is clearly a bug, go to bugzilla without asking on the mailinglist. Some examples: - a program crashes (and you have a reproducer) - you find a syntax error in an out-of-the-box^Wrpm config file - changed defaults that are a very bad idea (invented example: "kill $$" in /etc/bash.bashrc) OTOH, there are things that can or even should be discussed. Some examples: - an issue/change where you are unsure if it is a bug or intentional - a program crashes _sometimes_ but you have no idea why it crashes and hope other people have a similar problem. - a changed default that is "only" annoying for your usecase Basically you can sum that up to the question Do we need to discuss that or should it just be fixed?
Bugzilla is overpowered, I have issues without attention for years.
In theory, yes, all issues probably should go via bugzilla. In practice, I know we don't work like that and that's why I said its worth discussing. We need to think about how we want to work.
What about "force developers to read bugzilla mails/work on their buglist regularly"? ;-) Bugreports getting dusty is a real problem, and I'd love to present a nostrum how to fix that if I had one. My personal solution is to sort the buglist by last modification date - having recently changed bugs on top helps to get fast response times. I'm doing this with bugs where I'm involved (as assignee, reporter or in CC), and it works. Yes, I'm aware that most developers have more bugs assigned than I have with a handful of packages ;-) - nevertheless it might be worth a try.
There are some possible ways out of this. For example: === testers hang out on a separate list, discuss problems and help each other find the root cause and filter out non-bugs.
Are you talking about the opensuse-testing mailinglist? ;-) (at the moment, you could also call it testing-team-announce without changing the ML content) One problem is that a mailinglist won't work too good if you have only testers there and no developers - similar to why a newbies-only mailinglist can't work ;-)
'real' bugs are then brought to the developers via either bugzilla (? with a special "verified" flag?)
You can already do that today - add a note "bug seen by at least 10 users, see discussion in $mailinglist at $url".
or directly to the factory ML via a few 'gatekeepers'. ===
Which brings up the question who wants to do the gatekeeper "job". I'd expect it will be quite boring...
It is a rather formalized solution, not really in openSUSE spirit, but it is something which scales far better than our current solution ^^^^^^^^^^^^^^^^^ Except if you are one of the gatekeepers ;-) (In other words: I doubt this will work.)
(all on this list). We, as a project, are growing, and this list will become more and more crowded.
I remember the opensuse-de mailinglist had up to 200 mails per day (it was called suse-linux back then, but that doesn't really matter). And the mailinglist worked quite well with this amount of mails. opensuse-factory has an average of 17 mails per day[1], and this already includes at least one flamewar week ;-) I remember [2] In other words: the amount of mails in opensuse-factory isn't a problem at the moment IMHO. The only thing I propose is to take flamewars to another mailinglist - but unfortunately I don't know how we can enforce that ;-) Regards, Christian Boltz [1] around 2000 mails in 2012 until now [2] no, I won't mention the topic - but I'll use a non-random sig that might help to avoid flamewars - at least if you understand german ;-) --
[vim] Um einem Editor-War vorzubeugen: mit Emacs, Kate, nedit und mcedit kann man auch HTML-Dateien erstellen. Und auch mit allen anderen Editoren, die ich an dieser Stelle nicht genannt habe ;-) Du wirst ja immer unfreundlicher ;-))) Womit sollen wir uns denn das lange Wochenende vergnuegen. So ein richtig schoener flame-war, das waere doch wieder einmal was :-) [> Christian Boltz und Heinz W. Pahlke in suse-linux]
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org