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

[Andreas Ericsson]

Toshio Kuratomi wrote:
> Doug Ledford wrote:
>> This is where I point out that Jesse's email I responded to about the
>> upstream RPM devel cluttering up fedora's devel branch, the one where I
>> said he wasn't imaginative at all in terms of branching, is a perfect
>> example.  Panu mentioned he was pulling the new rpm from the upstream
>> git repo.  We would simply clone that.  In the process, our official
>> repo would have a list of references to the remote, upstream repo's
>> branches.  These branches are inviolate by us.  We can never change
>> them, they simply are a copy of upstream's metadata.  We can, however,
>> create our own branches.  In fact, the standard modus operandi in a case
>> like this would be to clone upstream, then create tracking branches in
>> our repo that show us upstreams branches (because we don't see anything
>> but master from upstream by default), then create our own branches (so
>> upstream has it's own devel branch, usually just named master, and we
>> could create our own branch named fedora-devel that would be our primary
>> devel branch, then as we approach a release we can branch from
>> fedora-devel to f-8, f-9, etc), and then we simply merge or don't merge
>> from upstream to our devel branch as we see fit.  For things where we
>> want to follow upstream, we can actually configure fedora-devel to
>> automatically merge any new changes from upstream's master branch in
>> anytime we do a pull (in fact, you can do this on a per branch basis,
>> any given branch can be told to automatically merge changes from another
>> branch into it, or it can be a more static branch that doesn't auto
>> merge anything).  Had this been the case, then merely setting the
>> fedora-devel branch to not automerge from the remote (upstream) devel
>> branch would have resulted in all of the auto-rebuilds and things like
>> that working just fine on the fedora-devel branch as Jesse mentioned
>> needed to happen, but it would have let us see the changes going on in
>> the remote tracking branches and everyone who bothered to update their
>> rpm repo would see those changes on those remote branches and know
>> something was up.
>>
> You're straying into git specifics here.  Different upstream SCMs will 
> give us different abilities.

There are two categories; Distributed and non-distributed. The most
important part is that which lets you uniquely identify one particular
commit uniquely.

git, hg, bzr and pretty much all the more-than-hardly-used-at-all DSCM's
use SHA1 or something similar to identify a particular commit and also
the history leading up to it. The fact that hg and bzr try to hide them
while git does not doesn't mean they don't exist.

For non-distributed SCM's (svn, cvs) I'd recommend any of the following:
* importing them to whatever dscm happens to be easiest to do all the
  fancy stuff people want to do
* importing tarballs to the dscm that would have been used above
* keep using tarballs and patch-files

> We'll need to figure out what things, like 
> this, are important to us,

In order of priority:
1. Ability to name one specific commit uniquely
2. Ability to generate tarballs from said commit
3. Easy and cheap branching

Only the first two are vital. The third one is for developer convenience
and disk-space saving.

Assuming 2 works properly, you don't never need to change anything in
RPM for this to work. At my day-job, we let our horde of git repositories
schedule builds whenever something is pushed to one of three different
branches (master, maint, next). It does this by generating a tarball
named by the "git describe" output and some very simple sed-hackery.
When a signed tag is pushed to a repository the build result is also
sent to our beta-release repos.

The only pre-processing we do post-checkout is to sed out the version
and release fields with parts of the "git describe" output.

In the spec-file's %build section, we do

sed -i -e "s/##FULL_VERSION##/%{version}-%{release}/" \
	version.{h,php,pl,py,sh,lua,whatever}

so we never need to have any "preparing for release blah blah" commits
cluttering the repository and no package will ever have faulty version
numbers.

I'd be happy to share our stuff. Although it's got quite a lot of stuff
hardcoded into it (paths, server addresses etc) someone interested could
perhaps get some mileage out of looking at them.

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