Le lundi 12 novembre 2007 à 14:19 -0600, Les Mikesell a écrit : > Nicolas Mailhot wrote: > > Ironically Fedora cvs is one exception and that's only because koji will > > only build stuff when given a tag number, and generally speaking we have > > anal brutal dumb SCM procedures that force everyone to behave. > > Yes, I've always considered the ability to reference things by tag name > only and have it give consistent results to be almost the whole point of > using the SCM, at least on the testing/release side of things. Well, that's the theory, in practice what's tested is the tarball that's given to QA (internal QA in proprietary world, internet QA for FLOSS). Unless projects have totally automated the SCM to tarball step, and have very strong discipline that forbids massaging the tarball in something suitable instead of fixing stuff in the SCM then re-starting the lengthy automated export when small stuff is broken, SCM tag is only a release approximation. And when projects break up, or fold, the only part remaining (that can still be packaged years later) are the tarballs that were mirrored on code repository sites. What developers "test" are SCM dumps build in an environment which has usually little in common with the one production entities like Fedora uses. Which does not mean developer testing is useless, just what you're used to with direct SCM access and what Fedora does at packaging time are two different things. One workflow emphasises re-build speed at the expense of perfect reliability or reproducibility. The other emphasises reliability and reproducibility at the expense of speed. You usually need some time in a support/sysadmin position managing systems built by developers from SCM dumps (or god forbid production systems directly re-build from developer SCM-plugged RAD IDE environments) to appreciate the difference. The developer just wants direct access so he can quickly inject code fixes in case of bugs. The sysadmin wants to nail the damn thing down. It does not matter if there are bugs as long as they're known bugs and he can organise himself so users do not call for help in the middle of the night (when developers sleep). The organic uncontrolled continuously evolving system developers typically dream of is his worst nightmare. rpm is designed to protect the sysadmin, and help him nail down developer code dumps. It limits what's needed to be trusted from developer systems to the bare minimum (release archive plus standalone patches) and enforces a process where changes are evolutionary and small. And this is good. It's a beautiful design. Much better than every system I've seen that tried the direct SCM-to-binary approach, and where developer happiness was achieved at the expense of everyone else in the ecosystem. rpm formalism is an annoyance just like unix permissions are an annoyance. Remove them and everything quickly spins out of control. -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
