[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#723175: [SoB osgearth] Vcs is not up to date

Hi Bas,

On Wed, Sep 18, 2013 at 03:59:22PM +0200, Sebastiaan Couwenberg wrote:
> > On Wed, Sep 18, 2013 at 01:45:00PM +0200, Sebastiaan Couwenberg wrote:
> >> Thanks for looking into osgEarth so shortly before you VAC.
> > 
> > Well, forcing people to wait is demotivating ... and I want to push a
> > bit on the motivation side, right. ;-)
> It is certainly motivating, I appreciate it a lot.

> > .../osgearth (master) $ git branch
> > * master
> >   upstream
> > 
> > 
> > Hmmm, it seems pristine-tar branch is missing.  I'm used to import upstream
> > tarball via
> > 
> >     git import-orig --pristine-tar
> > 
> > which enables the byte-identical recreation of the upstream tarball.  While
> > I could download the tarball for sure would you consider also injecting this
> > (or am I missing something again?)
> I don't use pristine-tar, I just commit the uscan downloaded upstream
> tarball to the upstream branch and merge that into the release specific
> branch and/or master to work on the debian packaging for the new
> upstream release.
> I build the packages with git-buildpackage specifying the upstream tree
> and debian branch. For example:
>   git-buildpackage --git-upstream-tree="upstream"
> --git-debian-branch="jessie" --git-pbuilder --git-dist=sid -sa >
> /var/tmp/osgearth-2.4.pbuilder 2>&1 &

Uhmmm, that's a pretty long line to type + to remember.  I feel way to
stupid to remember all this and I rely on a workflow that takes a


only. :-)
> Using pristine-tar instead of commiting the whole upstream tarballs is
> probably better.

Well, ths upstream tarball is *also* included.  However, pristine-tar
stores some metainformation to be able to recreate a *byte-identical*
tarball which is a bit tricky with tar even if the content of the
archive might be byte identical.  There were several threads about this
in the past on debian-devel list.  So the pristine-tar branch is not
instead of the upstream branch but in addition.

> It's probably a good idea to adopt the Debian Perl Group Git Guide and
> modify it for Debian GIS.


> That workflow looks much better than what I've
> come up with, and more like what you were expecting.

As I said:  In Debian Med we somehow forked Debian Perl workflow and are
quite happy about this.  It sounds quite sane to me to either fork again
for Debian Gis directly from Perl or Med (or a mix from both - whatever
seems to be apropriate).

> So far we only document how to setup a Git repo for Debian GIS on the
> wiki. We can use the git guide to document the next steps.


Kind regards


Reply to: