Re: Status of InVesalius packaging (Was: Status of SIGAR (Was: InVesalius packaging))
On Thu, Mar 17, 2011 at 03:23:17PM +0100, Andreas Tille wrote:
> Hi,
>
> I tried
>
> git clone git://github.com/hanke/sigar.git
>
> but there is no debian/ dir in the repository. Am I missing something?
After cloning you are in the 'default' branch -- in this case master.
The debian packaging is in the 'debian' branch (see below for reason).
To get there:
git checkout -b debian origin/debian
> On Thu, Mar 17, 2011 at 09:54:04AM -0400, Michael Hanke wrote:
> >
> > Upstream has sigar on github. It felt good to stay close to upstream --
> > collaborative work on github is much more efficient than on alioth. That
> > being said, I also prefer to have the vcs settings in debian/control
> > point to alioth and pushing to two remote repos is simple and allows
> > working with both ends without compromise.
>
> I admit I have close to zero experience with git (but I'm willing to
> learn). So I can not see in how far it has an advantage to have the
> repository which is targeting at Debian packaging close to upstream
> repository. As far as I understood the workflow is:
>
> 1. Import pristine-tar of *released* upstream tarball (not every
> single commit of their development cycle).
> 2. Maintain debian/ dir and tag every Debian package release
> which does not belong into upstream source (nor its repository)
>
> So what exactly is the point in staying close to upstream repository?
Your workflow describes the scenario where upstream's release tarballs are
the "source". That works great as long as you have them. Many projects
on github don't have them. github offers a mechanism that produces
tarballs for every tag in the repository. making a release is as simple
as 'git tag best-ever; git push best-ever'.
In this case you can take the upstream repository right away to do the
packaging as you know that each release corresponds to a particular
commit. You make a branch (e.g. 'debian'), add the debian dir, and
release from that branch. Git-buildpackage can be configured to produce
any upstream tarball from a configurable branch automatically. You can
place the gbp config into the debian dir to let others know about that.
And now, since your clone of the repos can make use of githubs 'fork'
mechanism, upstream will always know what you do, they can pick any
change they like, you can make 'pull requests', etc...
This is all github specific (although many things work with plain git and
alioth just as good), but the github guys make it really convenient to do
code/patch review (with line-by-line comments, etc.).
Michael
--
Michael Hanke
http://mih.voxindeserto.de
Reply to: