----- "Pierre Habouzit" <madco...@debian.org> wrote: > I disagree. What would be 3:1 (to date) is to decide that such bugs > aren't RC. The funding documents don't enforce the release team to > release without a single known DFSG-related issue, unless I'm deeply > mistaken. A $suite-ignore tag is _NOT_ the same as downgrading the > severity of a bug. It's acknowledging it's a serious issue, but that we > shall not wait for it to be solved to release. > > I don't say that DFSG freeness is a secondary issue. What I'm saying is > that when: > * we see DFSG freeness issue that need quite a long time to resolve > properly and would else delay the release too much, > * there is no sign of foul play from the maintainer (IOW those bugs > have not been sneaked into testing, but have just been detected > after the migration to testing), > Then I fail to see why deciding to release with such bugs needs a 3:1 > vote. It's merely pragmatism.
Well. I do agree with you here. Doing a "release" is essentially just bookmarking the state of the archive at a point in time where we consider it to be stable. From a DFSG violation perspective the real culprit is the uploading of the problem software, not the bookmarking of the release that includes it. Obviously, we could be distributing non-free from testing main for a year if we are waiting for a release as the event to clean it out. From this perspective, I agree with you. The release team declaring that a release state has been reached does seem orthogonal to the DFSG violation problem, especially as long as the release team is working with the rest of the project to clear problem softwares. I still disagree strongly with declaring firmware to be source but I agree on the notion that marking a release ready state is a separate matter. -- Ean Schuessler, CTO Brainfood.com e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
