Team Chat Logs

April 5, 2010

2010 3
Mo Tu We Th Fr Sa Su
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
<< <   > >>

[00:24:31.261278]<macmaN>:q
[00:25:09.842839]<macmaN>isn't pytz and default_timezone enough to make milestone dates appear in local format?
[00:39:26.862327]<macmaN>mmmkay ran into #9188 now
[00:48:19.599951]<macmaN>ahh datefield
[00:48:23.857546]<macmaN>[datefield] even
[00:49:33.916604]<macmaN>and TracFaq
[00:53:21.155381]<macmaN>and SetEnv
[06:41:22.040582]<cboos>rblank: hello Remy, about #9060 I have 3 pending patches - pasting them in a minute so you can have a look
[06:41:43.697263]<rblank>cboos: Sure, shoot away
[06:45:24.233177]<rblank>cboos: Did you intend to close http://trac.edgewall.org/ticket/9183 ?
[06:45:44.415699]<cboos>ah yes, forgot
[06:47:50.608043]<cboos>mh, no notifications from the paste server it seems
[06:48:12.077512]<cboos>http://paste.lisp.org/display/97349
[06:48:21.362357]<cboos>http://paste.lisp.org/display/97350
[06:51:09.525303]<cboos>and http://paste.lisp.org/display/97351
[06:52:19.591196]<cboos>who else is around? osimons? s0undt3ch?
[06:52:36.216021]<cboos>eli?
[06:52:55.958773]<cboos>I'd like to discuss the Genshi/Babel situation a bit
[06:56:40.362204]<rblank>cboos: First patch is good, please apply.
[07:00:49.190730]<rblank>cboos: Second one is good, too. I wasn't aware of #4465, so good catch!
[07:02:38.810242]<cboos> yeah, one of the next thing I'll do is to add tons of debug statements in the pool, to try to understand /really/ what's going on with #8443 ;-)
[07:05:01.474344]<rblank>cboos: About the third patch, "@self.env.with_transaction()" looks a bit ugly ATM, but it will become better once we can write "with self.env.transaction() as db do:"
[07:06:04.665560]<cboos>yes, and as this will happen "soon" I thought it's better not to annoy people with an extra import ;-)
[07:06:08.496916]<rblank>cboos: About #8443 and debug statements, be careful that logging also involves locking, so you might influence the experiment.
[07:06:34.207690]<rblank>I'm fine with all three patches, then.
[07:07:19.094875]<cboos>ok, first two already committed, let's test a last time the 3rd (had to fix a few conflicts)
[07:11:45.291569]<cboos>Remy, did you already give a thought about the situation we have with Genshi and Babel? The packages are in serious lack of maintenance, and we should find a solution to 1) get some releases done before we ship 0.12rc1 (Babel 0.9.5 and Genshi 0.6), 2) find a way to get regular maintenance releases as we need them
[07:12:49.641032]*rblank is thinking...
[07:12:57.053938]<rblank>(hard)
[07:13:00.493172]<cboos>The "nicest" solution would be to make official releases ourselves, clearly mentioning those releases are "ok" for Trac, and should be used with caution for other projects (i.e. no other guarantee that it works for us)
[07:13:30.173925]<rblank>"Really nicest" would be to get official releases out :)
[07:13:37.849309]<rblank>(By cmlenz, I suppose)
[07:13:37.932559]<cboos>forget it
[07:14:04.079126]<rblank>Then, your suggestion might be "second nicest" :)
[07:15:09.691349]<cboos>even if by chance we get a 0.6 release in time, the situation will repeat for the next maintenance release, so I don't really think this would be the best solution... no we really have to find something more future proof
[07:15:52.820487]<cboos>so, realistically, either make those releases ourselves, but for now we're lacking permission to do so; second solution would be to "fork" those packages
[07:16:25.486938]<cboos>and have some svn:externals + some renaming /genshi/tracgenshi/ and /babel/tracbabel/, for example
[07:16:52.727052]<cboos>I don't really like that, but I like even less being stuck ...
[07:18:45.207377]<rblank>I was also thinking about svn:externals. But if we keep the namespace "genshi", it will prevent installation of the "official" genshi, and if we rename, we have to rename all occurrences in genshi as well.
[07:19:03.585329]<rblank>Unless we do some import magic (which has been problematic in the past, IIRC)
[07:20:09.114469]<cboos>right, svn:externals more or less implies we override 'genshi'; if we do a rename, we need a re-import of the sources + changing all the import statement, or find some ugly tricks
[07:20:43.732657]<cboos>or we keep the genshi package name and find some trick with the version
[07:21:20.273524]<cboos>like 0.6.5
[07:21:37.193040]<cboos>or 0.6.trac12
[07:21:44.634710]<cboos>if that works
[07:21:49.918315]<rblank>Can you do that with setuptools?
[07:22:01.089257]<cboos>let me try
[07:24:04.664932]<cboos>works fine yes
[07:24:23.448727]<cboos>- 'Genshi>=0.6dev-r1072'
[07:24:28.285916]<cboos>+ 'Genshi>=0.6.trac-0.12dev-r1072'
[07:25:21.622802]<rblank>And what is higher, 0.6 or 0.6.trac-* ?
[07:25:57.114379]<cboos>what I tested is that when you require 'Genshi>=0.6.trac-0.12dev-r1072' a regular 'Genshi>=0.6dev-r1072' won't work
[07:26:01.897200]<cboos>let me try the opposite
[07:26:29.923266]<rblank>And can you have both 0.6 and 0.6.trac-* installed at the same time?
[07:26:43.599852]<cboos>with a multi-install I supppose
[07:26:51.646720]<cboos>(easy-install -m
[07:26:54.265130]<cboos>)
[07:26:57.367535]*rblank is reaching for the setuptools doc
[07:27:22.463323]<cboos> --multi-version (-m) make apps have to require() a version
[07:27:38.264954]<elisa87>is this information real? https://rt.ubuntu.com/Ticket/Display.html?id=10274 or just for learning?
[07:28:02.933163]<elisa87>what is the best "trouble ticketing " system to be chosen for a company?
[07:28:14.459772]<cboos>elisa87: JIRA? ;-)
[07:28:50.328082]<elisa87>what if the systems are using Windows as OS? what tracking sys should be used?
[07:28:56.582869]<rblank>cboos: Ok, -m would work, but we will probably feel the hatred of Linux distro packagers :)
[07:28:58.036513]<elisa87>cboos i don't know
[07:29:03.639066]<elisa87>i'm asking from users
[07:29:06.716861]<cboos>elisa87: seriously, what do you expect when asking such a question on a channel dedicated to the development of a ticket system (among other things...)
[07:29:16.474619]<elisa87>some tell rt but they tell it's hard to install
[07:29:50.455327]<elisa87>cboos i saw trac listed as first trouble ticketing system
[07:29:55.383386]<elisa87>but want to be sure
[07:30:03.539669]<elisa87>can it be used on windows?
[07:30:17.933127]<cboos>elisa87: so let's go for that, Trac is the first trouble ticketing system, go for it!
[07:30:38.286086]<cboos>elisa87: on Windows, I would recommend to have a look at the BitNami stack for Trac
[07:30:39.229606]<rblank>cboos: Come to think of it, having both a Genshi and Babel fork will certainly annoy packagers.
[07:31:01.444981]<cboos>elisa87: http://bitnami.org/stack/trac
[07:31:12.453895]<elisa87>some say remedy is best
[07:31:26.905726]<cboos>rblank: but what if we make those /part/ of the Trac install?
[07:31:28.464300]<elisa87>i'm just a litttle bit confused as i am debutant to this field
[07:32:21.351247]<rblank>cboos: That's more or less the only solution, yes. Then we might as well hide them in the trac or tracopt namespace.
[07:32:47.752393]<rblank>cboos: "tracdep"
[07:32:59.662182]<cboos>If that's not too troublesome for the imports and so one, I'd also prefer that (tracdep, yes, why not)
[07:33:22.727888]<elisa87>what is a sms server in a trouble ticketing system? can you name a few sms servers?
[07:33:43.599688]<cboos>rblank: I wanted to feel the sentiment about this before wasting time experimenting with it?
[07:33:44.755886]<rblank>Genshi might be pretty easy. Babel requires downloading some CDR stuff IIRC, so that might make installing (even) more difficult.
[07:34:39.455238]<cboos>makes it a bit more troublesome to prepare the packages yes, but that could probably be automated in the Makefile
[07:34:59.652178]<cboos>"make release" et hop! ;-)
[07:35:15.840516]<rblank>cboos: I still think that we should ask one last time on each of the relevant mailing lists, if 1) a release would be doable wihtin a given timespan and 2) if not, what the developers suggest.
[07:35:50.765425]<rblank>cboos: I can do that, if you like.
[07:36:07.296292]<cboos>if you want, but 1) is a clear no, 2) is a good thing to ask
[07:36:23.341475]<elisa87>is trac web based?
[07:36:30.256410]<elisa87>is trac easy to be installed?
[07:36:32.640608]<rblank>elisa87: Are you a bot?
[07:36:34.407793]<cboos>elisa87: is elisa bot based?
[07:36:36.583712]<cboos>hehe
[07:36:38.381707]<rblank>:)
[07:36:39.576929]<cboos>same thinking here
[07:36:50.202432]<elisa87>wow no!
[07:36:57.579260]<elisa87>cboos please don't laugh
[07:37:03.295866]<cboos>but you failed the Turing test...
[07:37:29.853192]<elisa87>i heard trouble ticketing for the first time in my life just 3 hours ago and i must select it as my job from tomorrow on!
[07:37:45.055691]<elisa87>lol
[07:37:58.136841]<rblank>elisa87: If I were you, I'd start googling right now.
[07:38:03.528450]<elisa87>i hate turing machine in linz automata book!
[07:38:10.127169]<elisa87>i'm doing
[07:38:11.199397]<elisa87>thx
[07:39:14.762112]<rblank>cboos: Do we actually require Babel trunk? Or would 0.9.4 do?
[07:39:51.181833]<cboos>0.9.4 which works fine and in which I have more confidence than 1.0dev, but 0.9.4 has a bug preventing correct polish translations
[07:40:12.931230]<cboos>so I asked for a 0.9.5 release (even offering to do it myself), but no response whatsoever yet
[07:40:20.565878]<cboos>(even to personal mail to cmlenz)
[07:40:47.042938]<cboos>I could have tried on the babel list, though
[07:41:12.425159]<rblank>And Genshi trunk is required for the i18n stuff. Ok, I'll ping both mailing lists and ask about a release or suggestions for Trac.
[07:41:46.934587]<cboos>just looking, the Babel list had had 6 messages so far in 2001
[07:41:50.622548]<cboos>2010
[07:42:47.940586]<rblank>I don't expect much either, but it's more polite to ask first before forking. And you never know, sometimes you get lucky and get a good suggestion.
[07:44:00.357608]<cboos>sure, and I *you* ask this time, maybe they'll get the impression I'm not the only one trying to bother them ;-)
[07:44:39.116494]<cboos>There's a mail from Arc Riley from beginning December asking for a 0.6 release - no answer
[07:49:03.274835]<cboos>This whole story (i18n + Genshi + Babel) made me *extremely* paranoid about new big contributions, especially those who involve 3rd party package (for example an eventual migration to SQLAlchemy - though SQLAlchemy has a different support track record)
[07:49:39.099212]<rblank>I understand.
[07:51:04.454165]<cboos>I think there's more to gain (infrastructure wise) if we upgrade the requirements, like going to Python 2.5 and context managers
[07:51:43.278432]<rblank>cboos: How's this related to 3rd party packages?
[07:51:56.980650]<rblank>(not that I'm against 2.5 and context managers, on the contrary)
[07:52:30.531626]<cboos>well, Python is also a kind of external dependency if you want ;-)
[07:52:58.141425]<rblank>That's a bit of a stretch, but still technically correct :)
[08:01:53.468052]<cboos>rblank: and more longer term, have you already thought about the possibility to get rid of Genshi, moving to Jinja for example? The performance improvements for Genshi never materialized, and I don't think it will ever happen. This is something we could do gradually, like an optional dependency and have alternate templates for the critical parts (like changeset and source display).
[08:04:21.460439]<elisa87>what is SLA?
[08:09:21.050852]<mitsuhiko>cboos: babel should no longer be an issue
[08:09:31.978705]<mitsuhiko>asmodai took over maintenance two weeks ago or so
[08:09:37.494532]<mitsuhiko>so we should finally see a new release
[08:10:02.234718]<mitsuhiko>the fun part about babel is that it's one of the libraries that *mostly* (it's not perfect) works
[08:12:33.968711]<rblank>cboos: Yes, I have thought about it (in the abstract). The trick would be to modularize the templating engine in the same way as the rest of Trac, so we can support any number of them.
[08:12:44.983568]<mitsuhiko>rblank: baaad idea
[08:12:57.542762]<rblank>mitsuhiko: Why that?
[08:13:18.758284]<mitsuhiko>far too complex
[08:13:21.376123]<mitsuhiko>especially for plugins
[08:13:36.195852]<mitsuhiko>imagine one plugin only provides templates for genshi and the website theme uses mako or whatever
[08:13:36.523223]<rblank>I don't say we must require *all* of them, only that they can be provided.
[08:13:45.117752]<mitsuhiko>rblank: why not decide on one?
[08:13:55.507367]<rblank>Ah, I didn't think of theming.
[08:14:33.202678]<cboos>I tend to think the same - I wouldn't like to support more than one, except when thinking in terms of transitioning from one to the next
[08:14:35.228935]<mitsuhiko>rblank: theming is the main reason a good template engine has to be chosen
[08:14:39.384845]<rblank>mitsuhiko: Because we've done this twice in the past, and it hasn't turned out too well. Trying to learn from our mistakes, if you will.
[08:14:40.917244]<cboos>(like we had Clearsilver -> Genshi)
[08:14:53.761291]<mitsuhiko>rblank: i did the support multiple of them mistake
[08:14:57.161949]<mitsuhiko>it was worse
[08:15:25.516899]<mitsuhiko>what i can tell you from a user perspective is that genshi sucks
[08:15:28.638006]<mitsuhiko>(trac user perspective)
[08:15:44.679174]<mitsuhiko>zzzeek did the switch recently and i a while ago and the server load after the upgrade to 0.11 was insane
[08:16:12.882653]<mitsuhiko>and keeping trac running was already quite tricky in the 0.10 days
[08:16:27.385901]<rblank>mitsuhiko: I haven't used ClearSilver at all, so I can't tell, but you're not the first one to mention this.
[08:16:45.045140]<mitsuhiko>clearsilver was fast, despite the architectural problems. but it was awful to modify
[08:16:58.237518]<mitsuhiko>i did try theming the old trac instance we had but it was pure horror
[08:17:33.168634]<cboos>... not to mention the ugliness of the Clearsilver templates themselves
[08:17:39.414639]<cboos>but yeah, it was *fast*
[08:17:53.736345]<mitsuhiko>and memory friendly
[08:18:24.729981]<mitsuhiko>i have a few good arguments for jinja2 as template engine :)
[08:18:33.166865]<rblank>The thing is, those templating engines seem to come and go at a fast pace. I wouldn't want to switch to the new kid on the block every 1-2 years.
[08:18:36.444995]<mitsuhiko>though obviously biased :)
[08:18:43.673063]<cboos>I suppose/hope Jinja2 would be in the between (faster than Genshi, slower than Clearsilver, but more flexible)
[08:18:48.268644]<mitsuhiko>rblank: genshi, mako and jinja2 will be the last for a long time
[08:18:59.957102]<rblank>Why is that?
[08:19:14.987320]<mitsuhiko>cboos: should be equally fast to clearsilver for the trac use cases
[08:19:22.003649]<mitsuhiko>rblank: paradigm shift
[08:19:24.419839]<cboos>no?!? really?
[08:19:40.557370]<rblank>cboos: Never believe a salesman :)
[08:19:55.603436]<mitsuhiko>rblank: last time i looked jinja2 and mako where close to raw python performance
[08:19:59.889956]<rblank>And no, we're not switching for 0.12 :)
[08:20:07.488359]<mitsuhiko>there are two engines which are faster but sacrifice everything for it
[08:20:21.971749]<cboos>rblank: well, 0.12 is behind us already, no? ;-)
[08:20:28.883869]<rblank>Almost :)
[08:20:38.480159]<mitsuhiko>rblank: well, generating html is what we do now but in two years or so the dom and javascript will be more important
[08:20:48.299348]<mitsuhiko>so i doubt anyone will innovate on the template engine thing
[08:21:06.387125]<rblank>mitsuhiko: Makes sense.
[08:21:29.685351]<mitsuhiko>anyways, reasons why jinja2 would be great for trac: for large pages (changelist and diff rendering for instance) you can hook up jinja2 directly to wsgi
[08:21:43.406660]<mitsuhiko>which reduces the memory usage because it will never allocate a string for the whole response
[08:21:46.981050]<mitsuhiko>just for what is sent to the server
[08:22:15.356943]<mitsuhiko>as far as i know, jinja2 is currently the online engine (besides genshi which can do that unless something is buffering) that does that
[08:22:37.043297]<cboos>mitsuhiko: you mean sending the raw content a la sendfile?
[08:23:01.325418]<mitsuhiko>not exactly sendfile, but pass chunks to the wsgi server as application iterator
[08:23:22.068369]<cboos>ah, I see
[08:23:31.529315]<cboos>chunked encoding is then possible
[08:24:05.743596]<cboos>would be extra fast, yes, and have lean memory requirements
[08:24:21.331159]*cboos is willing to buy the sales pitch ;-)
[08:24:50.635621]<mitsuhiko>cboos: may i ask how many extensions work currently?
[08:25:11.923127]<cboos>Trac plugins you mean?
[08:25:16.283433]<mitsuhiko>yes
[08:25:29.350411]<cboos>must be in the hundreds
[08:25:52.802786]<cboos>probably half for 0.10, half for 0.11
[08:25:56.315117]<mitsuhiko>there are quite a few people who want to use trac but can't for a few reasons
[08:26:02.083882]<mitsuhiko>a) git support sucks (fixed?)
[08:26:11.377189]<mitsuhiko>b) memory and cpu use is insane
[08:26:20.773426]<cboos>a) git support is high on my list for after 0.12
[08:26:23.512388]<mitsuhiko>c) authentication with ldap does not work good enough
[08:26:34.971819]<mitsuhiko>that's what i hear most of the time
[08:26:50.733754]<mitsuhiko>b) is probably mainly genshi and the component architecture
[08:27:13.932139]<cboos>b) was a big concern, and cpu spikes still is to some extent, although this mostly happens now in pathological cases which don't seem related to Genshi (#8443)
[08:27:34.891922]<cboos>c) I have no idea, sorry
[08:27:35.664678]<mitsuhiko>i did some profiling in 0.10 and there was some room for improvement, but since genshi is in there i don't see anything useful in the profiler outputs
[08:28:06.641601]<cboos>we have some very bad behavior w.r.t. to permissions in some cases
[08:28:07.665550]<mitsuhiko>cboos: neither do i, but a company i work for complains and so do two friends of mine working in corporate environments
[08:28:25.796179]<cboos>(http://trac.edgewall.org/ticket/4245 for example)
[08:28:47.449110]<mitsuhiko>cboos: oh, now that i see you. is it possible already to let the hg browser show the head of a branch instead of the tip?
[08:28:51.040030]<cboos>and more generally we have a page with some identified bottlenecks (TracPerformance)
[08:28:52.239642]<mitsuhiko>(wrt new named branches)
[08:29:26.913015]<mitsuhiko>siddhantchd: why are you asking that me?
[08:29:46.791806]<cboos>mitsuhiko: no, sorry, I started the change but didn't finish it (must have a patch somewhere)
[08:30:08.396974]<mitsuhiko>cboos: ah, okay. because i consider switching to named branches :)
[08:30:21.664341]<mitsuhiko>siddhantchd: i am not an rtorrent developer
[08:30:31.207572]<cboos>I consider switching to git ;-)
[08:30:53.494838]<mitsuhiko>me as well lately
[08:31:08.294085]<mitsuhiko>shortcut fail :(
[08:32:23.431820]<cboos>so back to the topic of Jinja2, if I sum up: a) it's as fast as we can reasonably wish for b) it's well supported
[08:32:46.862879]<cboos>and ... c) are you willing to give a hand if we'd switch?
[08:33:35.632834]<mitsuhiko>cboos: should be possible, yes
[08:33:50.464883]<cboos>ah great news then ;-)
[08:34:40.290768]<cboos>let's be done with this 0.12 thing :-)
[08:34:52.223787]<cboos>Remy, we should start a page where to sketch ideas for 0.13
[08:35:11.965530]<rblank>And let the flame wars begin ;)
[08:35:20.688476]<mitsuhiko>cboos: oh, and what about a trac blog? something to keep people reminded that trac still exists and that activity is there :)
[08:35:29.412113]<rblank>I can hear them already: What? Switch the templating engine *again*?
[08:35:35.455495]<mitsuhiko>it's sad to see everybody just caring about github lately
[08:35:45.461738]<rblank>mitsuhiko: It's called the "Timeline" ;)
[08:35:56.736882]<mitsuhiko>rblank: not trendy enough :)
[08:36:05.224602]<rblank>cboos: What's wrong with Mercurial (wrt git)?
[08:36:31.623614]<cboos>rblank: well, no, not really flamewars. I think at this point it's mainly both of us who have the say, and if we both agree, there's no place for a flamewar ;-)
[08:37:37.846551]<rblank>cboos: That doesn't prevent users from voicing their (dis)agreement. Like "I'm using this plugin that's using ClearSilver, will it still work after switching to Jinja2?"
[08:38:24.698972]<mitsuhiko>the genshi plugins will be the pain
[08:38:34.289180]<mitsuhiko>clearsilver plugins had the same problem for a longer timer
[08:38:35.252406]<mitsuhiko>*time
[08:39:17.614217]<cboos>rblank: if we both think that yet another switch of the template engine would be a good thing, then we're going to make it happen, regardless. And this means we're prepared to justify the move, of course. In this case, I think everybody can understand (and feel) the problems related to performance, and the lack of maintenance is also something I'm concerned with.
[08:40:03.915498]<cboos>and Clearsilver has been deprecated for long enough that we can remove support for it in 0.13dev.
[08:40:09.921527]<rblank>cboos: Sure. You know I'm not the one arguing *for* backward compatibility (usually) :)
[08:41:06.728687]<pacopablo>what? templating switch? ;)
[08:41:17.927788]*pacopablo needs to read the history
[08:41:42.324661]<rblank>pacopablo: Hey!
[08:43:01.706355]<cboos>actually, instead of removing Clearsilver support completely, we could even keep the dual template support and /replace/ Clearsilver with Jinja2
[08:43:38.969954]<cboos>mitsuhiko: what about i18n support in Jinja2 templates? also supporting Babel?
[08:43:54.578208]<mitsuhiko>yep, babel
[08:44:05.261786]<mitsuhiko>that's at least the recommended way and the one that works out of the box
[08:44:16.891989]<cboos>anything like i18n:msg ?
[08:44:38.989599]<cboos>for bringing together fragments in a single message?
[08:44:42.942519]<mitsuhiko>cboos: http://jinja.pocoo.org/2/documentation/templates#i18n
[08:44:49.197187]<mitsuhiko>well, it's not xml based
[08:45:36.097918]<mitsuhiko>cboos: it's implemented as extension, if you want a particular behavior changed that should be easy to accomplish
[08:55:27.018944]<rblank>cboos: Mail sent to Genshi and Babel mailing lists. I hasn't appeared yet.
[08:56:43.150303]*pacopablo jsut finished readying the history
[08:56:53.288554]<cboos>rblank: thanks!
[08:56:54.701433]<pacopablo>crazy as it sounds, I'm all for a jinja2 switch
[08:56:59.489653]*pacopablo has always hated genshi
[08:57:11.623601]<rblank>pacopablo: You all right? Fever or something? :)
[08:57:22.994534]<cboos>mitsuhiko: OK, it's not xml based, but we could have a check (in the tests) that templates /are/ actually well-formed. It would be nice if there was a way to verify that the jinja control structure are placed in such a way that they will not break the wfness of the document (e.g. nothing like: <li> {% for e in list %} </li> {{ e }} {% endfor %})
[08:57:42.030520]<pacopablo>rblank: what? you weren't around when we decided on genshi, I was for stan/breve then ;)
[08:57:57.176480]<mitsuhiko>cboos: you can hook into the preprocessing step and inspect the tokens transparently
[08:58:01.031727]<pacopablo>which I am still for a bit, but I understand if others don't like them
[08:58:07.237255]<mitsuhiko>you can also walk the ast
[08:58:33.407880]<mitsuhiko>cboos: in my projects i just have a test that visits all urls and validates with validator.w3.org :)
[08:58:47.167018]<pacopablo>why do we care about XML well-formedness?
[08:58:54.070316]<pacopablo>I mean, i understand the technical reason
[08:58:55.773094]<rblank>mitsuhiko: I was going to say that, too. We validate the generated XHTML in the functional tests.
[08:59:06.387761]<pacopablo>but why do we need something that enforces it?
[08:59:15.575742]<pacopablo>can't we just leave that to the programmer?
[08:59:31.990936]<pacopablo>sure, we may have some stupid plugins that bork it, but then that's a bug for the developer to deal with
[08:59:37.261053]<cboos>ensuring that the templates are well-formed in the first place is a good guarantee that the output will also be well formed (not a 100% guarantee of course, but it helps)
[09:00:06.663065]<pacopablo>cboos: yeah, but why have the templating engine enforce it?
[09:00:07.145595]<cboos>(saying that from the experience of the Clearsilver days)
[09:00:25.216721]<pacopablo>I like the testing aproach mentioned by mitsuhiko.
[09:00:28.840150]<cboos>pacopablo: exactly, this is not needed, we could check this by other means
[09:00:36.731559]<cboos>brb
[09:01:19.427000]<mitsuhiko>-comma after exactly?
[09:01:24.411018]<pacopablo>cboos: anyway, i think that if we're going to go for jinja2, we don't do a backwards compatible release
[09:02:11.908413]<pacopablo>0.11 was very annoying wrt plugins that used clearsilver
[09:02:29.464039]<pacopablo>especially since most of them broke anyway, even though there was the compatibility layer
[09:02:50.600913]<pacopablo>let's just break stuff. easier to know that we've cleaned up that way.
[09:03:11.863877]<pacopablo>"Hey, if you're using a plugin that only list <=0.12, it *wont* work for 0.13"
[09:03:20.882470]<pacopablo>seems pretty clear to me
[09:03:38.467745]<pacopablo>mitsuhiko: regarding c) earlier, what part of ldap authentication doesn't work well?
[09:03:49.500315]<mitsuhiko>pacopablo: would have to ask
[09:03:57.077804]<mitsuhiko>i have no idea about ldap myself
[09:04:17.747964]<pacopablo>heheh, I know that it's a little unclear, as there are multiple plugins for ldap
[09:04:36.442872]<pacopablo>but I auth against Active Directory and it works well
[09:05:03.383920]<pacopablo>full integration with LDAP, ie, permissions, etc, that's different story
[09:05:14.387752]<pacopablo>there is a plugin for it, but I haven't really tried it.
[09:05:35.514195]<pacopablo>oh, and for a) git support isn't horrible
[09:06:06.659833]<pacopablo>sometimes it's not the fastest, as it uses subprocess to run the git command directly
[09:06:30.033501]<pacopablo>should probably do a port that ues dulwich
[09:06:47.410883]<pacopablo>but git works with multi-repos :)
[09:08:59.317896]<cboos>rblank: this reminds me your question I left unanswered: the way I use Hg is juggling with multiple mercurial queues, and I start to feel that this I could get this with git + branches. Also the index (staging area) seems to be very close to preparing a patch with mq ... So I feel like that instead of trying to use Mercurial the git way, I could as well try to directly use git ;-)
[09:10:22.862445]<cboos>Not to mention that I feel I could better sell git at work as a replacement for svn, because it apparently has a better support for cherry picking (which is a requirement which invariably will come on the table), I just read about "git cherry" lately.
[09:13:50.374612]<rblank>cboos: Want to try my SvnBranch extension? :)
[09:57:03.495452]<cboos>rblank: seen the mail on Genshi - you're a bit generous with "a few weeks" but apart from that, it's good ;-)
[10:14:09.515986]<rblank>cboos: You know what the answer would have been if I had written "a few days".
[10:14:46.861463]<cboos>well, I bet you won't get a reply either way ...
[10:16:02.483307]<cboos>so now I have my Trac running with TracGenshi 0.6, in the tracdep.genshi package
[10:16:22.693734]<rblank>That's ok. It can't get worse, and any reply would be better.
[10:16:37.538873]<rblank>How did you "patch" genshi? import tricks?
[10:16:59.170982]<cboos>no tricks, a few renames
[10:17:17.447364]<rblank>You mean, in genshi?
[10:17:25.249767]<cboos>yes
[10:17:52.372264]<cboos>s/from genshi/from tracdep.genshi/ and the like
[10:18:01.479405]<cboos>not that bad
[10:18:02.461680]<rblank>So technically, it's a fork, right? No way of using a svn:externals?
[10:18:46.280674]<cboos>I don't think we can use externals and also that would get clunky if we need a fix (like the need to have some patches)
[10:19:17.054910]<cboos>so a fork with very minimal changes is perhaps the best way
[10:19:33.323526]<cboos>I need to find a way to trigger the install of that package from the main setup.py
[10:19:54.155770]<mitsuhiko>cboos: do you ship dependencies?
[10:19:59.455302]<rblank>You want to distribute it as a separate package?
[10:20:20.873498]<cboos>no, no, part of the main Trac install
[10:20:46.265447]<rblank>Can you do "svn merge" across repositories?
[10:21:29.123046]<cboos>I thin 1.6 supports something like that, but that won't really work in that case
[10:21:41.356954]<cboos>as we need the rename
[10:22:24.471332]<cboos>the move genshi -> tracdep/genshi I mean (not sure svn is happy when asked to merge after that)
[10:23:23.134768]<cboos>anyway, I'm just experimenting for now, to see if that would work at all. I would vastly prefer a simple "go" from Christopher ;-)
[10:25:16.698807]<rblank>cboos: How about plugins? They will still import from the genshi package.
[10:25:37.977502]<rblank>May have to do sys.modules['genshi'] = tracdep.genshi
[10:25:42.389585]<rblank>And all sub-packages.
[10:25:42.639781]<cboos>ah, damn yes, that's a problem
[10:26:08.505372]<cboos>maybe that would work,but then we have the dependency in setuptools to fake as well
[10:26:12.745479]<rblank>Or override __import__
[10:26:20.966444]<rblank>Right.
[10:26:28.320655]<pacopablo>what if we just distribute a trunk version of genshi?
[10:26:38.156894]<pacopablo>hackish, I know, but would be failry simple, no?
[10:26:48.259982]<rblank>pacopablo: Packagers won't like that.
[10:26:52.273088]<pacopablo>I guess debian and the like woul hate us
[10:26:55.267185]<pacopablo>yeah ;0
[11:51:27.134417]<elisa87>http://kb.almworks.com/wiki/JIRA_vs._Bugzilla
[11:52:26.949521]<kirean>In a macro, when used in a ticket description, how can I get the ticket id?
[12:08:20.441423]<cboos>kirean: from expand_macro(formatter, ...); the formatter has a .context, which is used to inform you "in which context" belongs the wiki text you're rendering; to that end, the context has a .resource, and in this situation the .realm will be 'ticket' and the .id will be the ticket num.
[12:09:08.364316]<cboos>... so this means formatter.context.resource.id is what you're looking for ;-)
[12:09:57.070451]<pacopablo>which couldn't be ANY bit more obvious ;)
[12:11:55.739336]<kirean>cboos: thanks
[12:31:44.676897]<svm_invictvs>Yep
[12:40:44.982192]<macmaN>whazzzzup cboos rblank
[12:41:28.356611]<cboos>who's the first guy?
[12:41:33.407063]<cboos>;-)
[12:42:05.569793]<macmaN>it's the guy from the budweiser commercial
[12:42:10.989936]<macmaN>downstairs on the speakerphone
[13:18:59.229323]<svm_invictvs>How do I know what my username is?
[13:25:45.852255]<svm_invictvs>:(
[13:37:16.584587]<cboos>exit
[13:37:21.579752]<cboos>\quit
[13:37:28.740944]<cboos>(it's late...)
[13:45:30.636480]<hasienda>rblank: hello, remember the custom time field modification thing?
[13:47:03.291449]<svm_invictvs>Actually is there a way to turn on verbose logging somehow?
[13:47:25.957527]<hasienda>rblank: you pointed me at r9210, that would be needed to include into my changes in order to get any attention from developers here.
[13:48:58.165429]<hasienda>rblank: Thanks for your hint. I'm merging now, already past r9217.
[13:49:51.168291]<hasienda>rblank: Would you agree that now custom timestamps should/must be in mircoseconds too?
[14:04:38.987323]<hasienda>@logging
[14:04:39.002896]<evil_twin>logging is http://trac.edgewall.org/wiki/TracLogging <-- Enable debug logging to file, ensure your environments log/ directory is writeable by your web server user, check for errors.
[14:05:35.244195]<hasienda>svm_invictvs: you see? just go with DEBUG level for the most verbose output.
[14:05:46.667049]<svm_invictvs>Cool
[14:05:51.475679]<rblank>hasienda: Yes, better be consistent and use microseconds as well.
[14:06:30.948676]<rblank>hasienda: I haven't had time to follow your work until now, but hope to catch up soon.
[14:07:42.843867]<hasienda>rblank: Ok, already thought, it would be the right thing. Seems reasonably easy to be done too.
[14:08:17.367449]<rblank>hasienda: I expect you're storing the field value as a string in the ticket_custom table?
[14:08:49.722826]<hasienda>rblank: Yes.
[14:11:04.602224]<hasienda>rblank: found this to be easy to implement, not changing ticket_custom db table at all.
[14:11:18.549259]<rblank>hasienda: Are you merging "manually" by applying each changeset from Trac SVN to your repository?
[14:11:58.704982]<hasienda>rblank: em, yes, but why do you ask?
[14:12:26.071796]<rblank>hasienda: Because it takes far too much effort! Most of it can be automated.
[14:13:22.788840]<rblank>As you are using Mercurial, you could convert the Trac SVN repository to a Mercurial repository.
[14:13:51.292317]<rblank>Conversion can be done incrementally. Then, create a clone and add your work to the clone, possibly on a separate named branch.
[14:14:17.118250]<rblank>When you want to merge, do an incremental conversion from SVN, pull the changes, then merge with Mercurial.
[14:15:33.855164]<rblank>This gets you the nice 3-way merge from Mercurial. When you want to create a patch e.g. for attaching to a ticket, just diff between your branch and the "imported" branch.
[14:17:50.432676]<hasienda>rblank: I know, much of my work by now could be done quicker, but so I have better overview in the merge. It's still hard after starting to learn Mercurial only some days back. However, I'm willing adopt good/better developer skills, as you give me advice. Thanks.
[14:22:38.099194]<rblank>hasienda: You could also base your work on my mirror on Bitbucket, I keep it mostly current. The conversion is done differently (I use a custom extension to pull SVN changesets directly into a named branch), but you should be able to use it in the same way.
[14:22:55.583649]<rblank>Just branch off the "incoming" branch.
[14:23:18.036024]<rblank>hasienda: http://bitbucket.org/rblank/trac-trunk/
[14:23:47.776464]<rblank>Just ignore anything that isn't on the branch "incoming".
[14:25:18.389396]<hasienda>rblank: Will look at it, thanks. Seems going for Mercurial was not that bad after I got the initial impression, that Git already rules the world.
[14:25:57.240481]<rblank>hasienda: Mercurial is great indeed. Git certainly also has its strenghts, but I haven't had a chance to use it yet.
[14:27:37.382570]<hasienda>rblank: Would you recommend, that I try to make custom time fields feature a series of patches with MQ? Or do you prefer other ways of contribution?
[14:29:13.716881]<rblank>hasienda: I'm not familiar with mq, haven't managed to wrap my head around it :)
[14:29:58.738251]<rblank>I just create a branch, edit stuff, then merge from time to time with "incoming", and finally diff against "incoming" to post a patch.
[14:30:26.338010]<rblank>If you fork from my repo, I could pull your changes directly.
[14:30:54.791495]<rblank>But you'll probably still need to post patches for others to review.
[14:32:33.890443]<hasienda>rblank: But having a pile of patches wouldn't be a strikt requirement, would it?
[14:33:16.255662]<rblank>hasienda: You don't need a "pile" of patches. Just diff against current trunk when asked to. A single patch.
[14:34:46.414272]<hasienda>rblank: Ok, thanks for making it clear. Since I'd appreciate code review, I'll try to make it as hassle-free for you as I can. :-)
[14:35:22.789265]<rblank>hasienda: Wait until tomorrow before cloning, I need to clean that repo first.
[14:36:56.590011]<hasienda>rblank: Well, will have still enough to do 'til then with the merging to current SVN HEAD. And rl is waiting too.
[14:47:04.323154]<hasienda>Ah, already little too late now, so I'll go, bye.
[15:02:52.133838]<osimons>rblank: just caught up on the irc log. major questions raised...
[15:03:10.582030]<rblank>osimons: More of a brainstorming, actually...
[15:03:56.952787]<osimons>yeah, see that.
[16:30:08.607961]<colombian>Hey guys, I'm trying to override the "get_permission_groups" method of IPermissionGroupProvider
[16:30:27.819044]<colombian>I have a question, should return [ "admin" ] make it such that every user has admin privileges?
[16:30:37.582389]<colombian>Because that's what I have right now - and it's not working
[18:04:14.921230]<colombian>Gentlemen, how do I resync a trac db
[18:04:16.527560]<colombian>?
[23:59:07.887566]<kirean>In a Macro, if I got the ticket id, how can I get values of fields for that ticket id?