Re: How does team maintenace of python module works?
On 02/20/2013 12:38 PM, Scott Kitterman wrote: > On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote: >> The idea to use "git archive" was mostly from Julien Danjou. It's >> very nice because that way, we can use xz compression, instead >> of what upstream provides (that is, github .zip or .tar.gz, which >> isn't the best). > See devref 6.7.8. This not an appropriate reason to not use the upstream > tarball. > > Scott K Thanks Scott, but I believe I know what I'm doing. This wasn't the only reason I stated, it's only one of the consequences. What upstream considers "release tarballs" are *not* what Github provides anyway (it is a little bit more complex than this). Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512489eb.7080...@debian.org
Re: How does team maintenace of python module works?
Thomas Goirand scrisse: > I've found that having a debian/rules entry called "get-vcs-source" > which gets what is needed from upstream works quite nicely. Our > workflow is described here: > > http://openstack.alioth.debian.org/ > > The idea to use "git archive" was mostly from Julien Danjou. It's > very nice because that way, we can use xz compression, instead > of what upstream provides (that is, github .zip or .tar.gz, which > isn't the best). It's also quite nice because that way, it's possible > to tag a specific commit and package that as upstream release. > This is mostly why I think using Git is convenient, so I really would > like this to be part of the draft. This may suit well for the openstack scenario, however in general I could see at least two shortcomings: * pristine upstream tarballs are not used (see the first "should" in devref §6.7.8.2) * it assumes that no tarball generation process (eg. make dist) is needed I'm not sure how much impact they have on normal python-team workflow, though. Cheers, Luca -- .''`. | ~<[ Luca BRUNO ~ (kaeso) ]>~ : :' : | Email: lucab (AT) debian.org ~ Debian Developer `. `'` | GPG Key ID: 0x3BFB9FB3 ~ Free Software supporter `-| HAM-radio callsign: IZ1WGT ~ Networking sorcerer signature.asc Description: PGP signature
Re: How does team maintenace of python module works?
On 02/20/2013 12:41 PM, Scott Kitterman wrote: > This all seems to assume full source branches which is not something I'm > interested in participating in at all. I've tried it and I find it very > difficult to work with. > > Currently we have one VCS and one package layout. In the end, we should have > that still. Anything else raises a substantial barrier to collaboration. > > Scott K Would you care explaining why full source branches is difficult to work with? Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51248a7d.3000...@debian.org
Re: How does team maintenace of python module works?
On 02/20/2013 04:31 PM, Luca BRUNO wrote: > This may suit well for the openstack scenario, however in general I > could see at least two shortcomings: > * pristine upstream tarballs are not used (see the first "should" in > devref §6.7.8.2) > * it assumes that no tarball generation process (eg. make dist) is > needed > > I'm not sure how much impact they have on normal python-team workflow, > though. > > Cheers, Luca I agree it only fits cases where upstream uses git and tags. Though it's a more and more common case. Some upstream authors don't even care to release a tarball at all nowadays. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51248ec5.1050...@debian.org
Re: How does team maintenace of python module works?
Am 20.02.2013 09:31, schrieb Thomas Goirand: > On 02/20/2013 12:38 PM, Scott Kitterman wrote: >> On Wednesday, February 20, 2013 12:23:02 PM Thomas Goirand wrote: >>> The idea to use "git archive" was mostly from Julien Danjou. It's >>> very nice because that way, we can use xz compression, instead >>> of what upstream provides (that is, github .zip or .tar.gz, which >>> isn't the best). >> See devref 6.7.8. This not an appropriate reason to not use the upstream >> tarball. >> >> Scott K > Thanks Scott, but I believe I know what I'm doing. No, I don't think so. > This wasn't the > only reason I stated, it's only one of the consequences. > > What upstream considers "release tarballs" are *not* what Github > provides anyway (it is a little bit more complex than this). So there would be no way anymore to build using upstream tarballs? This doesn't sound appropriate to force on a whole team. I don't think that many of the people that voted are aware of your implicit changes (no release tarballs, including upstream source in the VCS) by moving to git. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51248fdf.4010...@debian.org
Re: How does team maintenace of python module works?
On 02/20/2013 04:57 PM, Matthias Klose wrote: > So there would be no way anymore to build using upstream tarballs? Upstream tarballs, in some cases, is a concept of the past. When they are released (sometimes, they simply don't exist), it may only an image based on a git tag. Then using Git tags is often better, because tags may be PGP signed. I live in China, and the Chinese government did twice some man in the middle attack... Tarballs don't include PGP signatures. Plus it's possible for me to tag at any point in time, any commit, and use that to generate a tarball. Signed git tags is the new trend, you shouldn't fear it, and stick to the old 1980's concepts forever, only because we always did this way. If sticking to our old habits is not the only valid point, that there are real technical reasons why we should never be using a git tag as the key for an upstream release, or if you think they might be real difference between the "git archive" generated xz file and the github/gitorious/etc. tag based tar.gz, please explain. > This doesn't sound appropriate to force on a whole team. Of course it's not. In fact, I don't think it's the right thing to do to impose rules set that strong, and write them into a stone. There's no "one size fit all", and such a rigidity may bring inconvenience. I by the way think that switching everything from SVN to Git will probably be painful for a lot of the team members, which is why I think it isn't a so good idea, and that best would have been to allow both even if I understand why using more than one VCS might be at least annoying and probably very inconvenient sometimes. This doesn't mean that we shouldn't try to define some standards, and try to stick with them whenever possible, but only to some reasonable extend. Also, if you have valid arguments to use one type of workflow, and if it really is convenient to work the way you tell, I will happily adopt your way. Please share your view, and packaging habits and tricks! My intention when describing our workflow was to give ideas, and confront them. If everyone shares, I'm sure this will be beneficial. > I don't think that many of the people that voted are aware of your implicit > changes (no release tarballs, including upstream source in the VCS) by moving > to > git. > > Matthias Once more, I never wanted to change anything in the team, I just wanted to be allowed to use Git when relevant. I voted CDBA, in this order, as I didn't wish to distrub anyone that likes SVN. Now, do you know if it is possible to use git-buildpackage without storing the full upstream source in a branch? I never did that way. For me, using git-buildpackage is mandatory, it is simply too convenient. What is the problem of storing upstream source code anyway (that's the 2nd time I ask, as nobody explained yet why it's a problem)? Cheers, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124da42.9020...@debian.org
Re: How does team maintenace of python module works?
On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote: >If sticking to our old habits is not the only valid point, that there >are real technical reasons why we should never be using a git tag >as the key for an upstream release, or if you think they might be >real difference between the "git archive" generated xz file and the >github/gitorious/etc. tag based tar.gz, please explain. You better be darn sure that upstream has excellent QA then, and that you know for sure that a tag is correctly assigned to a buildable, tested, QA passed snapshot of the project. Also, you must ensure that everything necessary to build and deploy the package is either included in the repository or is easily generated by something that is in the repository. I bet that's going to cover a minority of projects still. At least with a tarball, you know you have a releasable "thing" that upstream has blessed (which could still have problems, sure, but that's different than not being sure.) Look at it from a Debian Python packager's point of view. If it's on PyPI, then there's no guessing. If it's a git tag in some repo, you have to carry along much more implicit context (e.g. the workflow of the upstream project, do I have the right repo, etc.). It's also not true that tarballs can't be signed, they are all the time on PyPI. Maybe not as often as we'd like, but still. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130220092305.445b7...@anarchist.wooz.org
Re: How does team maintenace of python module works?
On 20/02/13 14:14, Thomas Goirand wrote: > Now, do you know if it is possible to use git-buildpackage > without storing the full upstream source in a branch? Yes, most conveniently done via 'overlay = True' in debian/gbp.conf. You have to supply a copy of the upstream tarball as you would for plain debuild or svn-buildpackage, typically in .. or ../tarballs (also configurable in gbp.conf). I do this for openarena-data and its various related packages, because the full upstream source is *huge* (mostly audio, graphics etc.), particularly once I included the actual source files, so keeping a copy in git would be a significant problem; and the upstream source is unlikely to ever be patched in Debian (not that binary files patch well anyway), so there's no point. I don't think debian-directory-only maintenance in git is a good idea for typical packages containing "mostly" code - you lose the ability to use gbp-pq to manage patches, for instance. openarena and ioquake3 do have an 'upstream' branch, using the typical git-buildpackage workflow. S -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124e066.4050...@debian.org
Re: How does team maintenace of python module works?
On Wednesday, February 20, 2013 04:34:05 PM Thomas Goirand wrote: > On 02/20/2013 12:41 PM, Scott Kitterman wrote: > > This all seems to assume full source branches which is not something I'm > > interested in participating in at all. I've tried it and I find it very > > difficult to work with. > > > > Currently we have one VCS and one package layout. In the end, we should > > have that still. Anything else raises a substantial barrier to > > collaboration. > > > > Scott K > > Would you care explaining why full source branches is difficult to work > with? First, full source repositories are much larger than debian only repositories. I don't have a full checkout of all team packages locally, so that means if I'm going to touch a package I don't have to download, it's more time, bandwidth, etc. Even for a new upstream version, debian directory in the repository and upstream tarball is still smaller. Second, I think Debian packaging work and upstream's product should be distinct in the source package. The source package is what Debian as a project ships as the source for DFSG purposes and it should be useful. "Here's a huge mass of code and to understand what we did to it, you need to refer to this external repository (VCS)" is not socially acceptable to me. Third, I have yet to see a workflow for maintaining debian/patches in a VCS as part of a full source branch that was not more work than just having the patches in a debian/patches and letting dpkg handle getting them applied/ unapplied. Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to figure out a workflow that integrates all those just seems impossible. I've used partial (debian dir) VCS branches for years in both Debian and Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at all to full source. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1460350.rKONIhgERt@scott-latitude-e6320
python3 and /usr/share
Hi, I am trying to create packages for Python3 for the source package [1]. Following the guide [2], I get some success. However, the packages for Python2 and Python3 differ significantly: in the Python2 package, all machine independent data go into /usr/share/, while the Python3 package contains everything under /usr/lib/python3. Is this intentional, or shall I change something in the rules to get a proper layout? I've investigated some other python3 packages, they all put everything in /usr/lib/python3/. However, this seems to contradict the FHS? What is the way to go here? I've uploaded the package to debian-mentors [3], in case one wants to review it. Best regards Ole [1] python-astropy, http://bugs.debian.org/678168 [2] http://wiki.debian.org/Python/LibraryStyleGuide [3] http://mentors.debian.net/package/python-astropy -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ytzppzv2gph@news.ole.ath.cx
Re: How does team maintenace of python module works?
On Wednesday, February 20, 2013 10:14:26 PM Thomas Goirand wrote: > Upstream tarballs, in some cases, is a concept of the past. When > they are released (sometimes, they simply don't exist), it may only > an image based on a git tag. Then using Git tags is often better, > because tags may be PGP signed. I live in China, and the Chinese > government did twice some man in the middle attack... Tarballs > don't include PGP signatures. Plus it's possible for me to tag at > any point in time, any commit, and use that to generate a tarball. In some cases, sure. For me, every package I maintain has a tarball release and most, if not all, provide signatures for the tarball. GPG signed is not an advantage for git tags. Anything can be signed. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/24754993.i0WrSetHUW@scott-latitude-e6320
Re: How does team maintenace of python module works?
On 02/20/2013 10:23 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote: > >> If sticking to our old habits is not the only valid point, that there >> are real technical reasons why we should never be using a git tag >> as the key for an upstream release, or if you think they might be >> real difference between the "git archive" generated xz file and the >> github/gitorious/etc. tag based tar.gz, please explain. > You better be darn sure that upstream has excellent QA then, and that you know > for sure that a tag is correctly assigned to a buildable, tested, QA passed > snapshot of the project. In what way the QA is different because it's a tag instead of a tarball ? I don't understand your reasoning. In both cases, you must make sure that what you are packaging is buildable, tested, QA, etc. > Also, you must ensure that everything necessary to > build and deploy the package is either included in the repository or is easily > generated by something that is in the repository. I bet that's going to cover > a minority of projects still. At least with a tarball, you know you have a > releasable "thing" that upstream has blessed (which could still have problems, > sure, but that's different than not being sure.) > > Look at it from a Debian Python packager's point of view. If it's on PyPI, > then there's no guessing. If it's a git tag in some repo, you have to carry > along much more implicit context (e.g. the workflow of the upstream project, > do I have the right repo, etc.). With many PiPY projects, I can see that the generated tarball are the exact same thing as what's tagged in the Git repository. Often, the release process is automated so the tag and the tarball are released at once. This has been the case, for example, for: - python-pecan (https://github.com/dreamhost/pecan) - python-json-patch (https://github.com/stefankoegl/python-json-patch) - python-json-pointer (https://github.com/stefankoegl/python-json-pointer) - python-tablib (https://github.com/kennethreitz/tablib) - cliff-tablib (https://github.com/dreamhost/cliff-tablib) - python-warlock (https://github.com/bcwaldon/warlock) (non exhaustive list... and not including all of Openstack!) I don't understand your reasoning, they are all using setuptools, and are perfectly buildable, installable, etc. Did I miss something? Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124e387.8080...@debian.org
Re: python3 and /usr/share
Am 20.02.2013 15:38, schrieb Olе Streicher: > Hi, > > I am trying to create packages for Python3 for the source package > [1]. Following the guide [2], I get some success. However, the packages > for Python2 and Python3 differ significantly: in the Python2 package, > all machine independent data go into /usr/share/, while the Python3 > package contains everything under /usr/lib/python3. Having /usr/share/pyshared in Python2 is an implementation detail. This is never used on sys.path directly. > Is this intentional, or shall I change something in the rules to get a > proper layout? I've investigated some other python3 packages, they all > put everything in /usr/lib/python3/. This is correct. > However, this seems to contradict the FHS? What is the way to go here? No, the FHS doesn't make any statement about code in /usr/share. Matthias -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124e393.8010...@debian.org
Re: python3 and /usr/share
On 20 February 2013 14:38, Olе Streicher wrote: > I am trying to create packages for Python3 for the source package > [1]. Following the guide [2], I get some success. However, the packages > for Python2 and Python3 differ significantly: in the Python2 package, > all machine independent data go into /usr/share/, while the Python3 > package contains everything under /usr/lib/python3. > The Python code itself goes into /usr/lib/python3 now - as I understand it, /usr/share/pyshared was a workaround that's not needed for Python 3. If the package includes actual data files, they should still go into /usr/share. If it has a lot of data files, it might be worth splitting them into a -data or -common package that the Python 2 & 3 packages both depend on. IPython & matplotlib both use this: ipython3-notebook depends on ipython-notebook-common, and python3-matplotlib depends on python-matplotlib-data. Best wishes, Thomas
Re: How does team maintenace of python module works?
On 20 February 2013 14:53, Thomas Goirand wrote: > In what way the QA is different because it's a tag instead of a tarball ? > I don't understand your reasoning. In both cases, you must make sure > that what you are packaging is buildable, tested, QA, etc. > I think the idea is that, if you prepare a release and find some last-minute critical bug (say, in the build process), you'll definitely upload a fixed release tarball, because that's what people are installing from. But you might have already tagged it, and you might forget to move the tag to the fixed version. Of course, in projects where the git tag is the release, it makes no difference. But lots of projects still do tag a release and upload separate release tarballs (say, to PyPI). Thomas
Re: How does team maintenace of python module works?
On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote: >> You better be darn sure that upstream has excellent QA then, and that you >> know for sure that a tag is correctly assigned to a buildable, tested, QA >> passed snapshot of the project. > >In what way the QA is different because it's a tag instead of a tarball ? >I don't understand your reasoning. In both cases, you must make sure >that what you are packaging is buildable, tested, QA, etc. Right, but it's a matter of context. If you have a release on PyPI, you know it's been blessed. You don't need any more context. For a git tag, I have to know what is the blessed repo url, how the tagging scheme works, what the latest releasable snapshot is tagged, etc. I need much more context to know what is "a release" (even though upstream might find them quaint, Debian still does releases of packages, i.e. uploads). What if the repo url changes? What if they start using a different tagging scheme? What if someone accidentally assigned a release tag to a non-releasable revision? That might not be so important for someone who has intimate and ongoing knowledge of package maintenance, but it's really important for team maintained packages where I might have to fix a bug or grab a new upstream for a package you primarily maintain. >> Look at it from a Debian Python packager's point of view. If it's on PyPI, >> then there's no guessing. If it's a git tag in some repo, you have to carry >> along much more implicit context (e.g. the workflow of the upstream project, >> do I have the right repo, etc.). > >With many PiPY projects, I can see that the generated tarball are the >exact same thing as what's tagged in the Git repository. Often, the >release process is automated so the tag and the tarball are released >at once. This has been the case, for example, for: > >- python-pecan (https://github.com/dreamhost/pecan) >- python-json-patch (https://github.com/stefankoegl/python-json-patch) >- python-json-pointer (https://github.com/stefankoegl/python-json-pointer) >- python-tablib (https://github.com/kennethreitz/tablib) >- cliff-tablib (https://github.com/dreamhost/cliff-tablib) >- python-warlock (https://github.com/bcwaldon/warlock) That's great, but I bet it's a minority of projects on PyPI. >(non exhaustive list... and not including all of Openstack!) > >I don't understand your reasoning, they are all using setuptools, and >are perfectly buildable, installable, etc. Did I miss something? The point is, I might not want or have the time to know all the intimate details about how upstream does its project management. It will certainly be an impediment to collective, team maintenance. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130220100912.650cf...@anarchist.wooz.org
Re: python3 and /usr/share
On Feb 20, 2013, at 03:38 PM, Olе Streicher wrote:
>I am trying to create packages for Python3 for the source package
>[1]. Following the guide [2], I get some success. However, the packages
>for Python2 and Python3 differ significantly: in the Python2 package,
>all machine independent data go into /usr/share/, while the Python3
>package contains everything under /usr/lib/python3.
If you use the dh_python{2,3} helpers as described in [2], you generally don't
have to worry about such implementation details.
>[2] http://wiki.debian.org/Python/LibraryStyleGuide
Cheers,
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130220101303.5e141...@anarchist.wooz.org
Re: How does team maintenace of python module works?
On 02/20/2013 10:43 PM, Scott Kitterman wrote: > First, full source repositories are much larger than debian only > repositories. > I don't have a full checkout of all team packages locally, so that means if > I'm going to touch a package I don't have to download, it's more time, > bandwidth, etc. Even for a new upstream version, debian directory in the > repository and upstream tarball is still smaller. If you are modifying some packages, it's to upload them at some point. In such case, you will need the upstream tarball, right? I don't see where the waste of bandwidth is then. > Second, I think Debian packaging work and upstream's product should be > distinct in the source package. The source package is what Debian as a > project ships as the source for DFSG purposes and it should be useful. Which is why we have branches. One with the upstream code, and one with the debian folder added. Everything being contained in that debian folder. So it's really distinct. > "Here's a huge mass of code and to understand what we did to it, you need to > refer to this external repository (VCS)" is not socially acceptable to me. It's not any different to have absolutely zero upstream code in the VCS: you will need to refer to an upstream tarball, which has "a huge mass of code". > Third, I have yet to see a workflow for maintaining debian/patches in a VCS > as > part of a full source branch that was not more work than just having the > patches in a debian/patches and letting dpkg handle getting them applied/ > unapplied. Having full source branches do not prevent you from using debian/patches. I use that often, together with dpkg-source --commit and friends. If you have in debian/gbp.conf the following: [git-buildpackage] export-dir = ../build-area/ patches are applied/unapplied by git-buildpackage automatically at build time, in a separate folder, which doesn't pollute your VCS tree. So I'd say it's the same, with the added benefit of being able to use upstream commits to generate diffs. > Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to figure > out a workflow that integrates all those just seems impossible. For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and hg-fast-export). If that doesn't work, you can use the pristine-tar thing, that should always work. I never used it, probably I should learn, it seems quite convenient. Can anyone give feedback about it? By the way, I do the packaging of MLMMJ, and upstream provides both mercurial and Git, which I think is really awesome. If we could have that, and not only Git, that would be best, IMO, so that those who likes hg could use it. Last time I looked, it didn't seem so hard to setup. Probably that would be a nice addition to Alioth as well, so that any Alioth project using Mercurial would have Git too. Do you also think it would be worth asking the Fusion Forge team? > I've used partial (debian dir) VCS branches for years in both Debian and > Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at > all > to full source. WIthout full source, how do you use git-buildpackage? Could you describe your workflow so that I can understand your view as well? Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5124ea80.5080...@debian.org
Re: How does team maintenace of python module works?
On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: > On 02/20/2013 10:43 PM, Scott Kitterman wrote: > > First, full source repositories are much larger than debian only > > repositories. I don't have a full checkout of all team packages locally, > > so that means if I'm going to touch a package I don't have to download, > > it's more time, bandwidth, etc. Even for a new upstream version, debian > > directory in the repository and upstream tarball is still smaller. > > If you are modifying some packages, it's to upload them at some point. > In such case, you will need the upstream tarball, right? I don't see where > the waste of bandwidth is then. A VCS with all the upstream history will always be bigger than the tarball for just the current release. Sometimes substantially so. > > Second, I think Debian packaging work and upstream's product should be > > distinct in the source package. The source package is what Debian as a > > project ships as the source for DFSG purposes and it should be useful. > > Which is why we have branches. One with the upstream code, and one > with the debian folder added. Everything being contained in that debian > folder. So it's really distinct. You're missing my point. If it's only in the VCS, it's not in the source package. The source package needs to stand alone without the VCS to, in my opinion, properly comply with the spirit of the DFSG. > > "Here's a huge mass of code and to understand what we did to it, you need > > to refer to this external repository (VCS)" is not socially acceptable to > > me. > It's not any different to have absolutely zero upstream code in the VCS: > you will need to refer to an upstream tarball, which has "a huge mass > of code". Right, but if you embed Debian specific changes and don't use patches (as I've seen some people do who use Git) then any Debian changes to the upstream code are difficult to parse and undocumented. When you have patches, they are documented in debian/changelog and in the patch comments exactly why they are there (I know sometimes this isn't done, but it is supposed to be). > > Third, I have yet to see a workflow for maintaining debian/patches in a > > VCS as part of a full source branch that was not more work than just > > having the patches in a debian/patches and letting dpkg handle getting > > them applied/ unapplied. > > Having full source branches do not prevent you from using debian/patches. > I use that often, together with dpkg-source --commit and friends. If you > have in debian/gbp.conf the following: > > [git-buildpackage] > export-dir = ../build-area/ > > patches are applied/unapplied by git-buildpackage automatically at build > time, > in a separate folder, which doesn't pollute your VCS tree. So I'd say > it's the same, > with the added benefit of being able to use upstream commits to generate > diffs. > > > Finally, I have upstreams that use cvs, svn, bzr, and git. Trying to > > figure out a workflow that integrates all those just seems impossible. > > For all of them, you have bridges (cvs2git, git-svn, git-bzr-ng and > hg-fast-export). > If that doesn't work, you can use the pristine-tar thing, that should > always work. > I never used it, probably I should learn, it seems quite convenient. Can > anyone > give feedback about it? I've had it explained to me how to do it, done it, and then the next time I needed to do it could no longer remember it. For people that do packaging all day, every day, I think many of these tools are great, but for people like me for whom this is not the main focus of their day there's too much complexity involved to be useful. > By the way, I do the packaging of MLMMJ, and upstream provides both > mercurial > and Git, which I think is really awesome. If we could have that, and not > only Git, > that would be best, IMO, so that those who likes hg could use it. Last > time I > looked, it didn't seem so hard to setup. Probably that would be a nice > addition > to Alioth as well, so that any Alioth project using Mercurial would have > Git too. > Do you also think it would be worth asking the Fusion Forge team? > > > I've used partial (debian dir) VCS branches for years in both Debian and > > Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at > > all to full source. > > WIthout full source, how do you use git-buildpackage? Could you describe > your workflow so that I can understand your view as well? I don't. I generally unpack the upstream tarball, export the debian dir from the VCS into the unpacked tarball, update the package, build it with dpkg- buildpackage, and then commit the changes back to the VCS repository with debcommit (which is very nice since it speaks to multiple VCS through the same interface). Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/202262
Re: How does team maintenace of python module works?
On 02/20/2013 11:09 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote: > >>> You better be darn sure that upstream has excellent QA then, and that you >>> know for sure that a tag is correctly assigned to a buildable, tested, QA >>> passed snapshot of the project. >> In what way the QA is different because it's a tag instead of a tarball ? >> I don't understand your reasoning. In both cases, you must make sure >> that what you are packaging is buildable, tested, QA, etc. > Right, but it's a matter of context. If you have a release on PyPI, you know > it's been blessed. You don't need any more context. For a git tag, I have to > know what is the blessed repo url, how the tagging scheme works, what the > latest releasable snapshot is tagged, etc. I need much more context to know > what is "a release" (even though upstream might find them quaint, Debian still > does releases of packages, i.e. uploads). What if the repo url changes? What > if they start using a different tagging scheme? What if someone accidentally > assigned a release tag to a non-releasable revision? For the packages which I worked on, there was always a Git URL in PiPY, and I didn't have any of the issues you're talking about above. I'm not saying it can ever happen, but only that I see no difference with making a tarball: in both cases, you can do mistakes, can't find the correct URL and have it changed, etc. I haven't yet met a "context" problem like you describe above, but truth, I have seen multiple tagging scheme, the most reoccurring one being to add a "v" in front of the version number (which is easily worked around in the gbp.conf). > That might not be so important for someone who has intimate and ongoing > knowledge of package maintenance, but it's really important for team > maintained packages where I might have to fix a bug or grab a new upstream for > a package you primarily maintain. Team members can read debian/copyright, where you have the Source: field. >> With many PiPY projects, I can see that the generated tarball are the >> exact same thing as what's tagged in the Git repository. Often, the >> release process is automated so the tag and the tarball are released >> at once. This has been the case, for example, for: >> >> - python-pecan (https://github.com/dreamhost/pecan) >> - python-json-patch (https://github.com/stefankoegl/python-json-patch) >> - python-json-pointer (https://github.com/stefankoegl/python-json-pointer) >> - python-tablib (https://github.com/kennethreitz/tablib) >> - cliff-tablib (https://github.com/dreamhost/cliff-tablib) >> - python-warlock (https://github.com/bcwaldon/warlock) > That's great, but I bet it's a minority of projects on PyPI. Like you, I have no stats available, so I can't tell. But for me, that was a vast majority of the packages I worked on. Anyway, I'm not asking anyone to follow my workflow, I was merely explaining what I've been doing, and what I was very happy with. It might indeed only work for a group of packages only. Do you guys think we should only have *one type* of workflow? I wouldn't mind switching to some different way of doing things if the team finds it relevant, and if it is more easy and unified across all packages. If so, please tell how you would like to work. We would loose most of the cool features I was used to, but so be it... Cheers, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512504bf.3060...@debian.org
Re: How does team maintenace of python module works?
On 02/20/2013 11:45 PM, Scott Kitterman wrote: > On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: >> On 02/20/2013 10:43 PM, Scott Kitterman wrote: >>> First, full source repositories are much larger than debian only >>> repositories. I don't have a full checkout of all team packages locally, >>> so that means if I'm going to touch a package I don't have to download, >>> it's more time, bandwidth, etc. Even for a new upstream version, debian >>> directory in the repository and upstream tarball is still smaller. >> If you are modifying some packages, it's to upload them at some point. >> In such case, you will need the upstream tarball, right? I don't see where >> the waste of bandwidth is then. > A VCS with all the upstream history will always be bigger than the tarball > for > just the current release. Sometimes substantially so. But you only very rarely clone from scratch, and only get some incremental changes. While with tarballs, you always have to get the full of it. > >>> Second, I think Debian packaging work and upstream's product should be >>> distinct in the source package. The source package is what Debian as a >>> project ships as the source for DFSG purposes and it should be useful. >> Which is why we have branches. One with the upstream code, and one >> with the debian folder added. Everything being contained in that debian >> folder. So it's really distinct. > You're missing my point. If it's only in the VCS, it's not in the source > package. The source package needs to stand alone without the VCS to, in my > opinion, properly comply with the spirit of the DFSG. It's funny that you say it this way. I've read some other opinion saying that with the tarball, you're missing lots of information from upstream. That person went up to say that he thought it'd be a good idea to package the git repository as source package (sorry, I can't remember who and when, just that it was in -devel@l.d.o). I quite agree with this view. >>> "Here's a huge mass of code and to understand what we did to it, you need >>> to refer to this external repository (VCS)" is not socially acceptable to >>> me. >> It's not any different to have absolutely zero upstream code in the VCS: >> you will need to refer to an upstream tarball, which has "a huge mass >> of code". > Right, but if you embed Debian specific changes and don't use patches That's not what I do. > I know sometimes this isn't done, but it is supposed to be I agree it's a bad idea, so we are on the same line. > I generally unpack the upstream tarball, export the debian dir from > the VCS into the unpacked tarball, update the package, build it with dpkg- > buildpackage, and then commit the changes back to the VCS repository with > debcommit (which is very nice since it speaks to multiple VCS through the > same > interface). So, basically, you're doing all by hand... That's very tedious. IMO, the whole point of using git (or any other VCS), is to use either git-buildpackage, or "git-stuff" (that's a package name...), so you have tools to do all this manual boring work. git-stuff works the opposite way. You'd do all the changes in your packaging, then it would write the debian/changelog based on the commit messages. I find it a lot better, because then you can have a history of you changes, do rebase, squashes, cancel, etc. without the risk to loose any of your changes. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51250a67.1060...@debian.org
Re: How does team maintenace of python module works?
[Thomas Goirand, 2013-02-20] > I wouldn't > mind switching to some different way of doing things if the team finds it > relevant, and if it is more easy and unified across all packages. If so, > please tell how you would like to work. We would loose most of the cool > features I was used to, but so be it... does git-buildpackage work with git submodules (with debian dir as a separate git repo)? -- 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: How does team maintenace of python module works?
Den 20. feb. 2013 16:23, skreiv Thomas Goirand: If that doesn't work, you can use the pristine-tar thing, that should always work. I never used it, probably I should learn, it seems quite convenient. Can anyone give feedback about it? My workflow for anything outside of this team and not intended for Ubuntu directly is with git and a full source branch. I don't package often enough to remember everything from time to time, but it's no more than a quick google search away. Roughly the workflow is to use uscan to download the source tarball, git-import-orig with pristine tar to import upstream code into upstream branch. git-import-orig handles committing an tagging necessary changes. Using quilt I can then modyfi anything I like in the source directories, and quilt will keep every change in the debian/patches folder. If I accidentally touch anything not handled by quilt this is easily reverted with a single-file checkout. When I'm happy with the changes I build the package using git-buildpackage (--git-ignore-new if I want to test before commit) --git-builder=pdebuild. Once I'm ready to upload the debian release commit is tagged. Because of pristine tar, the upstream release tarball can be recreated from the upstream branch, and everybody should be happy. IMHO patching and patch handling is way easier in git than in svn, mostly because I never copy or export anything to create and test the patches. I totally agree that all changes to the source should be kept as patches. Regards Andreas Noteng -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/512506c1.8030...@noteng.no
Re: How does team maintenace of python module works?
Thomas Goirand wrote: >On 02/20/2013 11:45 PM, Scott Kitterman wrote: >> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote: >>> On 02/20/2013 10:43 PM, Scott Kitterman wrote: First, full source repositories are much larger than debian only repositories. I don't have a full checkout of all team packages >locally, so that means if I'm going to touch a package I don't have to >download, it's more time, bandwidth, etc. Even for a new upstream version, >debian directory in the repository and upstream tarball is still smaller. >>> If you are modifying some packages, it's to upload them at some >point. >>> In such case, you will need the upstream tarball, right? I don't see >where >>> the waste of bandwidth is then. >> A VCS with all the upstream history will always be bigger than the >tarball for >> just the current release. Sometimes substantially so. > >But you only very rarely clone from scratch, and only get some >incremental changes. >While with tarballs, you always have to get the full of it. I don't keep local copies of things I don't work on regularly, so for team packages I would be downloading all of it. >> Second, I think Debian packaging work and upstream's product should >be distinct in the source package. The source package is what Debian >as a project ships as the source for DFSG purposes and it should be >useful. >>> Which is why we have branches. One with the upstream code, and one >>> with the debian folder added. Everything being contained in that >debian >>> folder. So it's really distinct. >> You're missing my point. If it's only in the VCS, it's not in the >source >> package. The source package needs to stand alone without the VCS to, >in my >> opinion, properly comply with the spirit of the DFSG. > >It's funny that you say it this way. I've read some other opinion >saying >that with the >tarball, you're missing lots of information from upstream. That person >went up to >say that he thought it'd be a good idea to package the git repository >as >source >package (sorry, I can't remember who and when, just that it was in >-devel@l.d.o). >I quite agree with this view. Right. Someday there may be a source format git, but until then ... "Here's a huge mass of code and to understand what we did to it, >you need to refer to this external repository (VCS)" is not socially >acceptable to me. >>> It's not any different to have absolutely zero upstream code in the >VCS: >>> you will need to refer to an upstream tarball, which has "a huge >mass >>> of code". >> Right, but if you embed Debian specific changes and don't use patches > >That's not what I do. > >> I know sometimes this isn't done, but it is supposed to be > >I agree it's a bad idea, so we are on the same line. > >> I generally unpack the upstream tarball, export the debian dir from >> the VCS into the unpacked tarball, update the package, build it with >dpkg- >> buildpackage, and then commit the changes back to the VCS repository >with >> debcommit (which is very nice since it speaks to multiple VCS through >the same >> interface). >So, basically, you're doing all by hand... That's very tedious. IMO, >the >whole >point of using git (or any other VCS), is to use either >git-buildpackage, or >"git-stuff" (that's a package name...), so you have tools to do all >this >manual >boring work. git-stuff works the opposite way. You'd do all the changes >in >your packaging, then it would write the debian/changelog based on the >commit messages. I find it a lot better, because then you can have a >history >of you changes, do rebase, squashes, cancel, etc. without the risk to >loose >any of your changes. I've done the boring bits enough that my fingers mostly do them without much attention from my brain. If I were going to abandon my current approach, I'd have to see significant advantages for a new way and I don't. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/609b9744-397f-46a0-996a-e6d39cb86...@email.android.com
Re: How does team maintenace of python module works?
On Wed, Feb 20, 2013 at 06:43:11PM +0100, Piotr Ożarowski wrote: > [Thomas Goirand, 2013-02-20] > > I wouldn't > > mind switching to some different way of doing things if the team finds it > > relevant, and if it is more easy and unified across all packages. If so, > > please tell how you would like to work. We would loose most of the cool > > features I was used to, but so be it... > > does git-buildpackage work with git submodules (with debian dir as a > separate git repo)? FWIW, there is probably a way to implement the same idea with mercurial's subrepo or guestrepo. http://mercurial.selenic.com/wiki/Subrepository http://mercurial.selenic.com/wiki/GuestrepoExtension PS: No, I don't have time to do the work, hence I just mention it exists. -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130220214620.gb13...@volans.logilab.fr
Re: How does team maintenace of python module works?
On 19 February 2013 23:49, Ludovic Gasc wrote: > > On Feb 19, 2013 11:21 PM, "Barry Warsaw" wrote: >> >> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote: >> > > I can do that this week-end. I've only a github account to publish the git > repository, unless somebody else has an access for a better place? For a > test, I think that github is enough. > Using github would be against the basic principles laid out in the Debian Social Contract. While gitorious hosted solution, would be ok it reimplements the git server & protocol and hence lacks many features. It is best to continue to use excellent hosting facilities provided by git.debian.org / alioth.debian.org. One can create repositories in a home directory (please don't use official team account / group names) which would be good enough for maintainance. Having an gerrit instance would help a lot to serve merge requests functionality. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlugvhb5fv3srj+dojsvit+1hordojkuafzbgeolhx5+...@mail.gmail.com
Re: How does team maintenace of python module works?
On 21/02/2013 01:43, Piotr Ożarowski wrote: > does git-buildpackage work with git submodules (with debian dir as a > separate git repo)? It should. I wrote the initial patch for submodule support in git-buildpackage. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 20/02/2013 23:45, Scott Kitterman wrote:
> On Wednesday, February 20, 2013 11:23:44 PM Thomas Goirand wrote:
> [...]
>> If you are modifying some packages, it's to upload them at some point.
>> In such case, you will need the upstream tarball, right? I don't see where
>> the waste of bandwidth is then.
>
> A VCS with all the upstream history will always be bigger than the tarball
> for
> just the current release. Sometimes substantially so.
Not always. Text compresses easily, so it is not uncommon for the .git to be
smaller than a single uncompressed checkout of the tarball. And with
pristine-tar, you end up having every single tarball in history contained in
that .git directory.
>>> Second, I think Debian packaging work and upstream's product should be
>>> distinct in the source package. The source package is what Debian as a
>>> project ships as the source for DFSG purposes and it should be useful.
>>
>> Which is why we have branches. One with the upstream code, and one
>> with the debian folder added. Everything being contained in that debian
>> folder. So it's really distinct.
>
> You're missing my point. If it's only in the VCS, it's not in the source
> package. The source package needs to stand alone without the VCS to, in my
> opinion, properly comply with the spirit of the DFSG.
In the pkg-cli-{apps,libs}, we keep upstream history separate from downstream
history. Only the tarballs are imported, and that is done using git import-orig
--pristine-tar. Patches are maintained using gbp-pq or quilt. At the end of the
day, there isn't anything that only lives in the VCS.
>>> "Here's a huge mass of code and to understand what we did to it, you need
>>> to refer to this external repository (VCS)" is not socially acceptable to
>>> me.
>> It's not any different to have absolutely zero upstream code in the VCS:
>> you will need to refer to an upstream tarball, which has "a huge mass
>> of code".
>
> Right, but if you embed Debian specific changes and don't use patches (as
> I've
> seen some people do who use Git) then any Debian changes to the upstream code
> are difficult to parse and undocumented. When you have patches, they are
> documented in debian/changelog and in the patch comments exactly why they are
> there (I know sometimes this isn't done, but it is supposed to be).
Actually, with git-buildpackage, there's a gbp-pq tool which allows you to
import a quilt series of patches into a temporary patch-queue/$branch in git,
allowing you to use git rebase and whatever other git tools you have to figure
out what changes go where. After which, they can be exported into debian/patches
again and committed.
> [...]
> I've had it explained to me how to do it, done it, and then the next time I
> needed to do it could no longer remember it. For people that do packaging
> all
> day, every day, I think many of these tools are great, but for people like me
> for whom this is not the main focus of their day there's too much complexity
> involved to be useful.
That argument applies to any VCS that you don't use on a daily basis. You use
bzr on a daily basis and forget how to use git. I use git on a daily basis and
forget how to use svn/bzr and have to relearn it any time someone forces me to
use one of those. I don't think this is a valid reason for avoiding git.
>> By the way, I do the packaging of MLMMJ, and upstream provides both
>> mercurial
>> and Git, which I think is really awesome. If we could have that, and not
>> only Git,
>> that would be best, IMO, so that those who likes hg could use it. Last
>> time I
>> looked, it didn't seem so hard to setup. Probably that would be a nice
>> addition
>> to Alioth as well, so that any Alioth project using Mercurial would have
>> Git too.
>> Do you also think it would be worth asking the Fusion Forge team?
>>
>>> I've used partial (debian dir) VCS branches for years in both Debian and
>>> Ubuntu (where it's bzr, so I've used a DVCS) and I don't see any upside at
>>> all to full source.
>>
>> WIthout full source, how do you use git-buildpackage? Could you describe
>> your workflow so that I can understand your view as well?
>
> I don't. I generally unpack the upstream tarball, export the debian dir from
> the VCS into the unpacked tarball, update the package, build it with dpkg-
> buildpackage, and then commit the changes back to the VCS repository with
> debcommit (which is very nice since it speaks to multiple VCS through the
> same
> interface).
That sounds like awful lot of steps to take. My workflow only involves editing
things directly in the git repository, and then running git-buildpackage to
build. With the export-dir option that I have set in ~/.gbp.conf, that
automatically exports it out to ../build-area/ and builds on the spot.
Committing can be done with debcommit or any other method of committing into a
git repository.
--
Kind regards,
Loong Jin
signature.asc
Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 01:59, Scott Kitterman wrote: > I've done the boring bits enough that my fingers mostly do them without much > attention from my brain. If I were going to abandon my current approach, I'd > have to see significant advantages for a new way and I don't. Somehow I can only read this as: "I've done things manually all this while and it works for me, so go away and don't bother me because I don't see any advantages in having things automated." -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On Feb 21, 2013, at 11:08 AM, Chow Loong Jin wrote: >That argument applies to any VCS that you don't use on a daily basis. You use >bzr on a daily basis and forget how to use git. I use git on a daily basis and >forget how to use svn/bzr and have to relearn it any time someone forces me to >use one of those. I don't think this is a valid reason for avoiding git. As you say, this is true of any tool you use only intermittently. Here's a fairly good example of the kind of documentation that I think helps bridge the gap. It's for Python developers using the Mercurial repo, but it's more than that. It describes the common hg commands in the context of the workflow that core Python committers use. http://docs.python.org/devguide/committing.html I can never remember how to do a null merge, but this section answers the question nicely: http://docs.python.org/devguide/committing.html?highlight=null%20merge#porting-within-a-major-version Cheers, -Barry signature.asc Description: PGP signature
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote: > On 21/02/2013 01:59, Scott Kitterman wrote: > > I've done the boring bits enough that my fingers mostly do them without > > much attention from my brain. If I were going to abandon my current > > approach, I'd have to see significant advantages for a new way and I > > don't. > > Somehow I can only read this as: "I've done things manually all this while > and it works for me, so go away and don't bother me because I don't see any > advantages in having things automated." If the automation actually made things easier, I'd be in favor of it. I used to manually tag uploads in svn for DPMT/PAPT because I didn't trust svn- buildpackage. Then I learned it a bit better and started using it because it was easier. Then I learned debcommit -r -R and it was even easier. I'm all for easy. I have yet to see a full source (regardless of VCS) or git workflow that I didn't find more complex and harder to remember/do correctly than what we have now. I really don't care about what the new hotness is. It actually needs to be better and not just cooler. For me, a lot of better is simpler. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1662015.k84YxWKh5C@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote: ... > That argument applies to any VCS that you don't use on a daily basis. You > use bzr on a daily basis and forget how to use git. I use git on a daily > basis and forget how to use svn/bzr and have to relearn it any time someone > forces me to use one of those. I don't think this is a valid reason for > avoiding git. ... It is to a degree, but the learning curve for git is subtantially steeper than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another and there is no question in my mind which one, by a lot, is the most complex to learn. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027781.JVGg8X73QH@scott-latitude-e6320
Re: How does team maintenace of python module works?
On 21/02/2013 11:58, Scott Kitterman wrote: > On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote: >> On 21/02/2013 01:59, Scott Kitterman wrote: >>> I've done the boring bits enough that my fingers mostly do them without >>> much attention from my brain. If I were going to abandon my current >>> approach, I'd have to see significant advantages for a new way and I >>> don't. >> >> Somehow I can only read this as: "I've done things manually all this while >> and it works for me, so go away and don't bother me because I don't see any >> advantages in having things automated." > > If the automation actually made things easier, I'd be in favor of it. I used > to manually tag uploads in svn for DPMT/PAPT because I didn't trust svn- > buildpackage. Then I learned it a bit better and started using it because it > was easier. Then I learned debcommit -r -R and it was even easier. > > I'm all for easy. I have yet to see a full source (regardless of VCS) or git > workflow that I didn't find more complex and harder to remember/do correctly > than what we have now. I really don't care about what the new hotness is. > It > actually needs to be better and not just cooler. For me, a lot of better is > simpler. Update package: - edit - debcommit -a - git buildpackage (--git-builder="sbuild -d $distribution") Tagging: - git buildpackage --git-tag (or --git-tag-only if you've already built) Import new orig tarball: - git import-orig $tarball Cloning repository: - gbp-clone git://git.debian.org/….git Updating repository: - gbp-pull Looks simple enough to me. How much simpler do you want it? -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On 21/02/2013 12:02, Scott Kitterman wrote: > It is to a degree, but the learning curve for git is subtantially steeper > than > for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another > and > there is no question in my mind which one, by a lot, is the most complex to > learn. I'll admit that git isn't the simplest one, the others are not perfect either. To this day, I can't for the life of me figure out how to use CVS. Thank goodness git-cvsimport works. SVN is simple enough, but so is git when used with only linear history. But let's not forget the horrible hack that is svn tagging/branching. Bzr is simple enough as well, but $deity help you when you get incompatible pack format repositories, or when bzr suddenly decides that your branches have diverged for no apparent reason whatsoever. At least with git, you know when you've rewritten history -- you're no longer on the same commit. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote: >It is to a degree, but the learning curve for git is subtantially steeper >than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or >another and there is no question in my mind which one, by a lot, is the most >complex to learn. No one's accusing git of actually being user friendly. http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ -Barry signature.asc Description: PGP signature
Re: How does team maintenace of python module works?
On Feb 21, 2013, at 12:15 PM, Chow Loong Jin wrote: >I'll admit that git isn't the simplest one, the others are not perfect either. >To this day, I can't for the life of me figure out how to use CVS. Thank >goodness git-cvsimport works. Of course, CVS is 20+ years old so its ancient model is working against you. >SVN is simple enough, but so is git when used with only linear history. But >let's not forget the horrible hack that is svn tagging/branching. True, but also not much of a mental stretch when you realize it's just creating new directories in the repo. >Bzr is simple enough as well, but $deity help you when you get incompatible >pack format repositories Mostly not an issue any more, since 2a format has been the only sane format to use for a few years now. Yes, you do run into old branch formats now and then. Sigh. >, or when bzr suddenly decides that your branches have diverged for no >apparent reason whatsoever. I agree with this one. It's a real problem with UDD when you have both an upstream branch (e.g. lp:foo) and a packaging branch (e.g. ubuntu:foo). >At least with git, you know when you've rewritten history -- you're no longer >on the same commit. #9 on Steve Bennett's list is right on target IMHO, but I've had this discussion so many times before, I don't have much energy for it again. """ 9. Git history is a bunch of lies The primary output of development work should be source code. Is a well-maintained history really such an important by-product? Most of the arguments for rebase, in particular, rely on aesthetic judgments about “messy merges” in the history, or “unreadable logs”. So rebase encourages you to lie in order to provide other developers with a “clean”, “uncluttered” history. Surely the correct solution is a better log output that can filter out these unwanted merges. """ Cheers, -Barry signature.asc Description: PGP signature
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 12:08:45 PM Chow Loong Jin wrote: > On 21/02/2013 11:58, Scott Kitterman wrote: > > On Thursday, February 21, 2013 11:12:58 AM Chow Loong Jin wrote: > >> On 21/02/2013 01:59, Scott Kitterman wrote: > >>> I've done the boring bits enough that my fingers mostly do them without > >>> much attention from my brain. If I were going to abandon my current > >>> approach, I'd have to see significant advantages for a new way and I > >>> don't. > >> > >> Somehow I can only read this as: "I've done things manually all this > >> while > >> and it works for me, so go away and don't bother me because I don't see > >> any > >> advantages in having things automated." > > > > If the automation actually made things easier, I'd be in favor of it. I > > used to manually tag uploads in svn for DPMT/PAPT because I didn't trust > > svn- buildpackage. Then I learned it a bit better and started using it > > because it was easier. Then I learned debcommit -r -R and it was even > > easier. > > > > I'm all for easy. I have yet to see a full source (regardless of VCS) or > > git workflow that I didn't find more complex and harder to remember/do > > correctly than what we have now. I really don't care about what the new > > hotness is. It actually needs to be better and not just cooler. For me, > > a lot of better is simpler. > > Update package: > - edit > - debcommit -a > - git buildpackage (--git-builder="sbuild -d $distribution") > > Tagging: > - git buildpackage --git-tag (or --git-tag-only if you've already built) > > Import new orig tarball: > - git import-orig $tarball > > Cloning repository: > - gbp-clone git://git.debian.org/….git > > Updating repository: > - gbp-pull > > Looks simple enough to me. How much simpler do you want it? With git (I've never used gpb, and maybe that's my problem) I end up having to do things like: git clone git://git.debian.org/….git for branch in pristine-tar debian/unstable ; do git branch --track $branch origin/$branch ; done That's the sort of thing that convinces me it's too hard. The fact that I have to manually make the association between individual local and remove branches is just insane. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4940572.qY1k9Flhxp@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Thu, Feb 21, 2013 at 12:37 PM, Scott Kitterman wrote: > That's the sort of thing that convinces me it's too hard. The fact that I > have to manually make the association between individual local and remove > branches is just insane. This has changed with git from experimental, it sets up the association by default for remote branches and gives you an option to turn it off or turn it on for local branches too. Theres an option to set branches to use rebase by default too. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6h9n-saggbhr6tydeddtqqsbqyufmxhtenn7vo+uh_...@mail.gmail.com
Re: How does team maintenace of python module works?
(Re-posted back on list. Sorry ScottK.) On 21/02/2013 12:37, Scott Kitterman wrote: > With git (I've never used gpb, and maybe that's my problem) I end up having > to > do things like: > > git clone git://git.debian.org/….git > for branch in pristine-tar debian/unstable ; do git branch --track $branch > origin/$branch ; done > > That's the sort of thing that convinces me it's too hard. The fact that I > have to manually make the association between individual local and remove > branches is just insane. That's what gbp-clone does for you -- it clones, and creates master/pristine-tar/upstream. pristine-tar is the most important, because if this branch isn't present then git-buildpackage silently builds a brand new tarball for you. Aside from that, git (as of 1.7.10.4, not sure when it was introduced) also automatically does that set up for you when you git checkout $branch where $branch doesn't exist but origin/$branch does. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On Wednesday, February 20, 2013 11:46:31 PM Barry Warsaw wrote: > >At least with git, you know when you've rewritten history -- you're no > >longer on the same commit. > > #9 on Steve Bennett's list is right on target IMHO, but I've had this > discussion so many times before, I don't have much energy for it again. > > """ > 9. Git history is a bunch of lies > The primary output of development work should be source code. Is a > well-maintained history really such an important by-product? Most of the > arguments for rebase, in particular, rely on aesthetic judgments about > “messy merges” in the history, or “unreadable logs”. So rebase encourages > you to lie in order to provide other developers with a “clean”, > “uncluttered” history. Surely the correct solution is a better log output > that can filter out these unwanted merges. > """ Agreed. I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to be able to find it 4 years later). Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4870622.bsvUB0WW7U@scott-latitude-e6320
Re: How does team maintenace of python module works?
On 02/21/2013 12:32 PM, Barry Warsaw wrote: > On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote: > >> It is to a degree, but the learning curve for git is subtantially steeper >> than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or >> another and there is no question in my mind which one, by a lot, is the most >> complex to learn. > No one's accusing git of actually being user friendly. > > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ > > -Barry Some of the points in this page are really wrong. Like in the point 6, 7, 8 and 9, the author didn't understand at all the necessity of having fast-forward history when a project scales up, with lots of contributors. Then finally, I agree, the only thing that remains is the complexity. :) Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5125b737.4030...@debian.org
Re: How does team maintenace of python module works?
Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit : > On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote: > ... > > That argument applies to any VCS that you don't use on a daily basis. You > > use bzr on a daily basis and forget how to use git. I use git on a daily > > basis and forget how to use svn/bzr and have to relearn it any time someone > > forces me to use one of those. I don't think this is a valid reason for > > avoiding git. > ... > > It is to a degree, but the learning curve for git is subtantially steeper > than > for other VCS. I've learned CVS, SVN, BZR, and Git at one time or another > and > there is no question in my mind which one, by a lot, is the most complex to > learn. Dear Scott, I undertand that learning Git after BZR is hard, because learning BZR after Git is equally painful. I think that the key difficulty is whether a system is learned first or second, not the system itself. This is where git-buildpackage is nice, as it re-implements the same user experience as with svn-buildpackage, and therefore provides some kind of upgrade path. Cheers, -- Charles Plessy -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130221060056.ga1...@falafel.plessy.net
Re: How does team maintenace of python module works?
On 21/02/2013 12:46, Barry Warsaw wrote: > #9 on Steve Bennett's list is right on target IMHO, but I've had this > discussion so many times before, I don't have much energy for it again. > > """ > 9. Git history is a bunch of lies > The primary output of development work should be source code. Is a > well-maintained history really such an important by-product? Most of the > arguments for rebase, in particular, rely on aesthetic judgments about “messy > merges” in the history, or “unreadable logs”. So rebase encourages you to lie > in order to provide other developers with a “clean”, “uncluttered” > history. Surely the correct solution is a better log output that can filter > out these unwanted merges. > """ Well, rebasing aside, my main reason for rewriting history is to ensure that each commit is properly separated so that if I ever need something specific reverted, I can just git revert and take out that particular change instead of having to pick aside the appropriate change from inside the commit. git-bisect also works a lot better if your commits are "clean" and "uncluttered". -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 01:57:11 PM Thomas Goirand wrote: > On 02/21/2013 12:32 PM, Barry Warsaw wrote: > > On Feb 20, 2013, at 11:02 PM, Scott Kitterman wrote: > >> It is to a degree, but the learning curve for git is subtantially steeper > >> than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or > >> another and there is no question in my mind which one, by a lot, is the > >> most complex to learn. > > > > No one's accusing git of actually being user friendly. > > > > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ > > > > -Barry > > Some of the points in this page are really wrong. > Like in the point 6, 7, 8 and 9, the author didn't understand > at all the necessity of having fast-forward history when > a project scales up, with lots of contributors. > > Then finally, I agree, the only thing that remains is the > complexity. :) If by scales up, you mean the Linux kernel, sure. I agree, but for something the complexity of DPMT/PAPT where there don't tend to be lots of committers on the same package, they are valid. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1800697.fkr4dhOjoz@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 03:00:56 PM Charles Plessy wrote: > Le Wed, Feb 20, 2013 at 11:02:15PM -0500, Scott Kitterman a écrit : > > On Thursday, February 21, 2013 11:08:13 AM Chow Loong Jin wrote: > > ... > > > > > That argument applies to any VCS that you don't use on a daily basis. > > > You > > > use bzr on a daily basis and forget how to use git. I use git on a daily > > > basis and forget how to use svn/bzr and have to relearn it any time > > > someone > > > forces me to use one of those. I don't think this is a valid reason for > > > avoiding git. > > > > ... > > > > It is to a degree, but the learning curve for git is subtantially steeper > > than for other VCS. I've learned CVS, SVN, BZR, and Git at one time or > > another and there is no question in my mind which one, by a lot, is the > > most complex to learn. > > Dear Scott, > > I undertand that learning Git after BZR is hard, because learning BZR after > Git is equally painful. I think that the key difficulty is whether a > system is learned first or second, not the system itself. > > This is where git-buildpackage is nice, as it re-implements the same user > experience as with svn-buildpackage, and therefore provides some kind of > upgrade path. I disagree. Learning git is harder than all the others. It doesn't matter what order you learn them in. If you look at the figures in point 10 of http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ (you can largely substitute bzr for svn there and it won't get any more complex) and tell me those are of equal complexity. For all it's power, the git U/I is just inconsistent and counter intuitive. If you use it routinely, you get so you remember it and it seems easy. If you don't, you have to re-climb up the learning curve each time. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2329294.DFZBjWhh24@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 01:52:59 PM Chow Loong Jin wrote: > (Re-posted back on list. Sorry ScottK.) > > On 21/02/2013 12:37, Scott Kitterman wrote: > > With git (I've never used gpb, and maybe that's my problem) I end up > > having to do things like: > > > > git clone git://git.debian.org/….git > > for branch in pristine-tar debian/unstable ; do git branch --track $branch > > origin/$branch ; done > > > > That's the sort of thing that convinces me it's too hard. The fact that I > > have to manually make the association between individual local and remove > > branches is just insane. > > That's what gbp-clone does for you -- it clones, and creates > master/pristine-tar/upstream. pristine-tar is the most important, because if > this branch isn't present then git-buildpackage silently builds a brand new > tarball for you. > > Aside from that, git (as of 1.7.10.4, not sure when it was introduced) also > automatically does that set up for you when you git checkout $branch where > $branch doesn't exist but origin/$branch does. That's progress. Of course you still need to know to do git branch -r to see what the remote branches are named since git branch still won't know about them. Maybe in another decade it'll be half way usable for people whose life doesn't revolve around git. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4089658.34RS1eJNab@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Thursday, February 21, 2013 02:02:09 PM Chow Loong Jin wrote: > On 21/02/2013 12:46, Barry Warsaw wrote: > > #9 on Steve Bennett's list is right on target IMHO, but I've had this > > discussion so many times before, I don't have much energy for it again. > > > > """ > > 9. Git history is a bunch of lies > > The primary output of development work should be source code. Is a > > well-maintained history really such an important by-product? Most of the > > arguments for rebase, in particular, rely on aesthetic judgments about > > “messy merges” in the history, or “unreadable logs”. So rebase encourages > > you to lie in order to provide other developers with a “clean”, > > “uncluttered” history. Surely the correct solution is a better log output > > that can filter out these unwanted merges. > > """ > > Well, rebasing aside, my main reason for rewriting history is to ensure that > each commit is properly separated so that if I ever need something specific > reverted, I can just git revert and take out that particular change instead > of having to pick aside the appropriate change from inside the commit. > git-bisect also works a lot better if your commits are "clean" and > "uncluttered". I've tried doing this. Then I looked back and noticed that I was spending a LOT of time making the VCS pretty, just in case and rarely had to revert anything. It turned out I was spending a lot of time to save a little time and that's just not path to being productive. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2844385.4hKU8VhLLv@scott-latitude-e6320
Re: How does team maintenace of python module works?
On Feb 20, 2013 11:57 PM, "Dmitrijs Ledkovs" wrote: > > On 19 February 2013 23:49, Ludovic Gasc wrote: > > > > On Feb 19, 2013 11:21 PM, "Barry Warsaw" wrote: > >> > >> On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote: > >> > > > > I can do that this week-end. I've only a github account to publish the git > > repository, unless somebody else has an access for a better place? For a > > test, I think that github is enough. > > > > Using github would be against the basic principles laid out in the > Debian Social Contract. > While gitorious hosted solution, would be ok it reimplements the git > server & protocol and hence lacks many features. > It is best to continue to use excellent hosting facilities provided by > git.debian.org / alioth.debian.org. > One can create repositories in a home directory (please don't use > official team account / group names) which would be good enough for > maintainance. Ok, I'll use it this week-end. > > Having an gerrit instance would help a lot to serve merge requests > functionality. > > Regards, > > Dmitrijs.
Re: How does team maintenace of python module works?
On 02/21/2013 01:36 PM, Scott Kitterman wrote: > Agreed. > > I always liked this one http://netsplit.com/2009/02/17/git-sucks/ (enough to > be able to find it 4 years later). > > Scott K Lucky, 4 years later, the error messages of Git are much much more helpful than they used to be (in fact, since version >= 1.7). Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5125c34b.2030...@debian.org
Re: How does team maintenace of python module works?
On 02/21/2013 02:29 PM, Scott Kitterman wrote: > I've tried doing this. Then I looked back and noticed that I was spending a > LOT of time making the VCS pretty, just in case and rarely had to revert > anything. It turned out I was spending a lot of time to save a little time > and that's just not path to being productive. > > Scott K If you are working alone, probably. If you are working with a team, that's a different story. Having a very dirty commit history with changes going back and forth is just horrible and makes it very hard to follow. Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5125c3e1.7050...@debian.org
Re: How does team maintenace of python module works?
On Thu, 2013-02-21 at 12:08 +0800, Chow Loong Jin wrote: > On 21/02/2013 11:58, Scott Kitterman wrote: > > I'm all for easy. I have yet to see a full source (regardless of VCS) or > > git > > workflow that I didn't find more complex and harder to remember/do > > correctly > > than what we have now. I really don't care about what the new hotness is. > > It > > actually needs to be better and not just cooler. For me, a lot of better > > is > > simpler. > > Update package: > - edit > - debcommit -a > - git buildpackage (--git-builder="sbuild -d $distribution") > > Tagging: > - git buildpackage --git-tag (or --git-tag-only if you've already built) > > Import new orig tarball: > - git import-orig $tarball > > Cloning repository: > - gbp-clone git://git.debian.org/….git > > Updating repository: > - gbp-pull > > Looks simple enough to me. How much simpler do you want it? Why not document the workflow (or any other workflow in Debian for that matter) by means of an executable Makefile with targets like: help: egrep ^#DOC Makefile template: # Build a script which the user will edit replacing # keywords by package name etc. # The script will invoke this Makefile with the right # values in environmental variables update: debcommit -a ... git buildpackage ... tag: git buildpackage --git-tag import: # Set the $tarball environment variable git import-orig $tarball etc. etc. --- Omer -- Make love not war. More cleavage, less carnage. My own blog is at http://www.zak.co.il/tddpirate/ My opinions, as expressed in this E-mail message, are mine alone. They do not represent the official policy of any organization with which I may be affiliated in any way. WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1361428448.20304.186.camel@c4
Re: How does team maintenace of python module works?
On 02/21/2013 02:26 PM, Scott Kitterman wrote: > >> I undertand that learning Git after BZR is hard, because learning BZR after >> Git is equally painful. I think that the key difficulty is whether a >> system is learned first or second, not the system itself. >> >> This is where git-buildpackage is nice, as it re-implements the same user >> experience as with svn-buildpackage, and therefore provides some kind of >> upgrade path. > I disagree. Learning git is harder than all the others. It doesn't matter > what order you learn them in. If you look at the figures in point 10 of > http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ (you can > largely substitute bzr for svn there and it won't get any more complex) and > tell me those are of equal complexity. > > For all it's power, the git U/I is just inconsistent and counter intuitive. > If you use it routinely, you get so you remember it and it seems easy. If > you > don't, you have to re-climb up the learning curve each time. > > Scott K I've learn first CVS. Then switch to Git. Then when I tried to learn bzr, it was quite hard (and now I can't remember it at all). I always found SVN something of the past, hard to use and stupid, because I never took the time to learn it correctly (and in full honesty, I don't think I should, as there are way better VCS out there). But I perfectly know this comes *from me* and not the tool itself, which I know shouldn't be harder to use than CVS, which I used for years. So I deeply agree with Charles here. Also, for this point 10, the author completely skipped alltogether the very reason why Git needs more commands: because it doesn't do network access all the time. Only when you ask it to do so. And because I worked with launchpad BZR from China, with about 5 KB/s of bandwidth to it available (when I could connect at all...), I can tell you that it is really important. Lucky, launchpad.com has nicer connectivity now, but that's not what I'm debating. With BZR, I wouldn't be able to work in the train without my 3G connection opened... This debate can go on, and on, and on forever. It will go nowhere. We got the point that you find Git difficult, and like bzr more. I don't think posting such wrong argumentation helps. Moreover, ease of use is *not* the main point of any software (it does seem to me that this is your main point). Sometimes, convenience means that you do need to learn to later be more efficient. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5125c80a.6090...@debian.org
