Hi, Salvatore Bonaccorso wrote: > One one side we loose though some accuracy/detail view if we don't > have it since there are fixed we release through security which are > not (yet) included into a (old)stable point release (e.g. openjdk-7).
But the tracking of those broken updates can still be done via https://release.debian.org/proposed-updates/stable.html https://release.debian.org/proposed-updates/oldstable.html True, some updates might be missing on fringe archs, but that's really up to fix fpr the (typically inactive) porters of those archs and shouldn't clutter the view for the 99.99 % remaining users. > If this though makes the fix easier, I guess you can go ahead and > don't make the distinction anymore and just consider it fixed in > $codename once it is fixed "somewhere" in $codename. It'd say it's fixed in codename once it's fixed in "codename-security or codename". > If I understand the approach correctly, this mean we could as well add > the fixed versions through (o)s-pu directly to the data/CVE/list once > accepted by the stable release managers instead of keeping them in > separate list data/next-(oldstable-)point-update.txt and merge it at > point release time? I don't think anything would change wrt spu/ospu? People don't have spu in their apt sources, so a fix is really only visible to them once it has moved into stable proper. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-security-tracker-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150525130048.ga30...@inutil.org
