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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150806191850.08b6a...@limelight.wooz.org