On Fri, Aug 7, 2015 at 12:18 AM, Barry Warsaw <ba...@debian.org> wrote: > 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.
pkg-perl migration to git happened quite some time ago, so I guess there were not many tools to choose from at that time (but if someone is interested in the why, I imagine in their ml archives there will be answers) >>* 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. ehm.. Since you havent tried to create a perl package with dh-make-perl, I guess you missed much of its functionalities, like: * it downloads the tarball from CPAN * it populates the debian/ files with the information from module metadata (not all that crap that dh_make does) ** it fetches the ITP bug number from BTS ** setup all b-d and deps in d/control (ok, for deps we have dh_python*), Vcs fields, short and long descriptions and so on: it is basically ready with just 1 or 2 changes ** create a very precise d/copyright (it will still need a manual check, but names, years, licenses are there) * all of these creating a git repo with the standards pkg-perl defined. that's almost all we have to do by hand; i was positively shocked when I used it the first time. > 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. does it matter? git-dpm has currently 214 installation (source Popcon), kinda low for a package mirrored everywhere, but in line with the expectation for a DD/DM tool. the Debian archive is for our users, not necessarily for all development/infrastructure tools. dpt is an implementation of pkg-perl team workflow, so how is it better to have a wiki page with all the commands to cut&paste than a program that does exactly the same without the risk of the "smart" guy who thinks "I know what to do without reading the wiki" and deviates from our standards? > In any case, it's still Another Tool To Learn. we have tons of tools to learn anyway, and this is just a helper for our workflow (so it does basic/routine packaging tasks how *we* want them), i honestly dont see the problem here. >>* 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 I guess https://upsilon.cc/~zack/stuff/dpkg-v3/ proves differently, ie a lot of people seems to appreciate quilt (I know that 3.0 (quilt) doesnt necessarily reflect in using quilt). It's not perfect but I find it usable and in line with the style of other packaging tools. > 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. so one needs to be a git master to apply patches to a debian package? and completly ignoring the standard way debian decides to use (quilt)? I dont want to be forced to use git-dpm just because you dislike quilt and you are so vehemently pushing for git-dpm no one else bothers to say something different. You wanna use it? sure, but that doesnt mean it has to be the default for all our packages. the default has to be the minimum common ground anyone in the team is able to use. and quilt is the default tool for patches, trying to hide it generates just pain. > 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. I used quilt with several packages maintained in git and I never had a problem; I dont find it more painful than dealing with chroot build failures or missing dependencies. >>* 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. well people (not necessarily you) keep repeating we are hindering contributors because we dont use git (and if so, it's just because they are lazy and pretentious), so I really want to see how it will change > 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! totally agree here >>* 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). what I wanted to say is that they coded how they want to do mass commits: once you have a document on how to do them, you are less scared about them and we can be confident about performing whole-packages-set changes >>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. this is exactly what we are doing wrong and the reason they are a "successful" team and this is not (-ish). you will still use quilt (you are just hiding it behind git-dpm and it's git-massaging), and without dpt you just risk to have the same diversification (and here it is *bad*) of packaging styles/layouts/setups that makes work on other packagers' packages so annoying >>(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 if tomorrow I will convert all our packages to git with unapplied quilt will be ok? I dont think so. Do-ocracy is fine until it damages other people work. > 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. rediscussing the patch policy is not getting back to square 1, it is just notifying that a vast majority of contributors didnt express any thoughts on the matter, and just keep pushing for a tool doesnt make it better than others. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- 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/cab4xwxx8pz2+3qbhj2d+g-yuzenyxer88rtrpsu5+kughzq...@mail.gmail.com
