headers
David Abrahams | 1 Jun 01:41
Picon
Picon
Favicon
Gravatar

[Trac-dev] Re: Feature set [was: Re: [Trac-dev] Re: Report for dynamic variables]


on Fri May 30 2008, "Noah Kantrowitz" <noah-AT-coderanger.net> wrote:

> This would be a part of the long-fabled trac-hacks++ Alec and I have been
> discussing over the last year or so. I think this installer will solve the
> _real_ problem people are having. Its not that lots of plugins are a bad
> idea, they are just annoying to get working. Put this installer in Trac
> core, and you get the experience I think everyone wants.

I'm sorry, I have to disagree.  Even as someone who's willing (when
necessary) to hack plugins and hack the Trac core to make them work
right in my environment, my problems with plugins are the same as some
others have mentioned in this thread.  I need too many of them just to
get basic functionality and their compatibility with the latest Trac is
not always well-maintained.

Noah, are you hearing about different kinds of plugin problems from
other people, or are you saying something like that nobody who is
complaining really understands the problem they're having?

The economics of bringing a few mature, stable, and widely-needed
plugins into the official distribution are clear to me: when Trac makes
a code-breaking change, it's much easier to coordinate the code
transformations needed to keep all those plugins running.  Often, I'm
sure, one person is doing a fairly mechanical scan through the Trac code
and can take care of everything in one shot.

--

-- 
Dave Abrahams
BoostPro Computing
(Continue reading)

Permalink | Reply | 0 comments |
headers
jevans | 1 Jun 07:56
Picon

[Trac-dev] Re: Report for dynamic variables


>  > Using third-party plugin for such essential functionality looks risky.
>  > What about migration path and compatibility issues? There is no guarantee
>  > on the future compatibility of MasterTickets and Trac.
>  > Besides, MasterTickets looks quite limited. Trac is great, I bet you can
>  > do better than that.
>  >
>  > I can't believe that Trac team avoided implementation of such essential
>  > feature for so long (this ticket is 4+ years old). I love Trac but it's
>  > unusable in large projects because of things like this. Sad.
>
> Nicely put, I can't agree more.

I wholly agree with this sentiment.

> Well, as you might have guessed by now, I've grown tired of this, and
> 0.11 will likely be my last Trac release, while I'm looking for ways to
> build an enhanced, more cohesive solution, in line with my ideas (this
> might succeed or not, but at least I won't have the feeling to bump into
> walls).

Christian, I understand your frustration.  I'm only considering
advocating for Trac at my workplace and I'm frustrated.  I do however
hope you can stay on.

- jevans
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eirik Schwenke | 1 Jun 21:14
Picon
Picon
Favicon

[Trac-dev] Re: Feature set [was: Re: [Trac-dev] Re: Report for dynamic variables]


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Noah Kantrowitz skrev 30-05-2008 19:28:
|> -----Original Message-----
|> My preferred route for functionality like this (and MasterTicket /
|> Dynamic Report Variables / etc) would be to bless some plugins with
|> auto inclusion into the trac install (disabled by default).  I greatly
|> value that trac is simple to use.  I recently helped teach a Software
|> Engineering class that made use of trac.  I feel that it could not
|> have been used if it was more toward the bugzilla side of issue
|> tracking (way too complex for a first go at software management).
|> That said, part of the project was to estimate and track time (which
|> is convenient since I wrote the plugin).  I am sure that others will
|> want to have only ticket dependancies and not time tracking, or only
|> custom reports with a variable filling form.  All of these are
|> essential for the group of users that need them and the system cannot
|> be complete without them.  By blessing and including these plugins
|> with trac we can keep the simplicity, while easily enabling plugins
|> that fill out the functionality we need.
|
| I agree with this approach. Keep the Trac codebase small, and just bundle
| snapshots of some plugins (perhaps determined by community voting once t-h
| gets moved to 0.11) along with a set of release media. If people want new
| versions of those plugins, they can upgrade, but this is enough of a stopgap
| until ...
|
|> One thought I have been kicking around is a package management plugin
|> for trac that would be able download and install a plugin and update
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonas Borgström | 1 Jun 23:46
Favicon

