On Friday, August 07, 2015 11:30:11 AM Sandro Tosi wrote: > 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.
As someone who would really like to see the transition just get done, I find having this conversation now VERY frustrating. This has been discussed for literally more than a year including at a session at the last Debconf. When we were discussing git-dpm, I don't recall you objecting. To wait until the moment we are ready to pull the trigger on the migration and demand we stop and reconsider the entire plan certainly feels like some kind of denial of service attack, even if you don't intend it this way. There comes a point where I think the team should be able to say "the time for this conversation was ____ e.g. last year" and we're going to proceed. Personally, I'm pretty much a git neophyte, but I find git-dpm trivially easy to use and it has the property, which I think is essential, of producing packages for upload that have patches in debian/patches that are logically separated. I think it's essential because I don't think that one should have to refer back to a team VCS when trying to understand how to fix a package later (e.g. a security update). [note: I've no idea what other tools do or don't do this, I'm just saying this is an attribute of git-dpm that I find critical to any solution]. How many times should we rediscuss everything before doing this? Scott K -- 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/4799001.kIhubA4cL3@kitterma-e6430
