[Pkg-protobuf-devel] Git workflow

[Iustin Pop]

On 2015-11-06 13:48:30, Robert Edmonds wrote:
> Iustin Pop wrote:
> > Looking at the git history, it looks like we do keep (and update) some
> > things which are expected normally in a tar.gz (e.g. Makefile.in), but
> > which upstream doesn't store in git; maybe Robert has some special steps
> > done when importing upstream sources?
> 
> Hi,
> 
> The 'upstream' branch is a combination of upstream's release tarballs
> and upstream's repository history, using the --upstream-vcs-tag option
> to gbp import-orig.

I see, thanks for the clarification. It means we can't do 
releases directly from arbitrary upstream commits, at least without
generating ourselves a .tar.gz, right?

> See:
> 
>     http://www.eyrie.org/~eagle/journal/2013-04/001.html
> 
>     http://blog.mycre.ws/articles/converting-to-upstream-vcs-tag/


Interesting. So the upstream branch will contain real-upstream commits
A, B, C, etc…, F with a final synthetic commit 'G' that contains
different from real upstream final commit (F) and the .tar.gz. Is this
correct?

> If we don't want to continue basing the Debian .orig.tar.gz on
> upstream's release tarballs (or the --upstream-vcs-tag workflow is just
> too confusing), then maybe we should switch to a Git-only workflow
> (though probably with gbp buildpackage --git-pristine-tar
> --git-pristine-tar-commit as a backstop so that we track the
> .orig.tar.gz's that we generate).
> 
> I must admit to being very confused at the new upstream convention of
> producing multiple tarball artifacts from the same repository.  Should
> we split src:protobuf into src:protobuf-cpp, src:protobuf-java,
> src:protobuf-python, etc. to match upstream's tarballs, or should we
> continue to have a single src:protobuf that matches upstream's Git
> repository?  I dunno.

Oh, I didn't know (or forgot) that they did that.  If that is correct
and is the long-term plan for upstream, then my opinion is that we
should definitely do switch to separate src packages; in my experience
with protobuf packaging, one of the difficulties in making a new release
is that we have this single big tar gz that generates multiple language
bindings, and small bugfix releases for a single package requires new
builds for everything.

thanks,
iustin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-protobuf-devel/attachments/20151106/17c37b74/attachment.sig>