Le lundi 30 octobre 2006 à 20:02 +0100, Michael Schwendt a écrit : > On Mon, 30 Oct 2006 19:00:46 +0100, Nicolas Mailhot wrote: > > > Le lundi 30 octobre 2006 à 16:18 +0100, Michael Schwendt a écrit : > > > > > There is a simple solution: --> All or nothing. <-- > > > > > > [...] > > > > > > Don't build pieces of a package-set just because they are approved > > > already. Keep all dependencies in FE-ACCEPT state until the other packages > > > in FE-REVIEW are approved, too. > > > > It's simple but stupid. > > Great choice of language here. Either you have misunderstood me or you are > out on a mission to insult other people. Or both. I'll admit to being in a foul mood, part of which being caused by yet another message trying to 'fix' the non-broken part of last week's conflict, and that after a lot of people tried very hard not to feed the flames by keeping quiet. > > 1. The dependencies won't conflict less when released later, you're only > > maximizing the pain by releasing packages which never had exposure > > separately. > > No, far from it. And there is nothing like "maximizing pain". You only try > to play with words. No I don't. When you release twenty conflicting packages at once instead of releasing them as they are approved you are maximizing pain. There's a reason for the "release early, release often" rule. After a certain amount of changes forks just become entrenched because it's so many things to change at once before merging with mainline. > Actually, in the majority of cases it is impossible to review individual > pieces of a dependency-chain without taking a look at the entire set of > packages. Integration is good but package sanity is more tricky. If pieces of something are released separately that does mean maybe 80 to 90% of the packaging can be reviewed separately. Also the best test for integration is to release parts of a dependency chains and get feedback on how these parts are integrated by other entities (end-users, 3rd-party repositories, etc). > > 2. You're needlessly maximising bureaucratic inertia. > > Where? Packagers already complain the process takes too long. Have packagers wait for the last of a dependency set to be approved before releasing means we'll have even more dropouts before the review ends. > > Dependencies often > > have worth by themselves, either for other FE packages or for people > > running unpackaged stuff in the wild. > > You say "stupid", I say "nonsense". 1. Take any system running an unpackaged app (don't pretend no such thing exists) 2. Strip it of all the packaged components the app uses and force its admin to install them separately (no problem since you maintain the packaged deps have no value to the sysadmin) 3. If the sysadmin let you live, come back to report. > > For example a few years ago I > > packaged most amavisd-new deps which certainly helped when amavisd-new > > was packaged by someone else. Your rule would have forced the > > amavisd-new packager to start from scratch. > > No. Please re-read and try again. Please look at the amavisd-new ecosystem release timeline and come back. The full process took months if not years. I would *not* be maintaining part of the amavisd dependencies today if I had been forced to wait for amavisd-new approval before release. > > 3. You're rewarding the people who don't get their packages reviewed and > > penalise people who follow the appropriate process. > > No. This comment is beyond my comprehension. Sounds like FUD. > Try again. Any time you make the FE release process longer and more difficult you just prove right the people who insist it's too hard and you can't blame them for setting their own 3rd-party repositories. Approved is approved. *IF* you're reviewing all the packages in a packageset *AND* you feel you need the big picture you should not approve them separately. Now if a reviewer feels he can OK one bit of a packageset separately, one should not invoke "packageset veto" to block him. -- Nicolas Mailhot -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
