On Thu, May 15, 2003 at 10:28:48PM -0400, Matt Zimmerman wrote: > On Fri, May 16, 2003 at 10:40:10AM +1000, Anthony Towns wrote: > > On Thu, May 15, 2003 at 10:06:47AM -0400, Matt Zimmerman wrote: > > > There's that "we" again. Why not unstable, too? > > I'd have no problem with that. > You don't seem to have any problem suggesting that other people do more > work.
I don't have a problem helping other people do the work either. I'm also happy for them not to do the work; what I don't like is them then complaining about it, or, worse, obstructing others from doing it. > > So automate it more. Throw more people at it. Distribute it more. You've > > currently got five people on the security team, at least three of which > > are splitting their time between that and other fairly major Debian > > projects; it is, afaik, almost impossible for non-security team members to > > either know which DSA's are outstanding, let alone to help in preparing > > any of them; and there should be plenty of room to get decent benefits > > from improving the security system setup -- we went from being overloaded > > at one suite with six architectures and some 2600 packages pre-woody, to > > managing two suites, eleven architectures and 5200 packages today. > Outstanding DSA's are not the matter at hand; Sure they are: if you're complaining that the security team already has too much work to do, then it's outstanding DSAs that are exactly the problem. If there aren't any outstanding DSAs, then it'd seem like now would be the right time to see about doing a *better* job, rather than just the same old one. > the bugs being discussed have > been public for a long time, hence the fuss about testing. Yes. Duh. There have been various packages with security problems in testing *ever since it's existed*. It's not news. Testing works that way because it's simply not possible to get packages from unstable into testing the same day they're uploaded, or anything approaching that. The solution isn't to go into some bizarre reality denying mode and pretend otherwise, it's to do *the exact same thing we already do for stable*. > You suggest distributing the workload, and your concrete suggestions are > exactly the opposite of that. You want this to be the security team's > responsibility, while I'm saying to let maintainers (and anyone else) handle > it. You realise it's possible to add people to the security team, right? Or to let them upload to the security archive without adding them to the security team? You also realise that anyone "handling" this is *by definition* part of the security team, whether they're on the team@ alias or not? > > > No, it is not at all the same as stable. The problem that is being > > > discussed in this thread is the presence of known, publicized security > > > holes in testing. > > Mmm. And are you really wondering why nothing's being done about it when > > the Debian Security Team passively obstruct it every time it's brought up? > "Passively obstruct"? Is that what it is when someone declines to take on > additional work that is arbitrarily assigned to them? No, it's when someone refuses to accept even the possibility of the work being worthwhile, publically claims it's not possible, and resists anyone else who might want to help using the existing infrastructure that's been set up. > > Why not invite them to upload to `testing-security' on > > security.debian.org, exactly? You know, so that we can get security > > updates for testing on the day they're made public, rather than a few > > days afterwards once the maintainer works out what's going on? > You know, because testing-security must be processed by the security team, > and that just gets in the way of maintainers who want to fix bugs. So add some people to the security team. > Why > don't they upload them to testing-proposed-updates instead? You have said > that it works and all known technical issues have been addressed. Just give > maintainers the power they want. Yes, and funnily enough, uploads to -p-u have to be processed by the release manager, either Joey for stable, or me for testing. How's the phrase go? "You suggest distributing the workload, and your concrete suggestions are exactly the opposite of that." Again, the security architecture is there for a reason: it's so we have a quick, effective way to get security updates out and so we can prepare security updates before they've been publically announced. testing-proposed-updates simply does not manage either of those things, just as stable-proposed-updates doesn't. Yes, it's possible to do security updates via t-p-u; it's absolutely no easier to do it that way than via testing-security, and less effective. > > So, you're contending that "testing" hasn't been made public? Or you're > > contending that people regularly upload development versions of packages > > to testing? Or are you contending that there's a line somewhere between > > annual updates and daily updates that makes security support unnecessary? > No, I'm contending that testing is in development. Are you contending that the stable Debian release *isn't* in development? I'm pretty sure that the OpenOffice.org guys are working on some stuff to be included in the next stable release. > It's a daily snapshot. That's certainly true. Do you contend that it's impossible to have a daily release schedule? How about hourly? Weekly? Monthly? Every two months? Six? > It doesn't make any sense to release patches and security advisories for a > snapshot which will be overwritten in the near future. "refuses to accept even the possibility of the work being worthwhile". Security advisories, patches, and fixes are worthwhile whenever someone's running software that has a security problem. It might not be possible, or feasible, in all circumstances, but it's always worthwhile. Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!''
pgpmVl6XKDMTC.pgp
Description: PGP signature