[Trac-dev] Re: "database is locked" back on t.e.o.

David Abrahams wrote:
> on Fri May 30 2008, David Abrahams <dave-AT-boostpro.com> wrote: 
> 
>>> I have actually been thinking about making Trac use a single global db 
>>> pool instead of one pool for each environment in each process.
>> Yep, that's what we need, or something very like it.  Of course, each of
>> my environments connects with a different schema and role, so
>> connections aren't interchangeable.  I could think about changing that,
>> but I'm thinking the short-term fix is to build an LRU cache of all the
>> connections in any pool, and simply throw out the oldest ones when the
>> cache is full and a new one is requested.
> 
> Actually, your approach turned out to be easier.  My patched pool.py
> follows

Hi David,

When I tested your patch I noticed that the connections returned by the 
pool sometimes didn't correspond to the correct database. I think it's 
due to the dormant dictionary key is (thread_id, connector) which is not 
enough now when the pool is process wide.

Anyway, I've attached my attempt at a process-wide LRU based connection 
pool. It's still a work in progress but it would be very interesting to 
know if and how well it works in your setup.
I also added some code to close all connections that are unused for more 
than 60 seconds.

One thing I still would like to add is making it possible to share 
connections between Trac environments using the same database (and role)
(Continue reading)

Permalink | Reply | 7 comments |
headers
David Abrahams | 2 Jun 04:04
Picon
Picon
Favicon
Gravatar

[Trac-dev] Re: "database is locked" back on t.e.o.


on Sun Jun 01 2008, Jonas Borgström <jonas-AT-edgewall.com> wrote:

> David Abrahams wrote:
>> on Fri May 30 2008, David Abrahams <dave-AT-boostpro.com> wrote: 
>> 
>>>> I have actually been thinking about making Trac use a single global db 
>>>> pool instead of one pool for each environment in each process.
>>> Yep, that's what we need, or something very like it.  Of course, each of
>>> my environments connects with a different schema and role, so
>>> connections aren't interchangeable.  I could think about changing that,
>>> but I'm thinking the short-term fix is to build an LRU cache of all the
>>> connections in any pool, and simply throw out the oldest ones when the
>>> cache is full and a new one is requested.
>> 
>> Actually, your approach turned out to be easier.  My patched pool.py
>> follows
>
> Hi David,
>
> When I tested your patch I noticed that the connections returned by the 
> pool sometimes didn't correspond to the correct database. 

In my installation most of the instances are hitting the same database
with different Postgresql schemas.  The one instance that was using a
different DB kept reporting that it needed an upgrade even though
trac-admin upgrade refused to do anything, so maybe that accounts for
what I'm seeing... although "same DB, different schema" is not really
all that different from "different DB".
(Continue reading)

Permalink | Reply | 6 comments |
headers
Robert C Corsaro | 2 Jun 16:18
Favicon

[Trac-dev] Re: Report for dynamic variables


krkempa wrote:
> Christian, I couldn't agree more on what you wrote. That's exactly my
> point.
> 
> Noah's wrote:
>> That kind of huge collection of features might
>> be good for boxing up and shipping to people that want a turnkey
>> solution, but they aren't much use in the Trac community
> 

We have tried to put functionality into reusable components, but some 
features are so small, they can't warrant there own plugin.  It didn't 
seem worth while to us to maintain a plugin that adds one simple filter. 
  Yet the code was still of value to the community as it was posted here 
and someone used it.  I think you bring up an important point though. 
I'm just not sure what the solution is.  Obviously posting code to the 
list is not ideal.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Christian Boos | 2 Jun 16:44
Picon

[Trac-dev] Re: Report for dynamic variables


Christopher Lenz wrote:
> Hey Christian,
>   

Hello Chris,

Nice to see we had many points of convergence here, so I'll skip over 
those and go straight to the parts that need a follow-up.

