Mass closing EOL bugs should not close bugs with pending updates

John5342 john5342 at gmail.com
Wed Feb 20 00:13:04 UTC 2013


On Tue, Feb 19, 2013 at 2:26 PM, Christoph Wickert
<christoph.wickert at gmail.com> wrote:
> Am Montag, den 18.02.2013, 23:34 +0000 schrieb John5342:
>> 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.
>
> Maybe it is a corner case, but what you describe is a corner case of the
> corner case. How many updates get actually withdrawn? 1%, 2%, 5%?

My point is not that this specific corner case should prevent
improving the script. Merely that there are negatives (there are
others corner cases too) that make things more complicated than just
ignoring a status.

Considering the number of (or lack of) people who have complained, i
get the impression none of these things are actually a wide spread
problem and very quickly the effort and fragility or clever scripts to
cover all cases becomes more of a hassle than a benefit.

>> That means that the
>> script would need another rule that it _also_ closes bugs for the
>> release before regardless of MODIFIED/ON_QA.
>
> That's what it does already, no further rule needed.

I haven't looked at the script but further up the thread showed
version == 16 rather than version =< 16. The script would have
conceptually have to change from (version =< EOL_Version) to
(((version == EOL_Version) && (status != MODIFIED) && (status !=
ON_QA)) || (version < EOL_Version)). That's already 4 times as long.
Then i am sure there are other corner cases too.

This could be simplified even further by blocking creating new bugs
for EOL releases at the appropriate time but then closing the old bugs
after a grace period (e.g. 1 month). This would solve the vast
majority of these cases like the one that started this thread and the
minute fraction of people who are still affected by the mass closing
can just change the release or reopen.

No matter anyway. I am not significantly affected by any of this. Nor
am i one of the people who can solve it so, whatever.


More information about the devel mailing list