Re: so you want to migrate DPMT/PAPT to git? look at what pgk-perl did!
On Aug 06, 2015, at 11:42 AM, Sandro Tosi wrote:
>no I mean, really, read http://pkg-perl.alioth.debian.org/git.html
Thanks for the link Sandro.
Reading this, I think it's on par with our
https://wiki.debian.org/Python/GitPackaging by which I mean it's prescriptive
of how to do common tasks in a team collaborative way, but neither document
really provides much rationale on *why* those particular recipes were chosen.
>* they have a tool that automatically creates (and push) a new package
>from CPAN, and sets everything up with the team standards; the same
>should happen for python and pypi. and there is tool (dpt) to manage
>the other common packaging tasks
Certainly we could do the same, but TBH, with a working d/watch file, I've
never much found it necessary. What I'd actually like is for `git-dpm
import-new-upstream` to take no-args and then do a uscan to get the orig.tar
in that case. That seems like it would be a fairly simple patch.
Afaict, dpt is a tool sitting in a special git repo, not even in the archive.
So it's a non-standard thing that members of the Perl team will have to
install and learn and while you could claim that git-dpm is also such a tool,
it's 1) in the archive; 2) not at all specialized toward Python.
In any case, it's still Another Tool To Learn.
>* they do not force as default the use of an unnecessarily convoluted
>"patch regime" - just stick to the path of least resistance, quilt
>unapplied-patches is perfectly usable with git and is a method every
>one can use (and should know anyway), without tying the patch to the
>SCM tool we are using
But, is that a good thing? quilt itself is a PITA to use IMHO, and I find it
very nice that with git-dpm, once you're switched to the patches branch, all
you have to know is git commands. You modify the upstream source in place,
and git commit to your heart's content. If you must, `git rebase -i` and do
other git-y things without having to worry about quilt refreshing, making sure
your patches are created at the correct patch-level, dealing with rejections,
push, pop, quilt apply -f, and other such crazy stuff when the patches don't
apply, etc.
If you say that patch stack management is a PITA either way, I won't argue. :)
But I do think it's generally easier when staying in git as long as possible,
and dealing with other-tool peculiarities only at the boundaries.
>* you can choose more complex ways to do things, but not as the default
>(because -you know- you want us to buy the story "if we migrate to git,
>hordes of contributors will come", then keep the process as simple as
>possible, and be flexible to more skilled maintainers if they want to)
That's not necessarily why *I* want to switch to git. I think it's more or
less a myth that the migration to git suddenly increases the volume or quality
of contributions. I want us to switch to git because git is just a better vcs
than svn, for reasons I don't need to explain to anybody. Switching to git
will make the *current* DPMT members lives easier, and if it reduces friction
so more people will come to help us, bonus!
>* they have a way to download all the packages and do mass-commit on them
Which isn't impossible for us either, IIUC. I think mr would work for us
after switching to git-dpm too, though I have not used it much and very rarely
have ever wanted to do a mass commit (updated d/watch to use the redirector
was the first time I thought, hmm, I'd love to mass commit that change).
>they manage more than 3k packages, their approach works in practice
>and scales, do we really need to reinvent the wheel here?
I don't think we're reinventing the wheel! We're using just a few common
tools and a pile of policy. In fact, we'll be using *fewer* tools that the
Perl team (i.e. just git and git-dpm). No need for a special additional dpt
tool, no need for quilt, and not preventing the use of conveniences like mr.
I even think we're going to have less complex recipes and policies than the
Perl team.
>(as I'm quite sure at debconf there will be discussion about it, this
>my input on the matter)
Thanks for that! I won't be at Debconf this year, and if team members are
there and the conversion is discussed, I hope summaries will be posted. We
had some very thorough discussions at last year's Debconf, followed by lengthy
discussions on the mailing list (and even some at Pycon), and through much
hard work by folks like Stefano, now we're very close to flag day.
I won't say that decisions are set in stone - I don't even have any authority
to say that. IMHO, consensus, and those-who-do-the-work, rules. But I do
hope we don't go back to square one. I think we're fairly well convinced that
if git-dpm turns out to not be the right tool, we'll still have converted to
git, and we can implement some other better workflow later. I still like
git-dpm a lot, but we're not closing any future doors.
(One interesting thing I've learned since last year, reading recent
debian-devel threads, is that dgit isn't a replacement for git-dpm. We really
didn't know much about dgit back then.)
Cheers,
-Barry
Reply to: