On Mon, Nov 22, 2004 at 01:05:00PM +0200, Riku Voipio wrote: > > In that case, you should be using the control files to prevent mixed > > installs. If users can install packages in some combination that won't > > work; the Depends/Recommends/Provides/Conflicts fields should be used to > > tell them of that in advance. That's what they're for. > I agree. In this way, the kde packages have allways been broken. We > have been so far reluctant to enforce all of kde being the same version, > since it would seem make testing maigration even harder - Ie. every > kde release would need to be hinted all packages at once, which wouldn't > certainly help the "make kde safe to trickle in" -requirement. Speaking for the release team, we'd much rather do extra legwork to coordinate KDE pushes to testing, if that's what's called for, than be put on the spot and have to do damage control when part of KDE slips into sarge before the rest is ready. The latter is a huge step backwards on the "testing should always be in a releasable state" scale, and is stressful and irritating for users and developers alike -- and that doesn't even begin to address the question of users being able to break their system via partial upgrades between stable releases (or within testing). Another reason why Adeodato's "pick a date and push it" suggestion doesn't work is that package relationships are our safety net in britney to catch last-minute problems that no human notices in time. I'm perfectly happy to do the hinting necessary to get all of KDE 3.3 into testing in *one* day when the time comes, but I'd also much rather have nothing make it in on a given day than for things to be broken because only half the expected packages made it in due to a surprise RC bug filed 15 minutes before britney kicked off. > If you and the Release maintainers believe, that this in issue that > must be solved for kde3.3 to enter sarge (despite the fact that > kde 3.2 is sarge suffers from the same problem), we sould > probably need to reupload most kde packages, which on the other hand > will not make it in the time for sarge :-/ Which is kinda demotivating, > since almost every kde package is valid candinate at the moment.. Well, I'm sorry if this comes as a surprise to you; I've discussed this privately with two members of the KDE team before now, and I guess I assumed they would involve other maintainers as necessary to make it happen. FWIW, preliminary feedback from Ben Burton regarding plugin APIs suggests to me that we're a far cry from needing new uploads of most kde packages, but upgrade testing is the only sure way to know. Also, any existing partial upgrade issues with KDE 3.2 are deplorable, but I don't think they should be RC; the real reason for insisting on getting package relationships squared away before letting 3.3 into sarge is so we don't get caught trading one painful release blocker (testing-security queues) for another (half of KDE 3.3 in testing and broken, and the other half broken in ways that keep it out). I don't think the community would thank any of us if we had to send out a release update announcing *that* state of affairs. ;) -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature