On 2013年01月12日 00:26, Marco Martin wrote:
maybe what we actually need is someone with a wide enough knowledge of the
codebase, that continuously uses master and tests, poking people when
regressions happen? (especially in areas far from what one usually works in,
since for own area "proximity blindness" can happen) this kindof happens
already, but there isn't anythng "formal "about it
Hi
If there is such an (plasma) master available, I think he/she should
probably better spend time on development, instead of on "poking others".
Don't get me wrong. I'm not implying that quality assurance is not
important. I just feel it is the wrong way to improve quality to expect
some master to notice the problem and then poke you. That doesn't scale.
It might work in a short time, but I bet it will fail in the long term.
Actually, I would say that the quality team has done quite well in
organizing tests and encouraging/helping users to do it. And my
observation (Hint: I am subscribed to kde-bugs-dist@) is users do notice
and report many valid regressions very early and quickly. But the
problem is the *connection* between plasma team and bugs.kde.org is not
good enough.
That is again an old topic, I think. Ever since I got my developer
account, I have always noticed and seen the plasma product on
bugs.kde.org as a big monster. I have the habit of visiting
https://bugs.kde.org/weekly-bug-summary.cgi?tops=70&days=7, and I know
plasma always has the desire of becoming rank #1 :)
I know plasma is one big project. But beside that, probably the
co-maintaining model contributes to the bad connection with
bugs.kde.org. If I know the project is co-maintained by many developers,
I probably will take bugs.kde.org less seriously and expect others to
take care of it. Not to blame, but how many plasma developers are
watching plasma-bugs@ ? I ask that because I don't notice(hint again,
I'm subscribed to kde-bugs-dist@) many plasma developers are dealing
with incoming bug reports in a regular and timely way.
And here is another problem: plasma-bugs@ means high traffic, because
that is the only dummy address for the plasma product. So either you
watch plasma-bugs@ and receive many (uninterested) bug reports, or don't
watch it and receive no bug reports at all. What if I'm only interested
with three components which are currently assigned to plasma-bugs@ ?
There is no plasma-kickoff-bugs@, plasma-taskbar-bugs@,
plasma-pager-bugs@, plasma-battery-bugs@, etc .
Again, I don't intend to blame. I only want to raise the problem with
bugs.kde.org again and see whether this time some methods (like creating
more dummy addresses) can be found and agreed to improve the connection
with bugs.kde.org.
Regards
Jekyll
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
