Jesse Keating wrote:
> If I had my way and did it today, git. Each package would be its own
> module, and each fedora release would be represented by a real branch in
> the git module. We'd have a userland tool, as part of fedora-packager,
> that would allow simple commands to clone the module (and get master,
> which would build things for rawhide), or clone the module and all its
> release branches and construct a directory layout much like dist-cvs is
> today.
>
> Build commands would be part of fedora-packager, not makefiles in every
> module. Decisions on where to build the package would be based on what
> branch is being built from, programatically so that we don't have to
> keep updating some file somewhere to figure it out. Maintainers would
> not tag themselves, as the buildsystem would build from git hashsums,
> and only successful builds would have a human readable tag applied to a
> given hashsum, and that would be done by the build system. There would
> be no need to translate %dist values on the local user's system.
>
> That's what I got so far, I'm hoping to walk through a typical scenario
> with folks at FUDCon to see how well my plan stands up.
And why can't all this be done with s/git/SVN/? All we really need apart
from what CVS already provides is atomic commit IDs, to make the
"maintainers would not tag themselves" part easily implementable. I don't
see why SVN revision IDs wouldn't be as good as git hashsums for that.
In fact, in principle, it could even be done with CVS, but instead of
tagging a single revision ID, the build system would have to tag the
revision ID it checked out for each file. Having atomic commits just allows
dragging around just one revision ID instead of a set of IDs.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
