reflecting on 4.10

[Jekyll Wu]

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