Mass closing EOL bugs should not close bugs with pending updates

Jaroslav Reznik jreznik at redhat.com
Tue Feb 19 08:52:44 UTC 2013


----- Original Message -----
> On Mon, Feb 18, 2013 at 10:52 PM, Christoph Wickert
> <christoph.wickert at gmail.com> wrote:
> > Despite of the question whether it's right or wrong it's a manual
> > process and we cannot rely it really happens. On the other hand
> > changing
> > the script to not close any bugs which are ON_QA is easy.
> >
> > So what is so bad about ignoring bugs MODIFIED and/or ON_QA bugs?
> 
> This is a corner case perhaps, but those bugs still need closing at
> some point. If an updates-testing package gets un-pushed or never
> gets
> sent to stable the bug will never be closed. 

That's my main concern too. There are more states - I'm on edge even
more - for example for VERIFIED. But looking on how often and how it's
used (outside blocker bugs QA process) - it's again just adding 
complexity and manual fix could be quick (and also pings people to 
take a look on the correct state).

As Adam pointed out - Bugzilla is not a best tool. The script I was
given is neither a state of the art. Definitely it could be 
enhanced - semi-atomic operations to avoid conflicts, more clever
work with BZ states. But more complexity means more BZ resources and
especially in the last times BZ performance sucks (script has a 
sleep after every 10 bugs, still the reporting takes a whole day).
Let me try another thing - at DevConf there are people responsible
for BZ processes - maybe we can find a way how to make the EOL thing
more doable and not destroying BZ experience for everyone ;-)

Jaroslav   


> That means that the
> script would need another rule that it _also_ closes bugs for the
> release before regardless of MODIFIED/ON_QA.
> 
> --
> There are 10 kinds of people in the world: Those who understand
> binary
> and those who don't...
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list