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@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
