headers
gctrekker | 2 Feb 17:20
Picon

[Trac-dev] Re: A Christmas gift - TicketDep plugin


I renamed the file from 2.4 to 2.5 and it worked with adding
'ticketdep.* = enabled' to trac.ini file.  I liked what it does,
except it was appearing on all tickets even if they do not have
dependencies.  This may be configurable but I did not see how.  It
should work like "depgraph" - it is only available when a dependency
is in a ticket.   I also decided to not use it since the source is not
available and the author does not want to maintain it.  I would not
like our team to get dependent on something that may not work down the
road.

On Jan 25, 9:53 am, "rupert.thur...@gmail.com"
<rupert.thur...@gmail.com> wrote:
> how did you get to run? the description says the download is for
> python-2.4? ie. how would one migrate it to 2.5, just unpack and
> repack?
>
> rupert.
>
> On Jan 20, 4:19 pm, gctrekker <gctrek...@gmail.com> wrote:
>
> > I recently installed MasterTicketsPlugin but have not installed
> > Graphviz.  I also do not find the graphs to be very informative.  I do
> > like what TicketDep describes but I have not been successful in
> > getting it to run.
>
> > I have the TracTicketDep-0.11_20081224-py2.4.egg file installed in our
> > Trac plugins directory but I cannot get it to function.
>
> > Do I need to add something into the trac.ini [components]?
(Continue reading)

Permalink | Reply | 0 comments |
headers
rupert.thurner@gmail.com | 3 Feb 05:18
Picon
Gravatar

[Trac-dev] time based releases, to get iso date format ?


i was wondering if the trac project could do time based releases? e.g.
release a version every 3 months, or 6 months, no matter how many
ticktes got fixed.

mercurial was sometimes critizised for long release cycles, client
software already used features in trunk which then got released much
later, but this seems to have gone away completely with a change to a
3 months release cycle.

also ubuntu is doing quite well with their 6 months release cycle.

this mail is triggered by pure egoism :) we currently have slovak
month and day names in our scrum sheets as we could not find a locale
for entering iso date format. so a little feature like iso date format
fixed quite some time ago turned out to be kind of a blocker for the
whole trac installation.

rupert.

--~--~---------~--~----~------------~-------~--~----~
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 | 3 comments |
headers
Remy Blank | 3 Feb 09:27
Picon
Favicon

[Trac-dev] Re: time based releases, to get iso date format ?

rupert.thurner <at> gmail.com wrote:
> i was wondering if the trac project could do time based releases? e.g.
> release a version every 3 months, or 6 months, no matter how many
> ticktes got fixed.

This would probably be quite easy for bugfix releases (0.11.2, 0.11.3,
...), and more difficult for feature releases (0.12, 0.13, ...), as
trunk is not always in a stable state (it usually is, though).

But I suppose that if we switch to time-based releases, we would have to
change the development model anyway, along the lines of:

 - 0.x are time-based releases
 - 0.x.y are security releases, i.e. only happen if security issues are
fixed
 - 0.x is only supported until 0.(x+1) is released

I suppose that this model could be more difficult for plugin authors, as
they would have to track trunk development more closely.

FWIW, I'd be +1 on the idea, provided we find a suitable development /
support model.

-- Remy
Permalink | Reply | 1 comment |
headers
Christian Boos | 3 Feb 19:03
Picon

[Trac-dev] Re: time based releases, to get iso date format ?


Remy Blank wrote:
> rupert.thurner <at> gmail.com wrote:
>   
>> i was wondering if the trac project could do time based releases? e.g.
>> release a version every 3 months, or 6 months, no matter how many
>> ticktes got fixed.
>>     
>
> This would probably be quite easy for bugfix releases (0.11.2, 0.11.3,
> ...), and more difficult for feature releases (0.12, 0.13, ...), as
> trunk is not always in a stable state (it usually is, though).
>
> But I suppose that if we switch to time-based releases, we would have to
> change the development model anyway, along the lines of:
>
>  - 0.x are time-based releases
>  - 0.x.y are security releases, i.e. only happen if security issues are
> fixed
>  - 0.x is only supported until 0.(x+1) is released
>
> I suppose that this model could be more difficult for plugin authors, as
> they would have to track trunk development more closely.
>
> FWIW, I'd be +1 on the idea, provided we find a suitable development /
> support model.
>   

Well, we already had a time based release in place for the coming 
milestones, only we didn't stick to it :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Boos | 4 Feb 08:27
Picon

[Trac-dev] Re: time based releases, to get iso date format ?


rupert.thurner <at> gmail.com wrote:
> ... we currently have slovak
> month and day names in our scrum sheets as we could not find a locale
> for entering iso date format. so a little feature like iso date format
> fixed quite some time ago turned out to be kind of a blocker for the
> whole trac installation.
>   

What feature is that? If you're thinking about #2182/#1690, that's still 
opened.

-- 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
-~----------~----~----~----~------~----~------~--~---
Permalink | Reply | 0 comments |
headers
Jeffrey | 4 Feb 09:09
Picon
Favicon

[Trac-dev] Re: A Christmas gift - TicketDep plugin


I would really appreciate if TicketDep could be integrated with
MasterTickets as Noah suggested.  While plug-ins are a great way to
extend Trac, having plug-ins dependent on other plug-ins can be
fragile.

I would guess that 99.99% of all users that need MasterTickets, would
also love to have TicketDep integrated with it.  I have installed both
plug-ins, but I have a queezy feeling that they will stop working with
each other one day.

*Please* clear up the licensing issue somehow.  Let's try to move Trac
forward and the only way I can see that happening is:

    1. good quality code
    2. liberal licencing

That is my 2 cents.

Jeffrey

> Such a thing could be added to mastertickets directly, however you  
> have chosen to license it under the GPLv3, which is incompatible the  
> BSD license used by my plugins.
>
> --Noah
>
> On Dec 24, 2008, at 5:36 AM, Risto Kankkunen wrote:
>
>    .
(Continue reading)

Permalink | Reply | 1 comment |
headers
anatoly techtonik | 8 Feb 03:03
Picon
Gravatar

[Trac-dev] Stopped sync in 0.11.2.1


Hello,

Any ideas why Trac may stop syncing cache with repository after
upgrading to 0.11.2.1?
The log is full of strange messages about insufficient privileges for
creating pages.

2009-02-07 17:55:11,224 Trac[__init__] DEBUG: Dispatching <Request
"GET u'/timeline'">
2009-02-07 17:55:11,402 Trac[__init__] DEBUG: Subversion bindings imported
2009-02-07 17:55:11,417 Trac[__init__] INFO: repos rev [2557] !=
cached rev [2414]
2009-02-07 17:55:11,424 Trac[__init__] DEBUG: Retrieving session for
ID '4b0a7707907d96a01f8ff7e0'
2009-02-07 17:55:11,803 Trac[__init__] DEBUG: Prepare chrome data for request
2009-02-07 17:55:11,805 Trac[__init__] DEBUG: No policy allowed
anonymous performing TRAC_ADMIN on None
2009-02-07 17:55:11,806 Trac[__init__] DEBUG: No policy allowed
anonymous performing PERMISSION_GRANT on None
2009-02-07 17:55:11,806 Trac[__init__] DEBUG: No policy allowed
anonymous performing PERMISSION_REVOKE on None
2009-02-07 17:55:11,336 Trac[__init__] DEBUG: No policy allowed
anonymous performing EMAIL_VIEW on None
2009-02-07 17:55:12,509 Trac[__init__] DEBUG: Updating wiki page index
2009-02-07 17:55:12,511 Trac[__init__] DEBUG: No policy allowed
anonymous performing WIKI_CREATE on <Resource u'wiki:FreeFindData'>
2009-02-07 17:55:12,013 Trac[__init__] DEBUG: No policy allowed
anonymous performing WIKI_CREATE on <Resource u'wiki:KeyBarLabels'>
2009-02-07 17:55:12,746 Trac[__init__] DEBUG: No policy allowed
(Continue reading)

Permalink | Reply | 6 comments |
headers
Christian Boos | 8 Feb 12:32
Picon

[Trac-dev] Re: Stopped sync in 0.11.2.1


Hello Anatoly,

anatoly techtonik wrote:
> Hello,
>
> Any ideas why Trac may stop syncing cache with repository after
> upgrading to 0.11.2.1?
> The log is full of strange messages about insufficient privileges for
> creating pages.
>
> 2009-02-07 17:55:11,224 Trac[__init__] DEBUG: Dispatching <Request
> "GET u'/timeline'">
> 2009-02-07 17:55:11,402 Trac[__init__] DEBUG: Subversion bindings imported
> 2009-02-07 17:55:11,417 Trac[__init__] INFO: repos rev [2557] !=
> cached rev [2414]
>   

I've already seen that once on someone's machine (hi John ;-) ), without 
having a clue about it.
So it would be very helpful if you could spend some time debugging this 
in depth.
By inserting enough debug statements in trac/versioncontrol/cache.py, 
you should be able to get a clue about what's going on (e.g. missing 
read permission on the svn repo?).

> 2009-02-07 17:55:11,424 Trac[__init__] DEBUG: Retrieving session for
> ID '4b0a7707907d96a01f8ff7e0'
> 2009-02-07 17:55:11,803 Trac[__init__] DEBUG: Prepare chrome data for request
> 2009-02-07 17:55:11,805 Trac[__init__] DEBUG: No policy allowed
(Continue reading)

Permalink | Reply | 5 comments |
headers
anatoly techtonik | 8 Feb 15:22
Picon
Gravatar

[Trac-dev] Re: Stopped sync in 0.11.2.1


On Sun, Feb 8, 2009 at 1:32 PM, Christian Boos <cboos <at> neuf.fr> wrote:
>>
>> Any ideas why Trac may stop syncing cache with repository after
>> upgrading to 0.11.2.1?
>> The log is full of strange messages about insufficient privileges for
>> creating pages.
>>
>> 2009-02-07 17:55:11,224 Trac[__init__] DEBUG: Dispatching <Request
>> "GET u'/timeline'">
>> 2009-02-07 17:55:11,402 Trac[__init__] DEBUG: Subversion bindings imported
>> 2009-02-07 17:55:11,417 Trac[__init__] INFO: repos rev [2557] !=
>> cached rev [2414]
>>
>
> I've already seen that once on someone's machine (hi John ;-) ), without
> having a clue about it.
> So it would be very helpful if you could spend some time debugging this
> in depth.
> By inserting enough debug statements in trac/versioncontrol/cache.py,
> you should be able to get a clue about what's going on (e.g. missing
> read permission on the svn repo?).

It turned out to be locked cache after timeout. At first I thought
about a race condition, but it was false. The cache can easily be
jammed with a long resync from repository on a busy server. It took
about 40 seconds to sync 200 revisions before timeout occurred. Take a
cache.py sync()
http://trac.edgewall.org/browser/branches/0.11-stable/trac/versioncontrol/cache.py#L158
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christian Boos | 8 Feb 20:23
Picon

[Trac-dev] Re: Stopped sync in 0.11.2.1


anatoly techtonik wrote:
> On Sun, Feb 8, 2009 at 1:32 PM, Christian Boos <cboos <at> neuf.fr> wrote:
>   
>>> Any ideas why Trac may stop syncing cache with repository after
>>> upgrading to 0.11.2.1?
>>> The log is full of strange messages about insufficient privileges for
>>> creating pages.
>>>
>>> 2009-02-07 17:55:11,224 Trac[__init__] DEBUG: Dispatching <Request
>>> "GET u'/timeline'">
>>> 2009-02-07 17:55:11,402 Trac[__init__] DEBUG: Subversion bindings imported
>>> 2009-02-07 17:55:11,417 Trac[__init__] INFO: repos rev [2557] !=
>>> cached rev [2414]
>>>
>>>       
>> I've already seen that once on someone's machine (hi John ;-) ), without
>> having a clue about it.
>> So it would be very helpful if you could spend some time debugging this
>> in depth.
>> By inserting enough debug statements in trac/versioncontrol/cache.py,
>> you should be able to get a clue about what's going on (e.g. missing
>> read permission on the svn repo?).
>>     
>
> It turned out to be locked cache after timeout. At first I thought
> about a race condition, but it was false. The cache can easily be
> jammed with a long resync from repository on a busy server. It took
> about 40 seconds to sync 200 revisions before timeout occurred. Take a
> cache.py sync()
(Continue reading)

Permalink | Reply | 3 comments |

Gmane