Hello there,
The Cyrus Bugzilla is a very important component for all of us, community
users and Cyrus developers alike!
I suppose most of us have, at least once or twice, logged a new report in
Bugzilla, but then what happens with that report?
From the other side, the Cyrus team sometimes doe
On 12 Oct 2010, at 13:57, Henrique de Moraes Holschuh wrote:
> Well, I've seen in some other projects information get lost because of
> mass cleanups where there was not an effort to "unshelf" still important
> bugs. This is stuff that has been left idle for a long time because
> they were not pur
On Tue, 12 Oct 2010, Jeroen van Meeuwen (Kolab Systems) wrote:
> Should there be any bugs that obviously still apply to the current code, then
> for the 2.1 series, these bugs have apparently been idle for about 5 years,
> without proper follow-up from either side.
Yeah. Such as locking bugs.
Henrique de Moraes Holschuh wrote:
> On Tue, 12 Oct 2010, Jeroen van Meeuwen (Kolab Systems) wrote:
> > 2) Close the bugs that are not RESOLVED or CLOSED by mass-updating them,
> > providing some text saying that either the bug must be reproducible in a
> > currently supported version, or the repor
On Tue, 12 Oct 2010, Jeroen van Meeuwen (Kolab Systems) wrote:
> 2) Close the bugs that are not RESOLVED or CLOSED by mass-updating them,
> providing some text saying that either the bug must be reproducible in a
> currently supported version, or the reporter somehow proves to us its
> commitmen
Hi there,
I have formulated a plan of attack for a big bugzilla cleanup!
There may be a couple of assumptions in here, so please bear with me;
= Expired/obsolete/unsupported legacy versions =
As you can see right now in logging a new bug, the list of versions you can
log a bug against lists a