Re: Two django packages for Debian?
On Aug 06, 2014, at 02:28 PM, Dimitri John Ledkov wrote: I am on the edge. I prefer dgit, as it's the only one the guarantees round-trip save with the archive even when someone NMUs things without using dgit. From this description, it sounds like dgit is the closest equivalent to Ubuntu Distributed Development (UDD) branches, which of course I am a big fan of[*]. Even with today's svn-based workflow, it bothers me that a packaging branch and the archive might not agree about the state of a package. I've seen this a few times IRL, and it's always a mess to unwind because usually one is not a superset of the other. It's no fun to merge. However, it does not integrate with git-dpm at the moment and there is no clear conversion / vcs history import available. Do we care about preserving vcs history for our packages? Do we want synthetic history (e.g. per upload granularity)? I usually don't care much about preserving local intra-upload vcs history, and think that it's fine to have per-upload granularity in the public package repo. Yes, I'll use lots of intermediate commits locally until I'm happy that the next version of the package is ready to upload, but those can be safely rebased away on upload. (Ironically, this is opposite of my preferences when doing upstream development. In those cases, I want the intermediate commits to be preserved, but in a bzr-style mainline approach, where they're generally hidden to log and bisect commands. In git parlance I think that's --first-parent by default, which doesn't seem to be what git fans use or expect.) We've had debates in UDD circles about whether it's okay to push UDD branches or let the package importer do that step. I personally prefer the latter because it's safer - i.e. if the importer updates the branch on package upload, then there's less chance that the UDD branch breaks. But that's a superstition. From reading the manpage, it sounds like `dgit push` is ideal - it does the upload and pushes the branch so that collaborators would have immediate access to the new version without the need for an importer run. I just tried `dgit clone tox` since that's a package I intend on working on today. It's nice that I got a quilt-pushed source checkout; it means I can start hacking right away. I was dismayed though that there doesn't seem to be any upload history. There's only one commit and it's the last upload. There are no tags. I want the upload history to be reflected in the commit log and tags. Is there a way to synthesize the entire upload history with dgit? Also, reading the dgit manpage it seems like `3.0 (quilt)` integration isn't entirely smooth. I like working with quilt, but would also like better vcs integration. In my limited experience git-dpm seemed the nicest here. Cheers, -Barry [*] In the parallel universe where import failures never occur, bzr is blindingly fast, and bzr won the war. ;) signature.asc Description: PGP signature
Re: Two django packages for Debian?
On Aug 06, 2014, at 04:08 PM, Piotr Ożarowski wrote: and I would love to try them all before we make a decision¹ Me too. Should we relax the team preference for one vcs to rule them all, at least for a period of experimentation and experience sharing? I still *really* want to end up in a place where team packages use one vcs and one common workflow, but it may be time to allow for some non-svn managed packages. If we did, I would pick one or two of the ones I touch and experiment with some of the git packaging tools. (I suspect this may be a big topic for us at DC14 :). -Barry signature.asc Description: PGP signature
Re: Two django packages for Debian?
On Aug 09, 2014, at 06:02 PM, Brian May wrote: At the moment, in subversion, we only store the debian/* directory. Is there any requirement/benefit in putting the full upstream source in git too? If it were well integrated with quilt, I think it would be fine to have source-full branches. I like this aspect of UDD, but I've also become comfortable working with our svn debian-only branches. It usually means unpacking the tarball, cd'ing into that directory and symlinking in debian/ to work with the patch stack. It's a bit jarring though, since I have to go back to the svn branch directory to build the packages (source or binary), so I'm always flipping between the two directories. The other thing that *has* to work flawlessly for source-full checkouts is importing new upstream versions. If you do this naively in a UDD branch, you're screwed. `bzr merge-upstream` is the trick to make this work, since it updates the upstream source to match the tarball. I think this step should re-apply the quilt stack automatically, but of course scream loudly if it gets to a patch that is out of date. I guess I can summarize this as comfort != joy. :) -Barry signature.asc Description: PGP signature
Re: Two django packages for Debian?
On Aug 19, 2014, at 11:14 AM, Barry Warsaw wrote: I usually don't care much about preserving local intra-upload vcs history Ah, except for the case where I want to collaborate with someone on the new version, e.g. to get a code review of some packaging change *before* it gets uploaded. This is especially true for team members who don't have upload rights. I think it would be great if they could push their proposed packaging changes, which I could fetch, review, edit, push, merge, and upload. It would be nice to be able to capture a conversation between developers, e.g. as in a github pull request[*]. -Barry [*] No, I don't suggest using github; it's not free software. signature.asc Description: PGP signature
Re: Two django packages for Debian?
On 08/06/2014 10:08 PM, Piotr Ożarowski wrote: I am on the edge. I prefer dgit and I would love to try them all before we make a decision¹ If one wants us to consider XYZ, please send a link to test repo and a list of commands that will let us deal f.e. with such problems: * how can I fetch foo sources? IMO, it should be contained in the Git repository. With the workflow I'm using, it's already on your local repo after you do debcheckout, since it's contained in the tag (though it's not suitable for an upload because xz doesn't produce the same output twice, so your orig.tar.xz may be different from what's already in the Debian archive). With pristine-tar, no need to explain, it's there. * what about updating all packages in one command? (XYZ pull? mr update?) mr sounds like the correct tool. Anyway, in about 2 years, the only archive-wide commit that I saw was about the VCS fields, which I think isn't so important. Do you have other examples of team-wide commits that have occurred? * how can I build it? (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?) git-buildpackage is the natural tool, IMO. * old patch needs an update, what should I do? (quilt edit? quilt refresh? XYZ rebase on a different branch?) Do whatever is needed to edit the patch in debian/patches. What's the issue exactly? * there's new upstream release, how can I import it? (uscan in source pkg's root dir?) What I do: ./debian/rules fetch-upstream-remote git merge -X theirs tag-name That's in the case of upstream using Git (which, these days, is maybe 95% of the packages I maintain). Otherwise, use git-import-orig and pristine-tar... * new patch is needed, how can I add it? (quilt new? another branch?) Same as above. Do whatever you feel right to edit stuff in debian/patches, and git push the result. * how can I share my changes? (XYZ push?) Is there any other way than git push? etc. (i.e. describe workflow) My workflow is described here: http://openstack.alioth.debian.org/ I don't ask anyone to convert the whole repo, I ask to provide one/few packages for tests. If someone knows dgit, git-dpm, git-buildpackage, hg-buildpackage then (s)he probably already have at least one package that uses it, no? Just copy it to dpmt's git/hg/bar² repo and let others play with it. I would need to learn dgit and git-dpm. Pointers to howto welcome! [¹] note that, unless someone will provide a wrapper that unifies it all, there will be no 2 or more VCSs/tools at the same time Like it or not, this has already happened (with people using collab-maint for example). Thomas Goirand (zigo) -- 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/53ee426f.7020...@debian.org
Re: Two django packages for Debian?
On Wed, 13 Aug 2014, Piotr Ożarowski wrote: [Raphael Hertzog, 2014-08-13] * old patch needs an update, what should I do? (quilt edit? quilt refresh? XYZ rebase on a different branch?) * new patch is needed, how can I add it? (quilt new? another branch?) I don't see the need for the team to impose anything here. patches are stored in quilt format, people can use quilt or git-dpm or gbp-pq. that's the problem. I'm lazy and I rather stop helping / sponsoring than learn 650 ways to add a patch. You don't have to learn multiple ways to add a patch. You pick your preferred tool and you use it. Others use their preferred tool and everybody is happy since the exchange format (quilt series stored in debian/patches) is well defined. git-dpm and gbp-pq uses local branches that don't get pushed to update the patch series but the result is a simple update of debian/patches in whatever branch we store the Debian packaging. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140814154758.ga2...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
So let me give my own answer to some of the questions asked here. On Wed, 06 Aug 2014, Dimitri John Ledkov wrote: However, it does not integrate with git-dpm at the moment and there is no clear conversion / vcs history import available. Do we care about preserving vcs history for our packages? Do we want synthetic history (e.g. per upload granularity)? I believe it's useful to have some history, at least on a per-upload basis (and it's relatively easy to do do with git-import-dscs + debsnap). On Wed, 06 Aug 2014, Piotr Ożarowski wrote: If one wants us to consider XYZ, please send a link to test repo and a list of commands that will let us deal f.e. with such problems: Feel free to use debcheckout python-django as a test bed (just don't git push your tests). * how can I fetch foo sources? what about updating all packages in one command? (XYZ pull? mr update?) git clone For the multiple repositories, yes it's mr that most teams use. * how can I build it? (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?) I do use git-buildpackage but it's really not a requirement. debbuild should be usable on a git clone. * old patch needs an update, what should I do? (quilt edit? quilt refresh? XYZ rebase on a different branch?) * new patch is needed, how can I add it? (quilt new? another branch?) I don't see the need for the team to impose anything here. patches are stored in quilt format, people can use quilt or git-dpm or gbp-pq. * there's new upstream release, how can I import it? (uscan in source pkg's root dir?) git-import-orig --pristine-tar --uscan * how can I share my changes? (XYZ push?) git push origin : git push origin --tags On Sat, 09 Aug 2014, Brian May wrote: At the moment, in subversion, we only store the debian/* directory. Is there any requirement/benefit in putting the full upstream source in git too? Not putting the upstream sources would be non-sense. We want to be able to use the git tools to maintain the quilt series and for this we need the sources in git. It also makes it possible to use standard tools like debuild instead of needing some pre-build setup logic to extract the upstream sources and inject the debian directory. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140813190835.ga18...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
[Raphael Hertzog, 2014-08-13] * old patch needs an update, what should I do? (quilt edit? quilt refresh? XYZ rebase on a different branch?) * new patch is needed, how can I add it? (quilt new? another branch?) I don't see the need for the team to impose anything here. patches are stored in quilt format, people can use quilt or git-dpm or gbp-pq. that's the problem. I'm lazy and I rather stop helping / sponsoring than learn 650 ways to add a patch. -- Piotr Ożarowski Debian GNU/Linux Developer www.ozarowski.pl www.griffith.cc www.debian.org GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645 signature.asc Description: Digital signature
Re: Two django packages for Debian?
Raphael Hertzog hert...@debian.org writes: So let me give my own answer to some of the questions asked here. These questions would best be answered in a ‘debian/README.source’ document giving all the information needed to work with the Debian source for the package. -- \ “You can be a victor without having victims.” —Harriet Woods, | `\ 1927–2007 | _o__) | Ben Finney -- 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/85r40k6i54@benfinney.id.au
Re: Two django packages for Debian?
On 7 August 2014 00:08, Piotr Ożarowski pi...@debian.org wrote: I am on the edge. I prefer dgit and I would love to try them all before we make a decisionน Would be interested in a brief summary of the different workflows possible, and a comparison. I have not been keeping up. At the moment, in subversion, we only store the debian/* directory. Is there any requirement/benefit in putting the full upstream source in git too? -- Brian May br...@microcomaustralia.com.au
Re: Two django packages for Debian?
Hi, On Tue, 05 Aug 2014, Matthew Vernon wrote: https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git [...] Naturally, I'd like to upload these as maintained by python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If so, I'll make some ITPs, and initial uploads. I would feel uncomfortable having the name of the team on it while the package is not on a repository writable by all members. (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) Looking on git.debian.org, it looks like that some people started using git for team maintained packages: $ ls -al /git/python-modules/packages/ total 48 drwxrwsr-x+ 6 bzed scm_python-modules 4096 juil. 22 09:26 . drwxrws---+ 5 root scm_python-modules 4096 janv. 30 2014 .. drwxrwsr-x+ 7 obergix scm_python-modules 4096 nov. 29 2013 django-ldapdb.git drwxrwsr-x+ 7 azatoth-guest scm_python-modules 4096 mars 18 2013 plastex.git drwxrwsr-x+ 7 zigo scm_python-modules 4096 mai 16 2013 python3-pyparsing.git lrwxrwxrwx 1 aelmahmoudy-guest scm_python-modules 36 juil. 22 09:26 python-whoosh.git - ../../collab-maint/python-whoosh.git drwxrwsr-x+ 7 dkg scm_python-modules 4096 mars 18 2013 python-xlrd.git So please move your git repository there. /me notes to switch python-django to git. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140806064730.ga13...@x230-buxy.home.ouaza.com
Re: Two django packages for Debian?
On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote: (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) We've had these discussions on this mailing list before, but I think we should discuss it at Debconf. While obviously we won't have full representation (whatever that means ;) from team members, we should take advantage of the high bandwidth setting to discuss the future vcs for the Python teams. In the past we've all had the important and worthy goal of using a consistent packaging and workflow for team maintained projects. However, if folks are abandoning the team in order to use git, then we already have fragmentation, and it will only increase. I'm not particularly a git fan, but it's clear where this is heading. :) I don't think the question is if, but when and how. There are at least two git-based packaging tools and workflows: gbp and git-dpm. In my limited exposure, I've had problems with the former but have been pretty happy with the latter. There's also this interesting thread: https://lists.ubuntu.com/archives/ubuntu-devel/2014-August/038418.html What I really want to avoid is having to think about which vcs or workflow team packages have adopted. I really value the ability to use the same tool (svn-buildpackage) and workflow for all team packages. It makes it easy to do drive-by fixes and updates. I'm happy to adopt something else, but I don't want to adopt 5, 10, or M number of something elses. ;) We need a plan for transition, documentation for team members, and volunteers to see it through. I am offering to help. I hope the intersection of Debian, Python, and git fans will come to Debconf and help us lay the groundwork for a successful team-wide transition. 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/20140806091809.5c942...@anarchist.wooz.org
Re: Two django packages for Debian?
On 6 August 2014 14:18, Barry Warsaw ba...@debian.org wrote: On Aug 06, 2014, at 08:47 AM, Raphael Hertzog wrote: (That said I'm also rather annoyed by the fact that the team hasn't switched to git yet.) We've had these discussions on this mailing list before, but I think we should discuss it at Debconf. While obviously we won't have full representation (whatever that means ;) from team members, we should take advantage of the high bandwidth setting to discuss the future vcs for the Python teams. In the past we've all had the important and worthy goal of using a consistent packaging and workflow for team maintained projects. However, if folks are abandoning the team in order to use git, then we already have fragmentation, and it will only increase. I'm not particularly a git fan, but it's clear where this is heading. :) I don't think the question is if, but when and how. There are at least two git-based packaging tools and workflows: gbp and git-dpm. In my limited exposure, I've had problems with the former but have been pretty happy with the latter. There's also this interesting thread: I am on the edge. I prefer dgit, as it's the only one the guarantees round-trip save with the archive even when someone NMUs things without using dgit. However, it does not integrate with git-dpm at the moment and there is no clear conversion / vcs history import available. Do we care about preserving vcs history for our packages? Do we want synthetic history (e.g. per upload granularity)? -- Regards, Dimitri. -- 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/CANBHLUia+dHSdA_-T5wAy_=z1r-m1btwcdjer4bkykdh4hh...@mail.gmail.com
Re: Two django packages for Debian?
I am on the edge. I prefer dgit and I would love to try them all before we make a decision¹ If one wants us to consider XYZ, please send a link to test repo and a list of commands that will let us deal f.e. with such problems: * how can I fetch foo sources? what about updating all packages in one command? (XYZ pull? mr update?) * how can I build it? (is debuild/sbuild enough or do I need to use XYZ-buildpackage/whatever?) * old patch needs an update, what should I do? (quilt edit? quilt refresh? XYZ rebase on a different branch?) * there's new upstream release, how can I import it? (uscan in source pkg's root dir?) * new patch is needed, how can I add it? (quilt new? another branch?) * how can I share my changes? (XYZ push?) etc. (i.e. describe workflow) I don't ask anyone to convert the whole repo, I ask to provide one/few packages for tests. If someone knows dgit, git-dpm, git-buildpackage, hg-buildpackage then (s)he probably already have at least one package that uses it, no? Just copy it to dpmt's git/hg/bar² repo and let others play with it. [¹] note that, unless someone will provide a wrapper that unifies it all, there will be no 2 or more VCSs/tools at the same time [²] if it's not enabled for DPMT and you want to provide examples, please ping me to enable it on alioth for you -- 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/20140806140833.gc4...@sts0.p1otr.com
Re: Two django packages for Debian?
On 06/08/14 04:25, Brian May wrote: On 6 August 2014 03:11, Matthew Vernon matt...@debian.org mailto:matt...@debian.org wrote: I've packaged up django-grappelli and django-stronghold (since we have need for them at work). I think my debianisations are sane, but I've done them in git not subversion. Repos: Please make sure these work with Django 1.7 in experimental... Is 1.7 released yet? At least Grappelli only aims to work with released versions, so I think it's currently only 1.6-compatible. I'd expect 1.7-support to be along once that's been out for a bit. Regards, Matthew -- 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/53e24cd3.20...@debian.org
Re: Two django packages for Debian?
Hi, On 06/08/14 07:47, Raphael Hertzog wrote: Hi, On Tue, 05 Aug 2014, Matthew Vernon wrote: https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git [...] Naturally, I'd like to upload these as maintained by python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If so, I'll make some ITPs, and initial uploads. I would feel uncomfortable having the name of the team on it while the package is not on a repository writable by all members. Oh, sure. It seemed a bit presumptive to stick a repo into git.debian.org without asking first was all :-) Looking on git.debian.org, it looks like that some people started using git for team maintained packages: So please move your git repository there. Will do. /me notes to switch python-django to git. :-) Regards, Matthew -- 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/53e24d3f.4010...@debian.org
Re: Two django packages for Debian?
Hi Matthew, On Wed, 06 Aug 2014, Matthew Vernon wrote: Is 1.7 released yet? At least Grappelli only aims to work with released versions, so I think it's currently only 1.6-compatible. I'd expect 1.7-support to be along once that's been out for a bit. 1.7 will be out in a few days/weeks and we aim to include it in Debian Jessie. We have opened bugs against all reverse dependencies asking them to validate their package with Django 1.7rc2 in experimental. See https://lists.debian.org/debian-python/2014/07/msg00085.html So please ensure they work with Django 1.7 before upload, or file a bug yourself and user tag them so that they appear in: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=python-dja...@packages.debian.org;tag=django17 Thank you! -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140806192529.gb13...@x230-buxy.home.ouaza.com
Two django packages for Debian?
Hi, I've packaged up django-grappelli and django-stronghold (since we have need for them at work). I think my debianisations are sane, but I've done them in git not subversion. Repos: https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-grappelli.git https://git.csx.cam.ac.uk/x/ucs/u/mcv21/django-stronghold.git Resulting packages: http://www-uxsup.csx.cam.ac.uk/~mcv21/debian/pool/main/d/django-grappelli/ http://www-uxsup.csx.cam.ac.uk/~mcv21/debian/pool/main/d/django-stronghold/ Description: Grappelli, a jazzy skin for the Django admin interface Grappelli is a grid-based alternative/extension to the Django administration interface. Description: makes all Django views default to login_required Stronghold is a small Django app that makes your Django project default to requiring login for all views. Naturally, I'd like to upload these as maintained by python-modules-t...@lists.alioth.debian.org. Is that going to be OK? If so, I'll make some ITPs, and initial uploads. Cheers, Matthew -- 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/53e1102e.5070...@debian.org
Re: Two django packages for Debian?
On 6 August 2014 03:11, Matthew Vernon matt...@debian.org wrote: I've packaged up django-grappelli and django-stronghold (since we have need for them at work). I think my debianisations are sane, but I've done them in git not subversion. Repos: Please make sure these work with Django 1.7 in experimental... -- Brian May br...@microcomaustralia.com.au
