Nicolas Mailhot wrote:
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.
The key to making it work is to make the tag name the only thing that
can pass between the developer, the QA approver and the release deployer
so they all have to be using the same thing. That can be arranged by
mandate from the right person in a proprietary environment - but the
best you'll probably do with internet development is to glue a bug
tracker to the revision number.
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.
Couldn't that be equally true of distributed SCMs?
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.
I do know the difference - a company where I worked for years had one
group that was religious about deployment builds being based strictly on
tags and the SCM containing everything necessary for the build and
another that did a lot of hand tweaking and could only do the build on
one machine that nobody remembered how to reconstruct. A patient QA
dept. was the only thing that let the latter group survive.
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.
An SCM-to-binary mechanism that only deployed QA-tagged versions should
be indistinguishable from ones that nail released content in other ways.
You seem to be equating QA/testing with a deployment mechanism which is
just coincidental.
rpm formalism is an annoyance just like unix permissions are an
annoyance. Remove them and everything quickly spins out of control.
But RPM is barely enough and only works in a forward direction. Maybe
the place to really take advantage of SCM features would be to let one
manage the installed package lists as part of the OS functionality, and
teach yum to go backwards or forwards so you would have a way to
duplicate another machine's installed state or a prior one.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
