Hi
Dne Sat, 29 Aug 2009 03:58:13 +0300
anatoly techtonik 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 histor
Howdy mentors,
I am looking for a sponsor for the new release 0.4.3-2.1+lenny1 of my
package ‘burn’ in Lenny. Since it's implemented in Python, I'm asking on
both ‘debian-mentors’ and ‘debian-python’.
It builds these binary packages:
burn - Command line Data-CD, Audio-CD, ISO-CD, Copy-CD writing
Ben Finney writes:
> I don't want to change the version string based on a guess. I can't
> find any mention of the convention you're describing in the
> Developer's Reference or the Policy; what should I read to know what
> you're referring to?
Found it:
5.8.5.4. Preparing packages to addre
On Sat, 29 Aug 2009 03:58:13 +0300 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
On Sat, 29 Aug 2009 11:33:22 am Ben Finney wrote:
> Felipe Sateler writes:
> > Ben Finney wrote:
> > > Felipe Sateler writes:
> > >> I believe packages with updates to stable debian releases are
> > >> versioned -+lenny1 or something like that.
> > >>
> > >> BTW, I know this is not a hard require
Felipe Sateler writes:
> Ben Finney wrote:
>
> > Felipe Sateler writes:
> >
> >> I believe packages with updates to stable debian releases are
> >> versioned -+lenny1 or something like that.
> >
> >> BTW, I know this is not a hard requirement, but it is to easily
> >> detect stable updates.
>
On Fri, Aug 28, 2009 at 2:21 PM, Christoph
Egger wrote:
>
> 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.
If we are all Python developers to some degree a
On Fri, Aug 28, 2009 at 12:01 PM, Jan Dittberner wrote:
>
> I'm using trac and commithooks and would like to help with better
> Debian support for both.
>
There are many outstanding bugs without patches that are rather
critical to skip forever. Before moving Trac from one VCS to another
the first
On Fri, Aug 28, 2009 at 11:48 AM, W. Martin Borgert 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, gen
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 ne
Cyril Brulebois wrote:
> Bernd Zeimetz (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 t
Bernd Zeimetz (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
Quoting "Christoph Egger" :
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 wou
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 pa
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 larg
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 plugin
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
probabl
Fri, 28 Aug 2009 11:01:37 +0200
Jan Dittberner 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
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
[Mikhail Gusarov, 2009-08-28]
> Twas brillig at 12:08:21 28.08.2009 UTC+02 when pi...@debian.org did gyre and
> gimble:
>
> PO> question is: are these plugins installed in trac's directory or do
> PO> they "import trac"?
>
> import. Additionally Trac supports installing plugins into the
> inst
Twas brillig at 12:08:21 28.08.2009 UTC+02 when pi...@debian.org did gyre and
gimble:
PO> question is: are these plugins installed in trac's directory or do
PO> they "import trac"?
import. Additionally Trac supports installing plugins into the
instances.
--
http://fossarchy.blogspot.com/
[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 y
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 spe
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
[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
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 Pyt
26 matches
Mail list logo
