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
