[Pkg-protobuf-devel] Git workflow

[Robert Edmonds]

Iustin Pop wrote:
> 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?

I guess.  But an arbitrary upstream commit isn't going to contain any
debian/* content, anyway, so some sort of merge is going to have to be
performed.

> > 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?

I think so.

> > 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.

Well, the downside is that you would need very strict versioned (build-)
dependencies because upstream is not guaranteeing compatibility between
point releases.  E.g., hypothetically, protobuf-python 3.0.5 must always
be built against protobuf-cpp 3.0.5, not protobuf-cpp 3.0.4 nor
protobuf-cpp 3.0.6.  IIRC, IIUC.

But, the confusing thing is that the "v3.0.0-beta-1" prerelease on
https://github.com/google/protobuf/releases contains tarball artifacts
like:

    protobuf-cpp-3.0.0-beta-1.tar.gz
    protobuf-java-3.0.0-beta-1.tar.gz
    protobuf-python-3.0.0-alpha-4.tar.gz
    protobuf-ruby-3.0.0-alpha-4.tar.gz

They say "Not all languages have reached beta stage. Languages not
marked as beta are still in alpha (i.e., be prepared for API breaking
changes)."  But it is still very confusing to have a tag "v3.0.0-beta-1"
that produces artifacts with version numbers like "v3.0.0-alpha-4".
Hopefully they figure out a less confusing version number regime
post-3.0.0 and this isn't repeated for future pre-releases.

Basically upstream has gotten a bit crazier since the 2.x days and I'm
glad to have co-maintainers :-)

-- 
Robert Edmonds
edmonds at debian.org