Heads-up: brand new RPM version about to hit rawhide

[Andreas Ericsson]

Kevin Kofler wrote:
> Doug Ledford <dledford <at> redhat.com> writes:
>> First, before I respond to the rest of this, keep in mind that the
>> "overwhelming majority" of packages needs to be quantified.
>> Furthermore, at least one very significant package (the kernel) does not
>> massage files at all between SCM tag and tarball.  And to be honest, I
>> would be very surprised to find many projects that do have any
>> significant difference between a tagged release in the SCM of their
>> choice and their tarballs.  So I would like some examples please, which
>> shouldn't be hard to come up with since it is the "overwhelming
>> majority" of projects that obviously think when they tag something in
>> their SCM it doesn't need to match the tarball they make with the same
>> tag version...
> 
> Many packages don't have a public SCM at all; some have a private SCM, some 
> one-man projects have no SCM at all. (For example, there is _no_ SCM for 
> Quarticurve and Quarticurve-KWin, unless you call fully exploded copies of old 
> versions sitting around on my HDD an "SCM".)
> 
> And even if they use an SCM, they can:
> * make releases without tags: For example, the weekly trunk snapshots of KDE 
> don't get tags, nor do the extragear tarball releases.

I'm not sure if you saw my email regarding the requirements on the SCM for it
to be useful in the scenario Doug Ledford proposes, but right at the top of
the list comes the ability to uniquely name one particular commit. If you
have that, you don't need tags.


> * modify tags: This is particularly common in Subversion which allows using a 
> tag like a branch. KDE normally uses the following workflow:
> 1. tag release
> 2. prerelease tarballs from the tags to packagers
> 3. fix any showstoppers by merging fixes to the tag
> 4. respin tarballs for the modules which were thus fixed
> 5. make the release public
> so the contents of the tag can change between when we first build the package 
> and the public release of the new version.


It would be extremely poor project policy to move a tag after it's made
public, but for those rare occasions when that happens, it shouldn't matter.
The SCM's which have the ability to uniquely name a commit independent of
repository url all set the tag after the fact, linking one tag to one
commit. Since the commit itself can be uniquely identified the name (or
location) of the tag doesn't really matter.
For centralized scms, moving tags doesn't matter in the slightest, since
they can't name a commit uniquely anyway.

What's more interesting though; Fedora can clone whatever repo, importing
it to something sane if it isn't already, and then set tags that you
simply never move.

Me, being mostly a user who also happens to be a programmer, would love
to have an easy way to be able to get a clone of <insert-package-here>,
find the sources corresponding exactly to my version of the package and
then fix whatever issues I have with it. Even if it was just me willing
to do that (which I highly doubt), you'd have a net gain of one extra
spare-time developer. You can't possibly argue that making it easier for
casual developers to get involved is a bad thing.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231