Hi there
> Remember that the page describing how things will work within the team once
> we've migrated to git is described here:
> https://wiki.debian.org/Python/GitPackaging
> We'll make that page official once the migration is done.
I've using git for some years now, and so does upstream in most of the
packages I maintain.
Git multiple remotes is a nice feature. We can plug right into upstream
tree.
I like it for copyrights tracking, for example.
You labelled the wiki as "official" and use terms like "must". I dislike
that.
"master" branch name is already used by upstream (This is *very* often
the case). Using "master" ourself makes the things quite confusing in my
opinion. debian/master or debian/sid make more sense to me. I use
debian/wheezy and similar for security and backports. This is compatible
with DEP14 while your guideline is not.
As for the tags, I'm using "git pull" then "git push alioth --tags", so
that all upstream tags are automatically copied in our git. If upstream
tags "1.2" it is put in alioth, not "upstream/1.2". I love that feature.
That's forbidden now?
Also, for patches, I'm used to source format 3.0 (quilt). Is that bad now?
When I changed a file, I used to have a hint to run "dpkg-source
--commit". I miss that.
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.
So basically, I'm out of line. Please soften the new rules.
Can someone point me to some advantages of using gpb? Right now I can
only see useless constraints like branch names that collide with names
used by upstream, duplicate clean during build, and quilt files that
aren't created automatically on build and so on and so forth.
Why I should learn yet another set of tools such as gbp? There must be
some advantages, I presume?
Maybe I'm too far gone and should just leave the team?
