Re: Git migration schedule
On Oct 18, 2015, at 07:19 PM, Jean-Michel Vourgère wrote:
>Git multiple remotes is a nice feature. We can plug right into upstream
>tree.
Currently, our git workflow is tarball-based, since we primarily package PyPI
releases, which are tarball-centric, and because orig.tar is required for
uploads. We've had debates about whether to release from upstream git
revisions, but currently consensus is against that model.
We value consistency across our packages. TOOWTDI.
My personal opinion is that we should live with the current git workflow
recommendations for a while and see how it goes. If there are things we can
improve on (e.g. DEP-14 compatibility) then sure, let's discuss the pros and
cons, but let's not change things right now. I'd like to see how it works in
practice for a while.
>You labelled the wiki as "official" and use terms like "must". I dislike
>that.
I think everyone will agree that we want consistency within the team. You
want to be able to walk up to any package and just know how it is set up in
git. That means following the team guidelines -- but there's an escape hatch
for when you really have to (not want to) diverge from the team. You write a
debian/README.source explaining the rationale and difference.
>Also, for patches, I'm used to source format 3.0 (quilt). Is that bad now?
No. In the master branch you will see quilt formatted patches. It's just
that we're saying that the git repo must be compatible with git-dpm, which is
a patch management regime on top of git and gbp. If you need to generate a
new patch against upstream, we recommend git-dpm to do so.
Now, in practice, it doesn't matter if you ignore git-dpm and just use quilt
*as long as the final state of the repo is compatible with git-dpm*. Meaning,
in general, you can make whatever local decisions you want as long as they
don't force other team members to go outside of team recommendations.
Think of it like this: nobody cares if you use vim, emacs, or some other
editor because it doesn't affect anybody else. Nobody cares if you use sbuild
or pbuilder or something else to build your packages for upload because it
doesn't affect anybody else. But we all have to agree on tag names, branch
names, etc. because those *do* affect everyone.
So if you just use quilt, I don't care, as long as I can walk up to the same
repo and use git-dpm. Local differences are fine, global differences are not.
>I'm not using git-buildpakage, but a simple debuild (tests) or sbuild
>(for final uploads). sbuild is the tool used by buildd on the official
>packages. I can't begin to understand why it would be unacceptable.
I use sbuild and pbuilder in different contexts. Again, that's a local
decision so nobody cares. (I personally always build to source package first
because that gives me maximum flexibility, e.g. to run autopkgtests or
whatever, but that's just me.)
>So basically, I'm out of line. Please soften the new rules.
Not yet please. We've been using git for 10 days. Let's give it time to
settle down.
>Can someone point me to some advantages of using gpb?
Again, much of this is a local decision. Use whatever you want as long as it
doesn't affect other team members. Where you have to create artifacts such as
tag names that are visible outside your local environment, they must conform
to team conventions, otherwise that defeats much of the purpose of being in
the team.
Cheers,
-Barry
Reply to: