[12:30] <Scorpio> hallo
[12:31] <Scorpio> I am from Russia
[12:31] <Scorpio> Tell me about Ubuntu Linux
[12:31] <Scorpio> please
[12:32] <Scorpio> m?
[12:41] <SteveA> Scorpio: try #ubuntu
[12:42] <SteveA> http://ubuntu.ru/Wiki has stuff on.  i can't read any of it, though
[12:45] <Scorpio> Thanks
[12:47] <ddaa> Hi SteveA, doing overtime are you?
[09:02] <fabbione> ops
[09:02] <fabbione> echan
[09:19] <Scorpio> hi
[10:30] <_off> hi
[10:47] <Edgardoweb> quiero live cd 
[11:03] <Edgardoweb> dand, ??
[11:23] <Blejdfizt> No habla Espaol
[03:59] <munzir> hi gurus, is rosetta open-source? where can I download it?
[04:01] <munzir> is this question soo difficult? ;)
[04:02] <Kinnison> We're mostly asleep I think
[04:02] <Kinnison> Rosetta is not open-source
[04:02] <Kinnison> It's part of the Launchpad application
[04:03] <munzir> Kinnison: aha! where can I find how does it compare to other free software like pootle or kartouche?
[04:04] <munzir> Kinnison: I mean what would convince me to go and buy if I would find similar software that is free?
[04:06] <munzir> mostly I am missing some history
[04:09] <sivang> munzir: hi there, did you read the links I sent you last time?
[04:09] <sivang> munzir: it's all explained there
[04:12] <munzir> sivang: really? please give it to me again
[04:17] <munzir> sivang: all I remember I asked you how you compare solutions like pootle to rosetta and you told me you are more comfortable with the later and I decided to try it. but when I go to download i didn't find it. so I am sorry I didn't notice those links you gave me
[04:18] <munzir> sivang: don't think that i didn't care about your tips ;)
[04:24] <munzir> sivang: can you just give a hint? maybe I have read it but forgot!
[04:27] <sivang> munzir: ofcourse :)
[04:27] <sivang> munzir: all the answers are there
[04:27] <sivang> a sec
[04:28] <sivang> munzir: 1) https://wiki.ubuntu.com/RosettaFAQ
[04:28] <sivang> munzir: 2) https://launchpad.net/products/drupal/+translations (for drupal translations)
[04:29] <sivang> munzir: you might want to pay attention to Question #1 :)
[04:30] <munzir> sivang: ok thanks I am reading it all carefully now ...
[04:30] <sivang> munzir: pootle also feels very disoranized to me, but again this is maybe because of a certain way I got used to think 
[04:30] <sivang> munzir: np :) if you have any questions let me knw, I'd be happy to answer if I CAN
[04:30] <sivang> s/CAN/can/
[04:38] <munzir> sivang: still reading but lots of things are clear now. If you have time, I would like if you can take a look at http://www.dotmon.com/kartouche/ and give me how you see it
[04:40] <munzir> sivang: it's strange that both kartouche and rosetta has a name related to Egyptian hieroglyphic but I love it really
[05:05] <mahangu> has anybody written a gtk frontend for launchpad?
[05:09] <sivang> munzir: :)
[05:11] <sivang> mahangu: I've thought about it, https://launchpad.net/distros/ubuntu/+spec/launchpad-login-app
[05:12] <mahangu> sivang, ive written the skeleton of a live support application in perl
[05:12] <mahangu> irc backend
[05:12] <mahangu> i thought that launchpad might be a better backend though
[05:12] <mahangu> i would love to help you on it, if you're open to that
[05:13] <sivang> mahangu: well, as you can see it's not even a goal for the time being (deferred) maybe for dapper+1 :)
[05:13] <sivang> mahangu: what's live support application?
[05:13] <sivang> mahangu: and how does it relate to irc?
[05:13] <mahangu> sivang, we could release it as a launchpad extension
[05:13] <mahangu> so other distros that use launchpad can use it
[05:14] <mahangu> sivang, are you on ubuntu-devel?
[05:14] <mahangu> mailing list I mean
[05:14] <sivang> mahangu: yes, I am
[05:14] <mahangu> sivang, im just sending out an email now
[05:14] <sivang> mahangu: ok, cool . please include links so I can see that thingy you've done in perl, if it's related :)
[05:15] <mahangu> sivang, my perl is crappy
[05:16] <mahangu> im rather embarrased to link that to a list of hardcore devs
[05:16] <mahangu> :S
[05:17] <sivang> mahangu: no prob, I Just wanted to try and better understand what you wrote :)
[05:17] <sivang> mahangu: I don't think my perl is better either :) I am now concetrated on python
[05:17] <mahangu> sivang, http://cvs.taprobane.org/viewcvs.py/taprobane/hermes/hermes.pl?rev=1.7&view=log
[05:22] <mahangu> sivang, brb
[05:31] <mahangu> back
[05:38] <mahangu_> in rosetta, how can I choose font to translate with?
[05:39] <sivang> font?
[05:39] <sivang> you mean, the font which is used to display input text boxes?
[05:41] <mahangu_> sorry
[05:41] <mahangu_> i think i missed anything i was told
[05:41] <mahangu_> stupid wifi timed out
[06:11] <Bulb> Can I have a little question? I'd like to know if I can somehow specify the priority when reporting a bug. What I want is to create a wishlist item so it does not generate the second email about severity being set to wishlist.
[06:20] <SteveA> Bulb: you can't do it.  Please file a bug on the 'malone' product, saying that you want to be able to do this.
[06:20] <Bulb> Ok. Will do.
[06:25] <Bulb> There seems to be a bug about it already, but it's a bit confusing about what is the desired resolution. So I will file a new one clearly saying "It should be possible to set severity on bug reporting page" and refer to the other one.
[06:28] <SteveA> ok
[06:28] <SteveA> although...
[06:28] <SteveA> is what you want that you can set the priority on the same page, or is the more important thing receiving only a single email notification?
[06:29] <Bulb> Making it obvious that the severity can be set and indeed should be set. So really setting it on the same page.
[06:29] <SteveA> ok
[07:15] <Nafallo> anyone Rosetta here? :-)
[07:27] <Nafallo> or rather anyone with enough privilegies to nuke a language for me? ;-)
[09:43] <lifeless> morning
[09:49] <sivang> morning lifeless , how are you ?
[09:50] <lifeless> not bad, not bad at all
[09:54] <sivang> lifeless: did you have any written report of the mini meeting you and SteveA had about testing and stuff? (I recall it was scheduled for Fri 08:00UTC)
[09:57] <lifeless> no
[09:57] <lifeless> due to various reasons we ended up just having a phone call
[09:57] <lifeless> hmm, I might blog some of the salient points today
[09:58] <lifeless> a thumbnail sketch though..
[09:58] <sivang> ok
[10:01] <lifeless> so steve has a number of things bugging him about testing in launchpad
[10:01] <lifeless> some of which are easier to articulate than others
[10:03] <lifeless> those are, roughly in order...
[10:03] <lifeless> its hard to encourage TDD when running the tests is complex, and takes upwards of twenty minutes
[10:03] <lifeless> it would be nice to have *some* metrics for how well tested we are
[10:04] <sivang> (sorry, TDD=?)
[10:04] <lifeless> and would be nice to have a really simple way of writing granular tests that test just one layer of behaviour, which will result in faster execution too.
[10:04] <lifeless> test driven development
[10:13] <lifeless> also it seems very hard to get the knack of TDD for programmers.
[10:14] <lifeless> we need better ways of educating people to do it, and that (again) needs a test suite that is a joy to operate, not an enema.
[10:18] <sivang> lifeless: Are you in any way  following the paradigm of desining tests first, writing test input, writing code, then write tests - currently?
[10:18] <lifeless> got a name for that workflow ?
[10:19] <sivang> lifeless: erm, some would say that it's borrowed off XP ;-) But I'm not sure. That is how we used to do it in one of my previous workplaces :)
[10:19] <lifeless> (and no, I'm not, nor are we talking about doing that, as it appears to be a slightly broken form of TDD.)
[10:20] <sivang> well I guess it's more suited at testing XML db datasources which is what I used it against..
[10:20] <lifeless> the current workflow we *like* people to follow is 'write a test that fails, alter the code so it passes, remove duplication).
[10:21] <lifeless> which in comparison to your design test, write test input write code, write tests - switches the last two steps.
[10:21] <lifeless> which is the important thing.
[10:23] <lifeless> this is important because gives you some nice properties:
[10:24] <lifeless> your tests define the codes requirements:- actual code can vary wildly and not break.
[10:25] <lifeless> your tests mean that if code somewhere else in the system changes, any impact on your code is noticed. (as long as you have contract tests too).
[10:25] <lifeless> and when you have many 10K LOC systems, they are too big to hold in your head. So being able to rely on the system flagging issues is really nice.
[10:29] <sivang> Granted. As I now see from you that's a deformed way of TDD, it did help us find the most "major" issues (mostly segfaults) right away after a developer gave us his code. We had input ready to stress it, which we carefully crafted months before the actual code was done. This allowed to acutally test each and every code path that the developer had to supply. And that was done by first, feeding the test xml input by hand to the parser, before any automated
[10:30] <lifeless> that cut off at 'before any automated'
[10:30] <sivang> testing was done. But I can't say that project was as big as launchpad is :)
[10:30] <sivang> (I pasted in)
[10:30] <lifeless> right
[10:31] <lifeless> so to make that work (months between tests and code), you need a really long pipeline, and no design changes going on
[10:31] <lifeless> TDD is at the heart of many XP methodologies.
[10:32] <lifeless> its very agile, because you can literally change the spec on the fly, while writing the code, but you still get solid test coverage.
[10:38] <sivang> true. Indeed that project was a special case. The documentation was also produced long before the actual spec was implemented. So any changes had to be minor, or deferred for next version which dependend on a new version of the docs. I would routinely design my tests from the already made documentation, which was second stop basing off the spec.
[10:43] <lifeless> right
[10:43] <lifeless> I'm not criticing here, just pointing out corollaries.
[10:44] <lifeless> a common theme that XP methodologies have is that the 'spec' should be very small, lightweight and written by the customer within a couple of weeks of the code being written
[10:44] <lifeless> that sort of process does not give you the long pipeline that you were working with, which is why the testing methodologies have to be different too
[10:46] <lifeless> mdz: so hows dapper ?
[10:46] <mdz> lifeless: tame
[10:46] <lifeless> mdz: I'd like to run dapper all the way through, to give you good feedback ..
[10:46] <mdz> we haven't dropped any big bombs yet
[10:46] <lifeless> do we have any planned ?
[10:46] <mdz> yes
[10:50] <sivang> mdz: what like?
[10:50] <sivang> (I'm upgrading as we speak)
[10:51] <mdz> sivang: hardware-detection, hardware-activation, network-magic, etc.
[10:51] <mdz> you were there at UBZ
[10:54] <sivang> hardware-activation will be interesting :)
[10:57] <lifeless> yah, but did not get to those bofs ;)
[10:58] <lifeless> mdz: so am I crusing for a world of pain if I run dapper all the way through? how rough a ride will it be do you think?
[11:01] <mdz> lifeless: it'll be a cakewalk compared to breezy
[11:02] <mdz> but the usual development branch caveats apply
[11:03] <lifeless> well
[11:03] <sivang> well, those are usually manageable unless it's some X breaker issues, or kernel patches that had gone bad I guess
[11:03] <lifeless> I'm used to run sid ;)
[11:03] <lifeless> but breezy was scarey
[11:04] <sivang> lifeless: I also used sid for some time before I switched to Ubuntu, and yes, even by my experience, ubuntu seemed (mostly in hoary) comapred to what I Had known with sid.