On Tue, Feb 19, 2013 at 2:26 PM, Christoph Wickert <christoph.wickert@xxxxxxxxx> 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@xxxxxxxxx> 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
