Marcus Meissner wrote:
It just helps to be insistent. And if there is no reaction, just bring
it up on this list.
Personally, I have found that defects that I report on bugzilla tend to
disappear into the void and are never acted on and sometimes with little
to no response.
I hardly expect developers to dedicate themselves to every problem that
arises, but something a bit more than a token response would be appreciated.
For instance refer to the following bug regarding the ivtv driver which
was reported on during the 10.1 beta cycle.
The problem was reported during the development of 10.1 and still hasn't
had a real response from the development team. Even a *Won't Fix* would
be an acceptable response, but all pings and questions for the last year
have disappeared into the void.
These days I don't even see an ivtv package in the factory distribution,
but no comments to this effect in bugzilla...
Other bugs report the same problem, also with no conclusion
Maybe a post release bug cleanup activity could help here and in similar
instances? Perhaps 2-3 months after a release the developers and
community could be organized into a one day bug review of the
outstanding bugs for the release and evaluate/assign them properly.
For instance I currently see the following:
251 Open bugs for 10.0
683 Open bugs for 10.1
1224 Open bugs for 10.2
Wouldn't it be useful to review all those open bugs from the more recent
releases and see if they should be updated to reflect the state of
either the current release (10.2) or the factory (10.3), or possibly
close them if they represent problems that are negligible in recent
Surely the combined effort between the developers and community over the
course of a day or two could clean out the bug lists and identify tasks
that should genuinely be targeted for fixes.
Personally I would be willing to schedule a day or two toward such an
activity that I think would improve the quality of defect management in
I think that the Mozilla lightning/calendar project has the right idea
with scheduled community/developer test days.
Theodore Bullock, tbullock(a)canada.com
Software Engineering Student, University of Calgary
GPG Fingerprint = 3B8E 8B0E D296 AACB 7BE2 24F2 1006 B7BE C8AC 5109
To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org