Re: numpy 1.2.1, switching to git?
Hi Sandro, thanks for the points, I reacted to some. On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi wrote: >> P.S. bzed, POX, isn't it time to move our packaging to git? > > I'm none of them, but I'll speak anyway :) Buxy almost did my point, > I'd like to express me a bit. > > To do a change into something different we need a reason: what's the > reason for moving from svn to git? is it because it's cool? (I hope > not ;) ) is it because it has some features missing in svn? maybe, but > which ones? something else? Yes, distributed version control system has many features that are missing in svn (=that I am missing in svn), mainly that I can easily fiddle with different approaches and branches locally, that I can easily upload my own branch somewhere for someone else to try. With svn, I need to append a patch to our BTS/mailinglist. > > It's DVCS, ok, but how many time did you have to diff or log a package > offline? How many time did you have to leave uncommitted changes Actually, all the time. Maybe it's only how I work, but I often look at the history to learn what are the latest changes to see where the package is heading to, what is the style of maintaining, etc. Or simply to remind myself what I did on this package in the past. > locally while waiting to connect to network for "svn up && svn co"? it Also all the time, the latest example being my very first email in this thread. > would be the same for git or svn: you need network to upload a > package, and you need network to update/commit/whatever action on the > repo. > > Having a centralized place, to concentrate our work it's a plus, not a > minus for us (IMO): why would you distribute it? That's a good point and an argument why we should use one VCS as a team. > > Moreover, I do not want upstream code in the VCS we use for > debianization (I did this error for personal managed pacakges and I do > not want to do it again). Let upsteam tracks his own source code like > he prefers, we do not need re-tracking it in git/svn/XXX, what we want > to do is to keep track of our work, what's in debian/ dir *only*. As I understand, the upstream code in the repo is useful only so that one doesn't have to fiddle with orig.tar.gz. > > If, for packaging reason, you need to "touch" the upstream code, then > checkout the upstream code in whatever place you prefer, using the > same VCS upstream uses, and submit them patches, check differences or > what-so-ever, but that has nothing to do with packaging that tool. I agree with this. > >> So that I >> can just commit such patches in a branch and also so that we don't >> have to mess with the orig.tar.gz, svn-uscan and other things > > apt-get source --tar-only Ah thanks, I forgot about this. > uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs Right, that's almost what my svn-uscan alias does: $ alias svn-uscan alias svn-uscan='uscan --verbose --force-download --rename --destdir=../tarballs' However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. > > I don't see too difficult: 1 command (whatever you prefer) comparing > with the many of "vi + dch + build + lintian" loops you do to > prepare a package. > >> everything will be in one git repo, > > Given my slow line, I cannot afford the pain to download every > packages source code + debianization; now, to have a full checkout of > dpmt/papt repositories, I need to launch the commands during the > night. Additionally, doing repositories wide updates will become more > painful, so I have to refrain from "work on every package" but just on > mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? If you want to test a package, you still need to download the orig.tar.gz plus the debian dir (in svn). (the best thing is to just try this and see) > What users are you talking about? those that wants to rebuild a > package are experienced used, so they can apt-get source and > then debcheckout it or whatever order/way they prefer. A normal used > is "client" of the .deb package installed via > apt-get/aptitude/synaptic/dpkg/ I am talking about the user (client in your terminology:), who reports a bug and even suggests a fix, but he doesn't have time to learn how to fiddle with svn-buildpackage+orig.tar.gz. Especially if the fix needs to change some patches in debian/patches. See the howto in the Holger's wiki: http://wiki.debian.org/HolgerLevsen#head-a629792087aba6594e680a74e93b55a9318ba995 it's too dificult I myself don't remember it and I still need to copy the commands from the wiki each time I am fixing some patch in debian/patches. Actua
Re: numpy 1.2.1, switching to git?
On Tue, 2008-23-12 at 16:17 -0500, Scott Kitterman wrote: > Everyone on the team has a workflow for SVN. Not true for the others. > We have a working system and we ought not move off of it until we have > a approach that is easily accessible and well documented. Besides. Git will talk to a svn repo so it's unnecessary to rush a conversion. [just lurking here and on debian-perl] -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 8:01 PM, Pietro Battiston wrote: > I frankly don't see how svn can maximize participation of newcomers. Svn > users are tipically long-time "versioners" who probably tried at least Well, maybe we should distinguish between newcomers to the team and newcomers to VCS. A newcomer to the team could master one VCS, two or none of them, so it's impossible to know his (or her) preferences in advance. For a newcomer to VCS I really think that svn is easier to learn than git/hg/bzr but that's just my opinion. I think the priorities should be, first of all the personal preferences of top commiters, and secondly what we think could be helpful for newcomers. Regards. -- --- Carlos Galisteo PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008 20:01:06 +0100 Pietro Battiston wrote: >Il giorno mar, 23/12/2008 alle 11.41 -0500, Scott Kitterman ha scritto: >> On Tue, 23 Dec 2008 15:08:03 +0100 Loïc Minier wrote: >> >On Mon, Dec 08, 2008, Ondrej Certik wrote: >> >> P.S. bzed, POX, isn't it time to move our packaging to git? So that I >> >> can just commit such patches in a branch and also so that we don't >> >> have to mess with the orig.tar.gz, svn-uscan and other things -- i.e. >> >> everything will be in one git repo, so users can just download, hit >> >> one command and they have a working package (as opposed to the current >> >> scheme, were they need to download svn, then setup some tarball >> >> directories, then setup svn-uscan, then execute it and only then they >> >> can actually build the package, so it's very annoying for casual users >> >> to setup the environment to contribute to the packaging) >> > >> > WARNING bikeshedding VCS discussion spotted! >> > >> > Executive suggestion: we wont be able to use the same VCS for all >> > packages; use whatever the top contributors prefer, not what all >> > contributors to all packages prefer. >> > >> I'll argue we want something different. We want VCS that will maximize >> participation. That means both keeping top contributors happpy and keeping >> it accessible to newcomers. >> >> I don't think hg, bzr, or git obviously qualify as accesible. My vote, >> fwiw, is to stay with svn until we have a documented, accessible workflow >> with tool support. > >Just my two cents (I certainly have no right/reason to express a vote, but I >followed you discussion with interest): as of now, git may maximize >participation of newcomers because it's seen as "cool" (whether or not it is) >and more and more adopted, while bzr may maximize participation of newcomers >because it's popular _now_ (Launchpad and Ubuntu are; I don't think I'm the >only maintainer that became it because of being an Ubuntu user). > >I frankly don't see how svn can maximize participation of newcomers. Svn >users are tipically long-time "versioners" who probably tried at least >once some more recent versioning tool, probably bzr, or git, or hg (lots >of projects switched from svn to one of those), while bzr users often >have no idea of what svn is. > >Then one can say "let's stick to svn because it's a pain to change"; I >just think the "participation" argument is misleading. > Anyone who's used VCS for more than a couple of years has used CVS or SVN (and using either is very similar). Yes all the cool kids are using Git these days, but even in Debian it's much less used than SVN (accelerating though). In Ubuntu, not many developers outside of a group of core-devs uses bzr (note: I'm an Ubuntu core-dev, so I have more than a passing familiarity with the subject). The biggest kick against BZR is that it's little used outside of Ubuntu. OTOH, you can, if you want, use BZR just like you would SVN (bzr co, bzr ci -m ' '). Everyone on the team has a workflow for SVN. Not true for the others. We have a working system and we ought not move off of it until we have a approach that is easily accessible and well documented. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Il giorno mar, 23/12/2008 alle 11.41 -0500, Scott Kitterman ha scritto: > On Tue, 23 Dec 2008 15:08:03 +0100 Loïc Minier wrote: > >On Mon, Dec 08, 2008, Ondrej Certik wrote: > >> P.S. bzed, POX, isn't it time to move our packaging to git? So that I > >> can just commit such patches in a branch and also so that we don't > >> have to mess with the orig.tar.gz, svn-uscan and other things -- i.e. > >> everything will be in one git repo, so users can just download, hit > >> one command and they have a working package (as opposed to the current > >> scheme, were they need to download svn, then setup some tarball > >> directories, then setup svn-uscan, then execute it and only then they > >> can actually build the package, so it's very annoying for casual users > >> to setup the environment to contribute to the packaging) > > > > WARNING bikeshedding VCS discussion spotted! > > > > Executive suggestion: we wont be able to use the same VCS for all > > packages; use whatever the top contributors prefer, not what all > > contributors to all packages prefer. > > > I'll argue we want something different. We want VCS that will maximize > participation. That means both keeping top contributors happpy and keeping > it accessible to newcomers. > > I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, > is to stay with svn until we have a documented, accessible workflow with tool > support. Just my two cents (I certainly have no right/reason to express a vote, but I followed you discussion with interest): as of now, git may maximize participation of newcomers because it's seen as "cool" (whether or not it is) and more and more adopted, while bzr may maximize participation of newcomers because it's popular _now_ (Launchpad and Ubuntu are; I don't think I'm the only maintainer that became it because of being an Ubuntu user). I frankly don't see how svn can maximize participation of newcomers. Svn users are tipically long-time "versioners" who probably tried at least once some more recent versioning tool, probably bzr, or git, or hg (lots of projects switched from svn to one of those), while bzr users often have no idea of what svn is. Then one can say "let's stick to svn because it's a pain to change"; I just think the "participation" argument is misleading. Pietro signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008, Scott Kitterman wrote: > I'll argue we want something different. We want VCS that will > maximize participation. That means both keeping top contributors > happpy and keeping it accessible to newcomers. > > I don't think hg, bzr, or git obviously qualify as accesible. My > vote, fwiw, is to stay with svn until we have a documented, accessible > workflow with tool support. Fair point. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 02:14:25PM +0100, Bernd Zeimetz wrote: > Matthias Klose wrote: > > I only trust my own comparsion without any date and version numbers. > > And honestly I don't care about a checkin of the usual 2-5 files > > taking half a second longer. What annoys me most with git is the > > steep learning curve and the non-intuitive UI, therefore I do prefer > > bzr over hg over svn over others. > In my opinion git is much more intuitive than any other tool - but you have to > climb a bit on the learning curve before you realize it. ... That's not what the word "intuitive" means. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008 15:08:03 +0100 Loïc Minier wrote: >On Mon, Dec 08, 2008, Ondrej Certik wrote: >> P.S. bzed, POX, isn't it time to move our packaging to git? So that I >> can just commit such patches in a branch and also so that we don't >> have to mess with the orig.tar.gz, svn-uscan and other things -- i.e. >> everything will be in one git repo, so users can just download, hit >> one command and they have a working package (as opposed to the current >> scheme, were they need to download svn, then setup some tarball >> directories, then setup svn-uscan, then execute it and only then they >> can actually build the package, so it's very annoying for casual users >> to setup the environment to contribute to the packaging) > > WARNING bikeshedding VCS discussion spotted! > > Executive suggestion: we wont be able to use the same VCS for all > packages; use whatever the top contributors prefer, not what all > contributors to all packages prefer. > I'll argue we want something different. We want VCS that will maximize participation. That means both keeping top contributors happpy and keeping it accessible to newcomers. I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, is to stay with svn until we have a documented, accessible workflow with tool support. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
> P.S. bzed, POX, isn't it time to move our packaging to git? I'm none of them, but I'll speak anyway :) Buxy almost did my point, I'd like to express me a bit. To do a change into something different we need a reason: what's the reason for moving from svn to git? is it because it's cool? (I hope not ;) ) is it because it has some features missing in svn? maybe, but which ones? something else? It's DVCS, ok, but how many time did you have to diff or log a package offline? How many time did you have to leave uncommitted changes locally while waiting to connect to network for "svn up && svn co"? it would be the same for git or svn: you need network to upload a package, and you need network to update/commit/whatever action on the repo. Having a centralized place, to concentrate our work it's a plus, not a minus for us (IMO): why would you distribute it? Moreover, I do not want upstream code in the VCS we use for debianization (I did this error for personal managed pacakges and I do not want to do it again). Let upsteam tracks his own source code like he prefers, we do not need re-tracking it in git/svn/XXX, what we want to do is to keep track of our work, what's in debian/ dir *only*. If, for packaging reason, you need to "touch" the upstream code, then checkout the upstream code in whatever place you prefer, using the same VCS upstream uses, and submit them patches, check differences or what-so-ever, but that has nothing to do with packaging that tool. > So that I > can just commit such patches in a branch and also so that we don't > have to mess with the orig.tar.gz, svn-uscan and other things apt-get source --tar-only uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs I don't see too difficult: 1 command (whatever you prefer) comparing with the many of "vi + dch + build + lintian" loops you do to prepare a package. > everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from "work on every package" but just on mine. Moreover, I don't see any reason to have the fullsource code in the same VCS of debian/ for the myriad of damn-simple packages we have. Another question: do you know of any other big team (we have ~300 pkgs in both papt/dpmt so I see us as a big team) that is on git? I know none :) I'd take the example of pkg-perl: they maintain ~1000 pkgs, and they are still on svn (but I don't know if the plan to move to git anytime soon, but they use for some "corner cases" like perl apps). So, any team experience we can learn from? are the tools ready to allow a team (not just single/small group of maintainers) to work on a plethora of packages in a feasible way? > so users can just download, hit > one command and they have a working package (as opposed to the current > scheme, were they need to download svn, then setup some tarball > directories, then setup svn-uscan, then execute it and only then they > can actually build the package, so it's very annoying for casual users > to setup the environment to contribute to the packaging) What users are you talking about? those that wants to rebuild a package are experienced used, so they can apt-get source and then debcheckout it or whatever order/way they prefer. A normal used is "client" of the .deb package installed via apt-get/aptitude/synaptic/dpkg/ I recognize that some particularly complex packages may need an ad-hoc management, but the vast majority of the packages in the team do not need it; so let's "split" those packages in a separate DVCS repository (maybe still called papt/dpmt) and keep the other where they are. Concluding, if you ever switch to a DVCS, I'd vote for git, but given the situation, I don't see a strong need to move away from svn. Cheers, Sandro PS: I may have written it tough (and the "you" is a generic one), but read it as an open discussion email with ":)" in whatever place you like :) -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
Scott Kitterman pisze: On Tue, 23 Dec 2008 11:24:35 +0100 "PaweB Tcza" wrote: Scott Kitterman pisze: On Tue, 23 Dec 2008 09:10:35 +0100 "PaweB Tcza" wrote: Hi Scott, It's true, but probably not all true :) For example, what about release upgrade? I remember that when I run `do-release-upgrade` command for Ubuntu then I can only agree or disagree to remove *all* packages removed from Ubuntu. I don't know how to save only one package I still need, for example revelation. Even there it only removes packages where there is a conflict, not just because it's out of the archive. Thanks for the explanation! I didn't know about it. You're welcome. I should mention that the above is the rule. The Ubuntu update-manager carries a lot of special cases to smooth upgrades and so it may, in fact, have special case code to remove certain packages. I don't think you need to worry about that for your case. This folow-up is just for completenes. Thank you very much for that follow-up too! It's good to know how update-manager works :) Cheers, P. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, 23 Dec 2008, Ondrej Certik wrote: > I am surprised I am actually the 6th most active. Pretty cool. :) I am surprised to still be in the top 10 (hertzog)… it means the team is not so active as one would expect. :-) Anyway, I'm fine with git as well but I'm not convinced it's that important. You should also look at the perl team, they are using git on some packages only and have not yet decided to mass-convert from SVN to Git. One of the reasons of the block is that Git makes it difficult to do operations on all the repositories. And for a global update, you're forced to use tools like "mr" (and even that won't add new package automatically). Furthermore, Git alone doesn't mean much, the questions is whether we have to use git-buildpackage, topgit and so on. Hence I would rather suggest a per-package decision for the switch. I won't cry if SVN continues to be used. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Bernd Zeimetz wrote: Cyril Brulebois wrote: Tristan Seligmann (20/12/2008): My personal preference ordering would probably be: hg, bzr, svn, git git, FD, * +1 :) http://whygitisbetterthanx.com I don't know git, but I want to learn about it.. so It can be a nice oportunity to do it. So +1 for git. -- Marco Rodrigues http://Marco.Tondela.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFR] urlwatch
Hi, Piotr Ożarowski wrote: > [Franck Joncourt, 2008-12-19 21:21] /usr/share/urlwatch/examples/hooks.py.example /usr/share/urlwatch/examples/urls.txt.example >>> how about installing these in /usr/share/doc/urlwatch/examples ? >> You are right, that is a good idea. > [...] >> Upstream does that when setup.py is installed and I do not see how I >> could bypass this without rewriting the setup.py file. The argument > > you can simply move (mv) files/directory in debian/rules That a solution :p! I will update the package next year. I wish you all a merry christmas and a happy new year. Thanks, -- Franck Joncourt http://debian.org - http://smhteam.info/wiki/ signature.asc Description: OpenPGP digital signature
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008, Loïc Minier wrote: > Executive suggestion: we wont be able to use the same VCS for all > packages; use whatever the top contributors prefer, not what all > contributors to all packages prefer. I thought this was clear from the above rationale, but the stats I attached are for the numpy package only -- since my suggestion is to decide on a per-package basis. I checked last year worth of numpy uploads. > -- Ondrej Certik Sat, 20 Sep 2008 16:31:23 +0200 [...] -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Mon, Dec 08, 2008, Ondrej Certik wrote: > P.S. bzed, POX, isn't it time to move our packaging to git? So that I > can just commit such patches in a branch and also so that we don't > have to mess with the orig.tar.gz, svn-uscan and other things -- i.e. > everything will be in one git repo, so users can just download, hit > one command and they have a working package (as opposed to the current > scheme, were they need to download svn, then setup some tarball > directories, then setup svn-uscan, then execute it and only then they > can actually build the package, so it's very annoying for casual users > to setup the environment to contribute to the packaging) WARNING bikeshedding VCS discussion spotted! Executive suggestion: we wont be able to use the same VCS for all packages; use whatever the top contributors prefer, not what all contributors to all packages prefer. -- Ondrej Certik Sat, 20 Sep 2008 16:31:23 +0200 -- Ondrej Certik Sun, 17 Aug 2008 21:03:12 +0200 -- Ondrej Certik Tue, 08 Jul 2008 15:08:16 +0200 -- Ondrej Certik Sun, 06 Jul 2008 18:28:29 +0200 -- Ondrej Certik Mon, 09 Jun 2008 17:02:31 +0200 -- Ondrej Certik Wed, 30 Apr 2008 13:52:37 +0200 -- Ondrej Certik Thu, 13 Mar 2008 00:42:09 +0100 -- William Grant Sat, 08 Mar 2008 12:56:12 +1100 -- Ondrej Certik Wed, 20 Feb 2008 15:06:55 +0100 -- Kumar Appaiah Sun, 06 Jan 2008 07:36:20 +0530 -- Kumar Appaiah Sat, 22 Dec 2007 22:19:32 +0530 -- Ondrej Certik Mon, 17 Dec 2007 17:26:57 +0100 [ Ondrej Certik ] [ Sandro Tosi ] [ Riku Voipio ] [ Tiziano Zito ] [ Carlos Galisteo ] [ Ondrej Certik ] [ Emilio Pozuelo Monfort ] [ Tiziano Zito ] [ Ondrej Certik ] [ Andrew Straw ] [ Kumar Appaiah ] [ Chris AtLee ] [ Kumar Appaiah ] [ Kumar Appaiah ] [ Ondrej Certik ] [ Kumar Appaiah ] [ Sandro Tosi ] [ Kumar Appaiah ] [ Kumar Appaiah ] [ Ondrej Certik ] -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
On Tue, 23 Dec 2008 11:24:35 +0100 "PaweB Tcza" wrote: >Scott Kitterman pisze: >> On Tue, 23 Dec 2008 09:10:35 +0100 "PaweB Tcza" wrote: >>>Scott Kitterman pisze: On Mon, 22 Dec 2008 21:00:40 + b...@bc-bd.org wrote: >... >Simply removing the package may be a bad idea, as people who are using >revelation will then no longer be able to access their password lists. >... Removing the package from the archive won't remove it from installed systems. >>> >>>Hi Scott, >>> >>>It's true, but probably not all true :) For example, what about release >>>upgrade? I remember that when I run `do-release-upgrade` command for >>>Ubuntu then I can only agree or disagree to remove *all* packages >>>removed from Ubuntu. I don't know how to save only one package I still >>>need, for example revelation. >> >> Even there it only removes packages where there is a conflict, not just >> because it's out of the archive. > >Thanks for the explanation! I didn't know about it. You're welcome. I should mention that the above is the rule. The Ubuntu update-manager carries a lot of special cases to smooth upgrades and so it may, in fact, have special case code to remove certain packages. I don't think you need to worry about that for your case. This folow-up is just for completenes. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 2:14 PM, Bernd Zeimetz wrote: > Matthias Klose wrote: >> I only trust my own comparsion without any date and version numbers. >> And honestly I don't care about a checkin of the usual 2-5 files >> taking half a second longer. What annoys me most with git is the >> steep learning curve and the non-intuitive UI, therefore I do prefer >> bzr over hg over svn over others. > > In my opinion git is much more intuitive than any other tool - but you have to > climb a bit on the learning curve before you realize it. If you already know hg, the curve is not steep at all (as I said, it took me a day or two to feel like at home). I suspect if you already know bzr well, the curve will not be steep as well. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
ma, 2008-12-22 kello 21:00 +, b...@bc-bd.org kirjoitti: > Hello debian-python, > > I have been maintaining revelation in the past, a GNOME2 Password manager. I > will most likely orphan this package because: Before this gets removed from the archive: is there a good replacement? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Matthias Klose wrote: > I only trust my own comparsion without any date and version numbers. > And honestly I don't care about a checkin of the usual 2-5 files > taking half a second longer. What annoys me most with git is the > steep learning curve and the non-intuitive UI, therefore I do prefer > bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Bernd Zeimetz writes: > Cyril Brulebois wrote: > > Tristan Seligmann (20/12/2008): > >> My personal preference ordering would probably be: > >> > >> hg, bzr, svn, git > > > > git, FD, * > > +1 :) > > > http://whygitisbetterthanx.com I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. Matthias Not a member of the modules team, just listed as uploader of some of the packages. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 1:37 PM, Piotr Ożarowski wrote: > [Ondrej Certik, 2008-12-23 11:19] >> emi...@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut >> -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r >> 865 piotr >> 609 morph >> 598 kov >> 532 bzed >> 388 pox > > 865+388=1253 > > looks like my vote is most meaningful ;-) > > unfortunately I use Git only outside Debian, so I don't know about > issues git-buildpackage might have. I know it doesn't have > mergeWithUpstream but it's written in Python, so we can implement this. > The problem is (FWIK) that it's better to use Git with upstream sources > (with tools like pristine-tar)... anyway, I vote for Git, but I'm open > to alternative suggestions. Well, we'll have to divide our svn repo into many small git repositories anyways. And if there is enough space on git.debian.org, I suggest we also include upstream sources and use pristine-tar, as then one will just have to "git clone" and no other messing with the origtarball (this is really a pain with svn). Take the "mutt" package as an example: $ debcheckout mutt $ cd mutt $ bzr builddeb [...] bzr: ERROR: The build failed. Because the orig.tar.gz is missing. What is the easiest to obtain the right orig.tar.gz? (I can go to packages.debian.org and download it by hand, but preferably there is just one command for that) If we include upstream sources, it would be just: $ debcheckout mutt $ cd mutt $ git buildpackage [...] Finished running lintian. And that's it. It will be a lot easier for onetime for new people to start contributing, because they won't have to setup their environment. But maybe there is some other way to handle upstream source than just including them in the git repository. Ondrej
Re: numpy 1.2.1, switching to git?
I'd prefer: hg, git, bzr, svn, * but looks like the trend goes to git, which is a good option IMHO. Merry Christmas, Eike pgpHKNQOnhCVA.pgp Description: PGP signature
Re: numpy 1.2.1, switching to git?
[Ondrej Certik, 2008-12-23 11:19] > emi...@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut > -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r > 865 piotr > 609 morph > 598 kov > 532 bzed > 388 pox 865+388=1253 looks like my vote is most meaningful ;-) unfortunately I use Git only outside Debian, so I don't know about issues git-buildpackage might have. I know it doesn't have mergeWithUpstream but it's written in Python, so we can implement this. The problem is (FWIK) that it's better to use Git with upstream sources (with tools like pristine-tar)... anyway, I vote for Git, but I'm open to alternative suggestions. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
On Mon, Dec 22, 2008 at 05:22:09PM -0500, Scott Kitterman wrote: > On Mon, 22 Dec 2008 21:00:40 + b...@bc-bd.org wrote: > >... > >Simply removing the package may be a bad idea, as people who are using > >revelation will then no longer be able to access their password lists. > >... > > Removing the package from the archive won't remove it from installed > systems. > > If it's dead upstreamam then I'd suggest it ought to go. You are right that removing it from the archive will not uninstall it on systems directly, but revelation pulls in a lot of dependencies (directly and indirectly) and in the past it has happen more than once that revelation was uninstalled due to library incompatibilities. So what might happen, is that revelation gets removed from a system because some dependency changes. IMHO we should provide uses with some kind of exist strategy, perhaps a popup dialog saying something like "This program is dead upstream, it may be removed from the next stable release without further notice, we recommend that you migrate your password information to another application". Regards Stefan -- BOFH excuse #416: We're out of slots on the server -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
Scott Kitterman pisze: On Tue, 23 Dec 2008 09:10:35 +0100 "PaweB Tcza" wrote: Scott Kitterman pisze: On Mon, 22 Dec 2008 21:00:40 + b...@bc-bd.org wrote: ... Simply removing the package may be a bad idea, as people who are using revelation will then no longer be able to access their password lists. ... Removing the package from the archive won't remove it from installed systems. Hi Scott, It's true, but probably not all true :) For example, what about release upgrade? I remember that when I run `do-release-upgrade` command for Ubuntu then I can only agree or disagree to remove *all* packages removed from Ubuntu. I don't know how to save only one package I still need, for example revelation. Even there it only removes packages where there is a conflict, not just because it's out of the archive. Thanks for the explanation! I didn't know about it. Have a nice day, P. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 10:41 AM, Bernd Zeimetz wrote: > Cyril Brulebois wrote: >> Tristan Seligmann (20/12/2008): >>> My personal preference ordering would probably be: >>> >>> hg, bzr, svn, git >> >> git, FD, * > > +1 :) +1 too. Btw, Emilio did a list of the most active DPMT users, here it is. Some people like pox and piotr are actually the same. I am surprised I am actually the 6th most active. Pretty cool. :) Anyway --- when I get some free time, I'll try to assign the VCS preference to the svn names below. I think it is important that the people who are the most active use the vcs that they want. People with no so many commits imho can learn how to use a vcs that is not so much their favourite. I'll write a howto to our DPMT pages how to generate couple commits with let's say git (if we switch to it), so that one doesn't have to learn it --- I am 100% sure that with such a howto, it will take only 5 minutes to submit a fix to a BTS using let's say git. Ondrej emi...@saturno:~/deb/python-modules$ svn log | egrep "^r[0-9]+ " | cut -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r 865 piotr 609 morph 598 kov 532 bzed 388 pox 302 arnau 253 certik 216 shlomme 212 malex 175 hertzog 140 nslater 130 kobold 123 nijel 121 kitterma 106 bernat 99 kibi 87 varun 83 stratus 81 nobse 81 netzwurm 78 azatoth 76 mca 73 dottedmag 70 jluebbe 68 zack 68 cgalisteo 61 speijnik 61 odd_bloke 60 rganesan 55 kumanna 52 werner 50 haas 48 mejo 45 ucko 43 pabs 42 stew 42 luciano 41 mithrandi 40 wardi 36 gudjon 35 jandd 34 smcv 34 brettp 32 jenner 31 davidvilla 31 aurel32 30 rousseau 30 mtaylor 28 thomasbl 26 lool 25 gaspa 25 ffm 24 adn 22 jmalonzo 21 santiago 21 appaji 18 goedson 17 toadstool 17 sto 17 awen 16 mlizaur 16 akumar 15 nacho 14 smr 14 hanska 13 tviehmann 13 norsetto 13 mbaldessari 12 stone 12 sharky 11 rainct 11 fabrizio 10 lash 9 rodrigogc 9 pcc 9 miriam 9 madduck 9 ftlerror 8 pere 8 crschmidt 7 ncommander 7 myon 7 abuss 6 jwilk 6 bdrung 6 atehwa 5 kcoyner 5 catlee 5 andyp 4 vt 4 ross 4 osrevolution 4 lamby 4 baby 3 sez 3 joss 3 geole 2 rustybear 2 edmonds 2 astraw 2 ana 1 twerner 1 tincho 1 pochu 1 danderson -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
On Tue, 23 Dec 2008 09:10:35 +0100 "PaweB Tcza" wrote: >Scott Kitterman pisze: >> On Mon, 22 Dec 2008 21:00:40 + b...@bc-bd.org wrote: >>>... >>>Simply removing the package may be a bad idea, as people who are using >>>revelation will then no longer be able to access their password lists. >>>... >> >> Removing the package from the archive won't remove it from installed >> systems. > >Hi Scott, > >It's true, but probably not all true :) For example, what about release >upgrade? I remember that when I run `do-release-upgrade` command for >Ubuntu then I can only agree or disagree to remove *all* packages >removed from Ubuntu. I don't know how to save only one package I still >need, for example revelation. Even there it only removes packages where there is a conflict, not just because it's out of the archive. >> If it's dead upstreamam then I'd suggest it ought to go. > >I'm very curious how many debianized sources are dead now. Probably it's >not only revelation. Do you want to remove all of them? > >In my opinion it's better to save that packages as long as someone wants >to maintain them and they are useful for their users and don't have >unrepairabled bugs. > Right, but we don't currently have that. There's tons of cruft in the archive. Please don't add to it. It's easy enough to restore it if a maintainer appears. Scott K -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
> Btw, Emilio did a list of the most active DPMT users, here it is. Some > people like pox and piotr are actually the same. And the same list for PAPT: emi...@saturno:~/deb/python-apps$ svn log | egrep "^r[0-9]+ " | cut -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r 401 nijel 288 piotr 235 gothicx 159 pochu 76 nslater 69 kumanna 68 rainct 66 gilir 63 certik 52 vdanjean 52 bzed 46 dottedmag 41 stani 39 varun 37 kitterma 36 morph 35 odd_bloke 29 pcc 29 gudjon 28 appaji 25 thomasbl 24 arnau 20 sc 20 andyp 18 jalet 15 gerardo 14 eike 14 ana 13 dfiloni 11 tklauser 10 ryanakca 10 nxvl 10 akumar 8 sez 8 baby 6 catlee 4 osrevolution 4 cody-somerville 2 mithrandi 2 cjsmo 1 nenolod 1 ffm -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Cyril Brulebois wrote: > Tristan Seligmann (20/12/2008): >> My personal preference ordering would probably be: >> >> hg, bzr, svn, git > > git, FD, * +1 :) http://whygitisbetterthanx.com -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Need help with revelation
Scott Kitterman pisze: On Mon, 22 Dec 2008 21:00:40 + b...@bc-bd.org wrote: ... Simply removing the package may be a bad idea, as people who are using revelation will then no longer be able to access their password lists. ... Removing the package from the archive won't remove it from installed systems. Hi Scott, It's true, but probably not all true :) For example, what about release upgrade? I remember that when I run `do-release-upgrade` command for Ubuntu then I can only agree or disagree to remove *all* packages removed from Ubuntu. I don't know how to save only one package I still need, for example revelation. If it's dead upstreamam then I'd suggest it ought to go. I'm very curious how many debianized sources are dead now. Probably it's not only revelation. Do you want to remove all of them? In my opinion it's better to save that packages as long as someone wants to maintain them and they are useful for their users and don't have unrepairabled bugs. My best regards, Pawel -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
