Ahh, yeah, you're right. I tend to make it a habit of adding the task for that release and marking the bug otherwise for the latest release and leave the task for monitoring it for the affected release, which is why I observe things as such.
Otherwise, bugs don't get touched if they don't have the task, you're right. (My fault on the miscommunication) *Sent from my iPhone. Please excuse any typos, as they are likely to happen by accident.* > On Jul 19, 2014, at 14:25, Brian Murray <br...@ubuntu.com> wrote: > >> On Sat, Jul 19, 2014 at 12:27:51PM -0400, Thomas Ward wrote: >> Actually a good portion of "End of Life" bugs are typically cleaned up >> on an automated process, last I checked. I believe there's an >> automatic script that runs for some of the packages by people on the >> Security team and other teams, but I do not know the extent of those >> that get covered. >> >> From observations, EOL release targeted bugs go to "Won't Fix", if >> they've targeted it to the specific EOL release, and "Incomplete" if >> you're waiting on confirmation of the bug existing in a later release >> than the EOL one. There are a few special case bugs I watch in nginx, >> for example, where that second criterion is matched. >> >> (I may be wrong, as this is just built from my observations on EOL-release >> bugs.) > > I believe you are confusing bug tasks targeted to an End of Life release > and the generic bug task for the package which by default applies to the > current release. > > -- > Brian Murray > Ubuntu Bug Master -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
