Team Chat Logs

August 18, 2009

2009 7
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
31            

[02:30:47.143381]<osimons>morning people
[02:35:11.822008]<osimons>davidfraser: you got the cc on #424? take a look when you have time? thanks.
[02:44:30.460281]<davidfraser>osimons: Will do - but basically I'm pretty sure you're right...
[02:45:06.677996]<osimons>:-)
[03:23:58.983361]<evil_twin>b.e.o: Ticket #269 ("Database is locked" error) updated - <http://bitten.edgewall.org/ticket/269#comment:12> - osimons
[04:54:22.636507]<evil_twin>b.e.o: Ticket #431 (Remove bitten notification configuration from Trac main notification ...) created - <http://bitten.edgewall.org/ticket/431> - Erik Andersson <kirean@…>
[06:16:42.562851]<evil_twin>b.e.o: t431_kirean_separate_bitten_notification_tracini_section-r711.patch attached to Ticket #431 - <http://bitten.edgewall.org/attachment/ticket/431/t431_kirean_separate_bitten_notification_tracini_section-r711.patch> - kirean@…
[07:08:54.722869]<evil_twin>b.e.o: Ticket #432 (Add option to specify cc-list to be used for bitten notifications) created - <http://bitten.edgewall.org/ticket/432> - Erik Andersson <kirean@…>
[07:10:55.112383]<evil_twin>b.e.o: t432_kirean_configurable_cc_list-r711.txt attached to Ticket #432 - <http://bitten.edgewall.org/attachment/ticket/432/t432_kirean_configurable_cc_list-r711.txt> - Erik Andersson <kirean@…>
[07:11:55.892755]<evil_twin>b.e.o: Ticket #432 (Add option to specify cc-list to be used for bitten notifications) updated - <http://bitten.edgewall.org/ticket/432#comment:1> - Erik Andersson <kirean@…>
[08:41:59.955950]<pacopablo>moring
[08:42:06.629261]<pacopablo>s/morin/morning
[08:42:06.643354]<evil_twin>pacopablo meant: morning
[08:51:24.252383]<evil_twin>b.e.o: t430-build_layout_take2-r711.diff attached to Ticket #430 - <http://bitten.edgewall.org/attachment/ticket/430/t430-build_layout_take2-r711.diff> - osimons
[08:54:22.078063]<pacopablo>osimons: why goign back to a fixed column size?
[08:55:20.204305]<osimons>hehe. the layout is now 'auto' - it expands and shrinks better, and the charts stay glued on the right with just the space they need leaving the rest for the table
[08:55:25.480691]<evil_twin>b.e.o: Ticket #430 (Build History Layout CSS Changes) reopened - <http://bitten.edgewall.org/ticket/430#comment:4> - osimons
[08:55:45.493694]<osimons>try it - it think it will be fine. and simpler.
[08:56:11.432818]*pacopablo doesn't see how the size is 'auto' now, but I'll try it
[08:57:13.608309]<osimons>well, it is 'inherit' actually - and no width for the charts
[09:01:31.234794]<pacopablo>not bad. there is a lot of whitespace inbetween the table and the charts on a widescreen monitor (1680x1050)
[09:01:34.070230]<pacopablo>bbias, meeting
[09:02:47.338772]<osimons>make that 'auto' and not 'inherit'... suddenly remember reading 'inherit' is not supported by IE... fixed locally, same result.
[09:14:50.514817]<osimons>also increased the default td width to 40em - seems a useful maximum from all my test configurations. personally i don't mind the whitespace if you have a single target. add more targets (or longer revision numbers) and it all adjusts.
[09:17:32.747065]*osimons takes the lawn mower for a walk... back later.
[09:27:02.806594]<pacopablo>osimons: I'm fine with the change. it does make it a bit cleaner
[09:28:07.724652]<pacopablo>osimons: wrt multirepos, I have a need to detect multirepos in the tests and then customize tests to multirepos or no
[09:29:14.732298]<pacopablo>osimons: also, do you have any info about running tests within a virtualenv?
[09:30:50.550255]<osimons>pacopablo: a bit slow out the door into the garden... hang on.
[09:32:16.308714]<osimons>http://groups.google.com/group/bitten/browse_thread/thread/50dd743e412891a7 - and specifically my last post, i'd use [python] path = /path/to/venv/bin/python in a slave config
[09:32:52.316128]<osimons>personally i just activate the virtualenv and then run bitten-slave, so i don't have a working setup in recipe for it
[09:34:13.195606]<pacopablo>ahh
[10:14:54.275405]<matt_good>osimons: with the file attachments patch I'm still unsure why you'd attach a file to the config instead of to the build itself
[10:15:08.888474]<matt_good>I could see aggregating by-products of recent builds on the config page
[10:40:42.804236]<matt_good>basically, if the files are attached to the build, you still know their config, so anything you'd want to do with config-attached builds should still be possible, but without some of the gotchas
[10:42:20.643486]<matt_good>anyways, gtg to the office
[11:20:08.087456]<osimons>yo matt_good - lawn mowing... back :-)
[11:21:45.277273]<osimons>well, the use-case for configs imho is not just builds - it could also be artifacts for configuring slaves and so on. downloads of dependencies and what not
[11:23:04.764253]<matt_good>ok, I guess I can buy that
[11:23:10.685783]<osimons>still, for the pure build-push i (like you) expect that attaching it to the build will be the common scenario (and also the default)
[11:24:00.934992]<osimons>with the trac resource system so inately tied to the path, it was easier to support config + builds seeing all builds are at /config/buildid...
[11:25:19.696203]<osimons>after all these years around trac, i have stopped wondering what users may actually want to do - they surprise me all the time... options are in theory good - use as you please :-)
[11:25:48.759472]<osimons>matt_good: have you tried the <attach/>? does it work as expected?
[11:26:12.706287]<matt_good>I just foresee a number of people thinking that setting it to attach the build artifacts to the config will be an easy way to just keep the latest one, and then get all confused when it gets overwritten by an old version
[11:26:36.705086]<matt_good>no, I haven't actually tested it yet
[11:26:38.272165]<osimons>i've documented my way around that one
[11:27:08.449487]<osimons>and now with also some other patches recently, it will actually only build latest of so configured
[11:27:12.950091]<matt_good>well, people's ability to ignore documentation also surprises me :)
[11:27:47.722393]<osimons>(likely with some very rare corner cases of fast + slow slaves, but i'll deal with that if it appears)
[11:29:18.693314]<osimons>heh. yeah, i suppose... it isn't like we overwhelm them with docs though - it is one line out of ~5 for the command...
[11:29:46.338852]<matt_good>meh, whatever
[11:33:07.654226]<osimons>matt_good: if you're really opposed to config attachments, then by all means raise your voice on the mailing list. i'm not married to it or anything - it was more an option that came as a free bonus, and something i thought it would be nice then to do. i'll bend to opinion.
[11:33:21.917294]<osimons>- either remove all, or just remove the option from the <attach/> command
[11:36:27.032169]<matt_good>well, attaching files to the config via the web seems fine
[11:37:11.170352]<matt_good>but I guess for build-produced files I'd rather not throw that extra bit of data away
[11:37:46.169341]<matt_good>and if people have interesting uses for showing build attachments with the config you can still present them that way
[11:40:07.317011]<osimons>oki, matt. if you don't want it then remove it from the command + command docs + testcase. i won't revert it. we'll leave the underlying config support for attachments as-is, just not available as build command
[11:46:02.343468]<matt_good>well, I guess we can leave it and see what happens
[11:53:41.756493]<osimons>btw matt_good, just a handful of tickets left for 0.6 milestone - may get that beta out this month. not bad.
[11:53:52.836152]<matt_good>cool
[11:55:00.351011]<matt_good>btw, with the subprocess stuff I started making some changes to make it use the select() loop when possible
[11:56:11.613552]<osimons>that is generally a better approach? does it require 2.4 of 2.5? i haven't used it myself
[11:57:30.874132]<osimons>also, if there are open tickets related to commands you are familiar with, i'd appreciate a review - many commands relate to infrastructure and languages i don't use/know/have...
[11:58:29.681851]<osimons>http://bitten.edgewall.org/query?status=!closed&group=milestone&order=id
[11:58:45.950903]<osimons>^^ actually a manageable size for an open tickets list... :-)
[12:02:34.156758]<matt_good>no, select() works on pretty much every Python version
[12:02:46.246315]<osimons>but not all platforms, was that it?
[12:02:49.140583]<matt_good>it's how cmlenz implemented the original popen version
[12:02:49.980311]<matt_good>yeah
[12:02:59.397664]<osimons>yeah - i've seen it there
[12:03:24.943859]<osimons>did a lot of reading, and just concluded i couldn't use it as a general solution for my one execute() to rule them all...
[12:03:43.807555]<matt_good>no, it's kind of limited on Windows
[12:04:03.120440]<matt_good>it only works with sockets, and not file descriptors
[12:04:07.508270]<osimons>do you foresee problems with my treaded version?
[12:04:15.394873]<osimons>s/treaded/threaded
[12:04:15.418344]<evil_twin>osimons meant: do you foresee problems with my threaded version?
[12:08:07.049789]<matt_good>it's probably ok, but event-based IO is usually lower overhead
[12:09:40.026111]<matt_good>subprocess.communicate is implemented via threads on Windows and select() everywhere else, so I figured it'd suit this case well as well
[12:13:33.601208]<osimons>yeah, but using the queue was very fast for my comparisons - i don't depend on reading io and writing back output happening on the same time, so the pipes will populate the queue at full speed, and we pop the queue when we have time and then at the end
[12:14:15.898848]<osimons>- leaving some of the output to appear in "chunks" and not an even flow as output to log/screen is lower priority
[12:58:12.240919]<evil_twin>b.e.o: trac-bitten-multiplepaths6-r711.patch attached to Ticket #244 - <http://bitten.edgewall.org/attachment/ticket/244/trac-bitten-multiplepaths6-r711.patch> - sahendrickson@…
[13:02:56.117526]<CIA-60>r712 by osimons in bitten/ (3 files in 3 dirs): 0.6dev: Improving builds overview page layout, take 2. Re-closing #430.
[13:04:13.291408]<evil_twin>b.e.o: Ticket #430 (Build History Layout CSS Changes) closed - <http://bitten.edgewall.org/ticket/430#comment:5> - osimons