But before doing that, I would suggest that you could perhaps sum up the 
position on which we mainly agreed, about the guidelines for what should 
rather be done as a plugin and what should rather be contributed as a 
patch to Trac proper. This would be an useful addition to the 
TracDev/PluginDevelopment page for example, answering the "what" 
question in addition to the "how", and you have more authority than I 
have to speak on this topic.

> On 30.05.2008, at 11:00, Christian Boos wrote:
>   
>> Now to answer the question "why has the Trac team avoided  
>> implementation
>> of such essential feature (#31) for 4 years", it's quite simple: the
>> TracCrossReferences effort which was started (3 years ago) to address
>> that issue, among other things, didn't get any "traction", quite to  
>> the
>> contrary, so it ended up in a branch which I stopped maintaining  
>> after a
>> while.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Boos | 2 Jun 16:45
Picon

[Trac-dev] About memory leaks in 0.11-rc1 (was Re: seen this?)


David Abrahams wrote:
> IIRC, I'm still seeing growth to impressive sizes (~600M) even with
> 0.11-rc1.  I've been having to restart my trac daily for other reasons
> (too many pooled DB connections), so I don't know if it continues to
> grow from there but my impression is that things are still a bit out of
> control.  However, I'm about to fix the DB issue and will be able to get
> a better read on the memory consumption thereafter.  I'll keep you
> posted.
>   

You may want to try a more recent revision from 0.11-stable (> r7135), 
as I've squished another mem leak in r7133.
Also be sure to use a recent version of Genshi, as noted in #6614.

I agree the issue is probably not completely solved, so if someone has a 
recent Trac installation which exhibits an ever growing memory usage, 
please discuss it first here and we'll create a new ticket for tracking 
the progress made.

-- Christian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac Development" group.
To post to this group, send email to trac-dev <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
(Continue reading)

Permalink | Reply | 0 comments |
headers
Culapov Andrei | 2 Jun 16:55
Picon

[Trac-dev] Re: Report for dynamic variables


posted patch to trac
http://trac.edgewall.org/ticket/7293

On Thu, May 29, 2008 at 4:33 PM, Christian Boos <cboos <at> neuf.fr> wrote:
>
> Culapov Andrei wrote:
>> Hi Richard,
>> we implemented something exactly like this. Take a look
>> https://projects.optaros.com/trac/oforge/report/9
>>
>
> 401 :-)
>
> Other than that, the code looks interesting and even more so the OForge
> project.
> However, for this particular feature, I think it would have made more
> sense to write a patch against Trac, instead of writing a request filter
> + stream filter, as (to me at least) this issue looks more like a defect
> of the report subsystem rather than an optional feature: if you don't
> set the PRIORITY dynamic var, Trac reports an error page with no way to
> specify that value, which is not terribly useful. A simple list of input
> boxes for the missing variables would do, and plugins could still be
> implemented if anything more fancy is needed.
>
> -- Christian
>
> >
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christian Boos | 2 Jun 17:02
Picon

[Trac-dev] Re: Report for dynamic variables


Culapov Andrei wrote:
> posted patch to trac
> http://trac.edgewall.org/ticket/7293
>
>   

Thanks, but I was already reading it ;-)
Looks quite good to me.

-- Christian

> On Thu, May 29, 2008 at 4:33 PM, Christian Boos <cboos <at> neuf.fr> wrote:
>   
>> Culapov Andrei wrote:
>>     
>>> Hi Richard,
>>> we implemented something exactly like this. Take a look
>>> https://projects.optaros.com/trac/oforge/report/9
>>>
>>>       
>> 401 :-)
>>
>> Other than that, the code looks interesting and even more so the OForge
>> project.
>> However, for this particular feature, I think it would have made more
>> sense to write a patch against Trac, instead of writing a request filter
>> + stream filter, as (to me at least) this issue looks more like a defect
>> of the report subsystem rather than an optional feature: if you don't
>> set the PRIORITY dynamic var, Trac reports an error page with no way to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane