headers
Michael Renzmann | 1 Dec 06:57
Picon
Favicon
Gravatar

[Trac-dev] Minor issue with trac-admin (Trac 0.11.6)

Hi all.

I'm currently messing with trac-admin and noticed that the help for "wiki"
suggests that both, export and import, have an optional parameter "file".
Omitting file means that the content of the wiki page in question will be
written to stdout/read from stdin, according to the help.

However, the implementation is different: omitting file will cause the
command to fail. While _do_wiki_export would work as expected when no
filename is passed to it, _do_wiki_import would complain.

This could be fixed either by correcting the help text (which then would
state that "file" is mandatory), or by adjusting the programming logic.
Which of both options should be preferred?

Bye, Mike

--

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 | 2 comments |
headers
Doki Pen | 1 Dec 05:55
Gravatar

[Trac-dev] Trac Notifications

I want to revisit this topic[0]:

I took over the abandoned AnnouncerPlugin[1] last year.  I've been working on 
the AnnouncerPlugin quite a bit[2].  I'd like to know what we need to do to 
get this thing into trac.  

One thing that is becoming cumbersome is supporting backward compatibility 
with trac notifications.  Specifically, other plugins use the Notification api
to send their own notifications.  This code has to be reimplemented using the 
AnnouncerPlugin api since the Notification api is not very extensible.  

I still think AnnouncerPlugin needs a good amount of work before being 
included in core, but I think it's at a point where I need specific feedback.
The core API is very stable.   The existing notification functionality is 
there.  I think the arch is well described in api.py, but I'd be happy to 
write up a proposal on the wiki.

What do you think?

[0] http://groups.google.com/group/trac-dev/browse_thread/thread/93190fbd9eae48d9/25ccafab5d89ed02
[1] http://trac-hacks.org/wiki/AnnouncerPlugin
[2] http://trac-hacks.org/query?status=new&status=assigned&status=reopened&status=closed&group=status&component=AnnouncerPlugin&order=priority

--

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 | 10 comments |
headers
Christian Boos | 1 Dec 10:47
Picon

Re: [Trac-dev] Minor issue with trac-admin (Trac 0.11.6)

Michael Renzmann wrote:
> Hi all.
>
> I'm currently messing with trac-admin and noticed that the help for "wiki"
> suggests that both, export and import, have an optional parameter "file".
> Omitting file means that the content of the wiki page in question will be
> written to stdout/read from stdin, according to the help.
>
> However, the implementation is different: omitting file will cause the
> command to fail. While _do_wiki_export would work as expected when no
> filename is passed to it, _do_wiki_import would complain.
>
> This could be fixed either by correcting the help text (which then would
> state that "file" is mandatory), or by adjusting the programming logic.
> Which of both options should be preferred?
>   

I think this is issue http://trac.edgewall.org/ticket/3532
There's even a patch you could test, if it works I'll look into 
integrating it for 0.12.

-- 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 | 1 comment |
headers
Michael Renzmann | 1 Dec 12:36
Picon
Favicon
Gravatar

Re: [Trac-dev] Minor issue with trac-admin (Trac 0.11.6)

Hi Christian.

> I think this is issue http://trac.edgewall.org/ticket/3532
> There's even a patch you could test, if it works I'll look into
> integrating it for 0.12.

The ticket covers only the "wiki import" part, but leaves out "wiki
export". I'll test the patch as soon as I'm done with hacking trac-admin
(see below) and will extend it to also fix the export stuff.

NB: I'm currently hacking trac-admin in order to add an option that allows
to "replace" the latest version of given wiki pages rather than updating
them. This is required for the 0.11-upgrade of trac-hacks.org, for fixing
the use of the (no longer available) tagit-macro. That macro is used on
~2400 wiki pages - updating them all with the regular "wiki import" (or
"wiki load") stuff would result in ~2400 timeline events...

Would it be worth to submit the resulting patch in a ticket, for review
and possibly inclusion?

Bye, Mike

--

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
Remy Blank | 1 Dec 19:36
Picon
Favicon

Re: [Trac-dev] Trac Notifications

> One thing that is becoming cumbersome is supporting backward compatibility 
> with trac notifications.  Specifically, other plugins use the Notification api
> to send their own notifications.  This code has to be reimplemented using the 
> AnnouncerPlugin api since the Notification api is not very extensible.  

So the least we could do is add an extension point allowing to re-route
the calls to the current notification system.

> What do you think?

I'd certainly welcome a more flexible notification system. The plugin
looks quite complex, but very well designed (I haven't looked at the
code yet). Personally, I'm most interested in the "watch this"
functionality, but I'm sure others will find the other features useful
as well.

I only read the wiki page for the plugin, and haven't played with the
plugin yet, but my impression is that the configuration can be quite
complicated. I'm a bit concerned about this, as Trac already seems to be
a challenge in its current state. But maybe this is a wrong impression,
I'll try the plugin to get a better idea.

-- Remy
Permalink | Reply | 5 comments |
headers
doki_pen | 1 Dec 20:19
Gravatar

Re: [Trac-dev] Trac Notifications

In gmane.comp.version-control.subversion.trac.devel, you wrote:
>> One thing that is becoming cumbersome is supporting backward compatibility
>> with trac notifications.  Specifically, other plugins use the Notification api 
>> to send their own notifications.  This code has to be reimplemented using the
>> AnnouncerPlugin api since the Notification api is not very extensible. 
>
> So the least we could do is add an extension point allowing to re-route
> the calls to the current notification system.
I'd hate to spend time making the old system more like announcer.

>> What do you think?
>
> I'd certainly welcome a more flexible notification system. The plugin
> looks quite complex, but very well designed (I haven't looked at the
> code yet). Personally, I'm most interested in the "watch this"
> functionality, but I'm sure others will find the other features useful
> as well.

I'm thinking that I could strip everything but the ticket_compat module
and make any new functionality into plugins.  There is some code
duplication between modules that I could start moving into some utility
module.  This is the type of stuff that was hard to predict, but once
you start making plugins, it becomes clear.

>
> I only read the wiki page for the plugin, and haven't played with the
> plugin yet, but my impression is that the configuration can be quite
> complicated. I'm a bit concerned about this, as Trac already seems to be
> a challenge in its current state. But maybe this is a wrong impression,
> I'll try the plugin to get a better idea.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Remy Blank | 1 Dec 22:09
Picon
Favicon

Re: [Trac-dev] Trac Notifications

doki_pen <at> doki-pen.org wrote:
> I'd hate to spend time making the old system more like announcer.

That's not what I meant, sorry for being unclear. I understood that the
lack of a hook in the current notification system was a burden on
AnnouncerPlugin, and I was suggesting we add that hook (as an extension
point) to make it easier for you to catch calls from other plugins
sending notifications. Did I get this wrong?

-- Remy
Permalink | Reply | 3 comments |
headers
Doki Pen | 1 Dec 22:32
Gravatar

Re: [Trac-dev] Trac Notifications

On 2009-12-01, Remy Blank <remy.blank <at> pobox.com> wrote:
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enigB922B00F8E9BE87F390DD041
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> doki_pen <at> doki-pen.org wrote:
>> I'd hate to spend time making the old system more like announcer.
>
> That's not what I meant, sorry for being unclear. I understood that the
> lack of a hook in the current notification system was a burden on
> AnnouncerPlugin, and I was suggesting we add that hook (as an extension
> point) to make it easier for you to catch calls from other plugins
> sending notifications. Did I get this wrong?

It makes sense in theory, but not in practice.  The way the system
currently works is that plugins extend NotifyEmail.  In their
constructor the call NotifyEmail.notify, which calls there email
constructing logic(get_recipients(), send()).  Announcer seperates these
steps into 

Producer    : produces and event
Subscriber  : figures out what users to notify of the event
Formatter   : creates the content for the event
Distributer : actually create and distribute the email (including 
              headers)

Most plugins want to do the first three, but not that last one.  With
the old system they are very much doing the last one, but worse,
formatting and distributing are mixed together.  Also, the notify method
(Continue reading)

Permalink | Reply | 2 comments |
headers
Tim Hatch | 2 Dec 03:43
Favicon
Gravatar

Re: [Trac-dev] Test failures on buildbot

> Tim Hatch wrote:
>> In other testing news, it looks like the minimum Genshi version has
>> increased again (beyond what I had on the OS X box), causing
>> strange-looking failures running trac-admin.  At some point we need to
>> make a test for that to get an understandable failure.
> 
> Yes, Christopher has merged the advanced-i18n branch back into trunk,
> and we now require at least that revision. When you say "strange-looking
> failures running trac-admin", I assume you mean that trac-admin refuses
> to run because Genshi>=0.6dev-r1072 is not provided, right?

Yes, the unit test output shows 74 failures, none of which imply that
it's a version issue.  Functional test output is much better, containing
a single failure with the traceback from the failed
pkg_resources.require().  We should either skip the trac-admin tests
when this requirement isn't met, or fail the whole test since running
Trac without current Genshi isn't supported as far as I know.

Unit:
http://buildbot.timhatch.com/trac/builders/OS%20X%2010.5%20py26%20intel/builds/50/steps/unit%20tests/logs/stdio

Functional:
http://buildbot.timhatch.com/trac/builders/OS%20X%2010.5%20py26%20intel/builds/50/steps/functional%20tests/logs/stdio

> I have also seen spurious failures due to random words being too long.
> Some tests choose 5 random words e.g. for ticket summaries, and if all
> words are relatively long, format_to_oneliner() shortens the summary
> with an ellipsis, which makes some tests fail.

Whoops.  I've made patches locally for that, will test further and push
(Continue reading)

Permalink | Reply | 1 comment |
headers
victoria | 1 Dec 18:33
Picon

[Trac-dev] Re: Trac 0.11.6 Released


Hi,

I'm Victoria from BitNami project. I don't know if you know the
project but summarizing it we pack open source applications with all
their depencies and we distribute them completly free. We have
received lot of request from our users for upgrading our package of
Trac and finally we have released a new package that includes Trac
0.11.6, Apache 2.2.13, Subversion 1.6.6 and SQLite. We'll really
appreciate if you, as Trac experts, could take a look into it and give
us your feedback. We are willing to improve it in order to give a
satisfactory experience for all users that use Trac by means of
BitNami.

I include some links. It would not interfere with any software
installed in your system so if you already have a different version of
Trac, Pyhon, etc, don't worry, this will not break anything. It
doesn't add anything to your path, nor any other enviroment variable.
Also when you uninstall it, it will remove everything that was
installed.

http://bitnami.org/files/stacks/trac/0.11.6-0/bitnami-trac-0.11.6-0-windows-installer.exe
http://bitnami.org/files/stacks/trac/0.11.6-0/bitnami-trac-0.11.6-0-linux-installer.bin
http://bitnami.org/files/stacks/trac/0.11.6-0/bitnami-trac-0.11.6-0-osx-x86-installer.app.zip
http://bitnami.org/files/stacks/trac/0.11.6-0/bitnami-trac-0.11.6-0-opensuse-11.1.zip

Thanks in advance,

Victoria.
On Nov 29, 12:48 am, Christian Boos <cb...@neuf.fr> wrote:
(Continue reading)

Permalink | Reply | 9 comments |

Gmane