Re: VCS for Python code Was: Trac team almost dead?
Recently I have discovered some very nice features of hg that make it attractive: 1) Multiple branches such that debian/ can be kept on alioth and have working copy that has everything if maintainer prefers so 2) MercurialQueues plugin allows to keep versioned quilt patches, rebase, merge and split them. Keep their history in a seperate branch and always upto date series file. This 2 features are very neat that imho bzr and git are lacking. (well bzr will have stable support for nested trees soon can be simulated with checkouts now and git has tg2quilt) One major drawback of hg is missing pristine-tar support and abandoned hg-buildpackage. Anyone willing to start working on this drawback together with me? I have a little bit of ugly hackish code. =) -- With best regards Dmitrijs Ledkovs (for short Dima), Ледков Дмитрий Юрьевич -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
On Tue, Sep 1, 2009 at 4:16 PM, Dmitrijs Ledkovsdmitrij.led...@gmail.com wrote: Recently I have discovered some very nice features of hg that make it attractive: Mercurial Queues are awesome, but there is one major drawback in Mercurial comparing to SVN - it is impossible to clone a subtree of repository. In SVN you may checkout any path and isolate your work inside. I personally found this feature along with --set-depth option very convenient when working with parts of such big projects as Debian or Python. There is forest extension and experimental subrepository support in HG, but it works like svn:externals replacement. Ciao, -- anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
On Tuesday 01,September,2009 09:16 PM, Dmitrijs Ledkovs wrote: Recently I have discovered some very nice features of hg that make it attractive: 1) Multiple branches such that debian/ can be kept on alioth and have working copy that has everything if maintainer prefers so 2) MercurialQueues plugin allows to keep versioned quilt patches, rebase, merge and split them. Keep their history in a seperate branch and always upto date series file. This 2 features are very neat that imho bzr and git are lacking. (well bzr will have stable support for nested trees soon can be simulated with checkouts now and git has tg2quilt) Git has #1, by the way, if I'm understanding you correctly. Which means both said features are present in Git at the very least. Also, Git does seem like a more popular option than Mercurial, so I think going Git would be a better choice, or many of us and potential newcomers would have to learn a new tool which they may potentially disagree with. In my case, the more I read about Mercurial, the more I dislike it, but that's a different matter. -- Kind regards, Chow Loong Jin signature.asc Description: OpenPGP digital signature
Re: VCS for Python code Was: Trac team almost dead?
On Tue, 2009-01-09 at 19:10 +0300, anatoly techtonik wrote: On Tue, Sep 1, 2009 at 4:16 PM, Dmitrijs Ledkovsdmitrij.led...@gmail.com wrote: Recently I have discovered some very nice features of hg that make it attractive: Mercurial Queues are awesome, but there is one major drawback in Mercurial comparing to SVN - it is impossible to clone a subtree of This drawback is part of the design of git (and mercurial). It's well worth viewing linus' 70 minute google video to understand the design goals and issues. repository. In SVN you may checkout any path and isolate your work inside. I personally found this feature along with --set-depth option [snip] -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
Hi, On Wed, Sep 02, 2009 at 12:15:44AM +0800, Chow Loong Jin wrote: Git has #1, by the way, if I'm understanding you correctly. Which means both ... In my case, the more I read about Mercurial, the more I dislike it, but that's a different matter. I'm not sure anyone cares, but at Logilab we have been happy users of Mercurial for several years now. My bet is that git and hg are the two dvcs that will survive the current crunch that follows the vcs explosion which happened a few years ago. And Mercurial being written in Python makes it easier to hack into it when needed. -- 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
Re: VCS for Python code Was: Trac team almost dead?
Hi Dne Sat, 29 Aug 2009 03:58:13 +0300 anatoly techtonik techto...@gmail.com napsal(a): If we are all Python developers to some degree and know about PEP 374 - what do you think about switching from SVN to HG for maintaining Debian packages? There is also convert extension that may allow to convert history from other sources to HG and PEP 385 that may help admins to decide how to move from SVN. There was recently lengthly discussion about using Git, check archives. The reasons against Hg will be the same + the fact that much poeple do not know it. (I'd be for Git but not for Hg, which I never used before and I'm too lazy to know every VCS available). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: VCS for Python code Was: Trac team almost dead?
I'm all for Git. -- Kind regards, Chow Loong Jin (GPG: 0x8F02A411) Ubuntu Contributing Developer signature.asc Description: OpenPGP digital signature
Re: VCS for Python code Was: Trac team almost dead?
anatoly techtonik wrote: If we are all Python developers to some degree and know about PEP 374 - what do you think about switching from SVN to HG for maintaining Debian packages? There is also convert extension that may allow to convert history from other sources to HG and PEP 385 that may help admins to decide how to move from SVN. That won't happen as the main sponsors and the most active people in the team will not touch hg. We'll stick with svn for now, but chances are good that we'll add git support in the future. The reasons behind that were discussed often enough, no need to start that again. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: VCS for Python code Was: Trac team almost dead?
OoO En cette nuit striée d'éclairs du samedi 29 août 2009, vers 02:58, anatoly techtonik techto...@gmail.com disait : If we are all Python developers to some degree and know about PEP 374 Decision presented in PEP 374 does not really apply to us: - Windows support is unimportant - Python core developers' tastes do not matter -- I WILL NOT TEASE FATTY I WILL NOT TEASE FATTY I WILL NOT TEASE FATTY -+- Bart Simpson on chalkboard in episode 5F05 pgpPvcQSYpn2t.pgp Description: PGP signature
Trac team almost dead?
On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
[Jan Dittberner, 2009-08-28] On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, [...] I would really like to have trac in DPMT or maybe PAPT (is trac module used outside trac itsefl? If not, it should be moved to private directory, IMHO) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 10:48:48AM +0200, W. Martin Borgert wrote: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? I would really like to have trac in DPMT (or more activity in the current trac team). Maybe we could also coordinate to include commithooks [1] which integrate darcs, mercurial and git with trac and debbugs but should use trac's included post-commit scripts and consists of some Python and bash scripts. [1] http://git.complete.org/commithooks I'm using trac and commithooks and would like to help with better Debian support for both. Regards Jan -- Jan Dittberner - Debian Developer GPG-key: 4096R/558FB8DD 2009-05-10 B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD http://ddportfolio.debian.net/ - http://people.debian.org/~jandd/ signature.asc Description: Digital signature
Re: Trac team almost dead?
[W. Martin Borgert, 2009-08-28] On 2009-08-28 11:29, Piotr Ożarowski wrote: or maybe PAPT (is trac module used outside trac itsefl? If not, it should be moved to private directory, IMHO) I think, it's in the similar category as Django etc. i.e. it is a base technology on that you install plugins. It is, however, more specialised (focus on project management) and you can use it without writing your own application opposed to Django etc. question is: are these plugins installed in trac's directory or do they import trac? -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
On 2009-08-28 12:08, Piotr Ożarowski wrote: question is: are these plugins installed in trac's directory or do they import trac? AFAIK, this depends on the package. Typical plugins are installed into Trac directories, but they have also to import trac to use the APIs. I'm currently not near my trac server, but I remember that email2trac is installed under /usr/bin and uses the Trac API by from trac import Installation outside of Trac directories is, however, an exception. CMIIW. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Fri, 28 Aug 2009 11:01:37 +0200 Jan Dittberner ja...@debian.org wrote: On Fri, Aug 28, 2009 at 10:48:48AM +0200, W. Martin Borgert wrote: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? I would really like to have trac in DPMT (or more activity in the current trac team). Maybe we could also coordinate to include commithooks [1] which integrate darcs, mercurial and git with trac and debbugs but should use trac's included post-commit scripts and consists of some Python and bash scripts. [1] http://git.complete.org/commithooks I'm using trac and commithooks and would like to help with better Debian support for both. I've looked at this scripts and found them not very accurate. So as for me, I've decided to use trac-post-commit-hook from trac distribution and simple shell scipt to run it in right time. -- Best regards, Alexander GQ Gerasiov Contacts: e-mail:g...@cs.msu.su Jabber: g...@jabber.ru Homepage: http://gq.net.ru ICQ: 7272757 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
Twas brillig at 12:21:21 28.08.2009 UTC+02 when deba...@debian.org did gyre and gimble: WMB Typical plugins are installed into Trac directories, ? There are two modes of installation: putting the .egg to the concrete Trac instance and installing it site-wide in the PYTHONPATH. You're probably referring to former. Distribution-friendly way is latter. -- http://fossarchy.blogspot.com/ pgp7bdlHbgBYz.pgp Description: PGP signature
Re: Trac team almost dead?
On 2009-08-28 17:25, Mikhail Gusarov wrote: There are two modes of installation: putting the .egg to the concrete Trac instance and installing it site-wide in the PYTHONPATH. You're probably referring to former. Distribution-friendly way is latter. Than I was wrong. I thought that plugins can go into a site-wide Trac directory, but you are right. So anybody vetoing against moving Trac to DPMT? You have three seconds... :~) Given that (1) pkg-trac was inactive the last months and that (2) interested Trac team members can easily join DPMT, and (3) a new upstream version is needed desperately by some users, I will probably start migration tomorrow. Depends on the weather. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
W. Martin Borgert schrieb: On 2009-08-26 10:59, Alexander GQ Gerasiov wrote: project on alioth looks nearly dead. We're using trac actively in our lab, so I'll think about entering team to help them a little bit. I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb, and pygments. If nobody objects, I would do the necessary work, including fix of #521513 (i.e. upload of current trac version 0.11.5), under the flag of the python-modules team. Andres, Federico, Jesus, Luis, Otavio, what do you think? Hi! I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. As my packages have (following trac itself) a git history and the one I've ITA-ed has some HG history I'm interested in what the team thinks so I can decide if / what to move in. Regards Christoph -- /\ ASCII Ribbon : GPG-Key ID: 0x0372275D \ /Campaign : GPG 4096R : 0xD49AE731 X against HTML : Debian NM / \ in eMails : http://www.debian.org/ http://www.christoph-egger.org/ signature.asc Description: OpenPGP digital signature
Re: Trac team almost dead?
Christoph Egger wrote: I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. As my packages have (following trac itself) a git history and the one I've ITA-ed has some HG history I'm interested in what the team thinks so I can decide if / what to move in. We're thinking about migrating the modules/apps teams repositories to git for a long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. Dropping the history doesn't make sense indeed, so I'm not sure what the best way to handle this is *now* - on the long run I;m sure we'll find a way to include it properly. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Quoting Christoph Egger deb...@christoph-egger.org: I have some of the trac-plugins ITA/ITPed and would probably consider following trac itself into one of the python Teams. However I wonder how the $VCS will be handled, throwing away trac's git history doesn't sound like a good idea to me. The git history would still exist. And we could also import the git history into the SVN repository of DPMT. I never used git and I currently don't have the time to learn new tools, so maybe somebody could post the right command line to do this, please? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
Bernd Zeimetz be...@bzed.de (28/08/2009): long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. You meant putting a few lines into a .mrconfig file? Mraw, KiBi. signature.asc Description: Digital signature
Re: Trac team almost dead?
Cyril Brulebois wrote: Bernd Zeimetz be...@bzed.de (28/08/2009): long time, actually there is even a plan (at least in my head) to make it possible to have modules in git or svn while still being able to checkout all of them in a useful way, but that means writing new code, and I didn't have the time to do so yet. You meant putting a few lines into a .mrconfig file? no. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-trac-devel] Trac team almost dead?
On 2009-08-28 12:21, Piotr Ożarowski wrote: DPMT is fine then (most important ;-) problem solved) Maybe not yet: To me it would make sense to maintain Trac and some Trac plugins in the same team and in the same VCS. DPMT would be OK for Trac, but probably not for all the plugins, that are never used by anything but Trac. So maybe PAPT is the right choice then? -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trac team almost dead?
On Fri, Aug 28, 2009 at 11:48 AM, W. Martin Borgertdeba...@debian.org wrote: I wonder, how people feel about moving Trac from its own team to a larger, more active team, i.e. Debian Python Modules Team, which already has some of tracs dependencies, i.e. libapache2-mod-python, mod-wsgi, python-docutils, genshi, python-mysqldb Please, note that MySQL support in Trac is still experimental. Why Trac should belong to application is that Python Application is something that should be run inside virtualenv. Trac is not a module, but rather important piece of server software that should better be updated alone with it's dependent libraries and probably independent of main Python installation. --anatoly t. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
