[12:43] <RADD> Hello?
[12:44] <nealmcb> shawarma: Yeah - I had the same question about "Resource primer".  Resource as in... documentation?  tools?  human resources? http resources (uRls)?    Such a vague term....  http://en.wikipedia.org/wiki/Resources
[12:45] <nealmcb> RADD: the presenter didn't show up for this session....
[12:46] <RADD> NEALMCB: thank you for letting me know.
[12:48] <RADD> Have a good day you all!
[01:54] <^^malajenho^^> hi
[01:55] <jrib> hi
[01:56] <^^malajenho^^> one moment
[01:56] <^^malajenho^^> I'm coming
[02:07] <^^malajenho^^> hi again
[02:07] <^^malajenho^^> i'm trying to compile a source withot configure, only with makefile
[02:07] <^^malajenho^^> and when I do a "make"
[02:10] <^^malajenho^^> this is the answer:        gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o wepattack.o wepattack.c
[02:10] <^^malajenho^^> cc1: aviso: la opcin de lnea de comando "-fno-for-scope" es vlida para C++/ObjC++ pero no para C
[02:10] <^^malajenho^^> wepattack.c: En la funcin loop_packets:
[02:10] <^^malajenho^^> wepattack.c:141: aviso: declaracin implcita incompatible de la funcin interna strlen
[02:10] <^^malajenho^^> wepattack.c:146: aviso: declaracin implcita incompatible de la funcin interna strlen
[02:10] <^^malajenho^^> wepattack.c:151: aviso: declaracin implcita incompatible de la funcin interna strlen
[02:11] <^^malajenho^^> gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o rc4.o rc4.c
[02:11] <^^malajenho^^> cc1: aviso: la opcin de lnea de comando "-fno-for-scope" es vlida para C++/ObjC++ pero no para C
[02:11] <^^malajenho^^> gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o wepfilter.o wepfilter.c
[02:11] <^^malajenho^^> cc1: aviso: la opcin de lnea de comando "-fno-for-scope" es vlida para C++/ObjC++ pero no para C
[02:11] <jrib> !paste | ^^malajenho^^
[02:11] <^^malajenho^^> gcc -fno-for-scope -c -D__LINUX_WLAN__ -D__I386__ -o log.o log.c
[02:11] <ubotu> ^^malajenho^^: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
[02:11] <^^malajenho^^> mmm
[02:11] <^^malajenho^^> sorry
[02:11] <^^malajenho^^> :S
[02:12] <^^malajenho^^> here you are
[02:12] <^^malajenho^^> http://paste.ubuntu-nl.org/17704/
[02:12] <^^malajenho^^> it is in spanish, I hope you don't have problem
[02:13] <jrib> it seems you are getting permission errors
[02:14] <^^malajenho^^> ohh
[02:14] <^^malajenho^^> with "sudo" I have the same problem
[02:14] <jrib> don't run make with sudo
[02:15] <^^malajenho^^> and how do u think I could to resolve the problem
[02:15] <^^malajenho^^> ?
[02:15] <jrib> can you start over and paste the errors you get with "LANGUAGE=en_US make"
[02:16] <jrib> by start over, i mean delete the directory and untar it again
[02:16] <^^malajenho^^> ok
[02:19] <jrib> this thing is broken
[02:19] <jrib> their Makefile has a typo
[02:24] <^^malajenho^^> hi again
[02:24] <^^malajenho^^> here is the paste
[02:25] <^^malajenho^^> http://paste.ubuntu-nl.org/17708/
[02:28] <jrib> ^^malajenho^^: yes
[02:29] <jrib> if you hilight me I'll notice you said something :)
[02:29] <^^malajenho^^> what do u think?
[02:29] <jrib> ^^malajenho^^: issue this command: chmod +x wlan
[02:30] <^^malajenho^^> right
[02:30] <jrib> ^^malajenho^^: now try 'make' again (it will fail)
[02:30] <^^malajenho^^> ok
[02:30] <jrib> ut pastebin the errors
[02:31] <^^malajenho^^> http://paste.ubuntu-nl.org/17709/
[02:31] <jrib> ^^malajenho^^: ok, now you need to edit the Makefile
[02:31] <^^malajenho^^> aha
[02:31] <jrib> ^^malajenho^^: do you see the mistake?
[02:32] <^^malajenho^^> mmm
[02:32] <^^malajenho^^> wait
[02:32] <^^malajenho^^> I'll see
[02:32] <jrib> k
[02:33] <^^malajenho^^> I don't know exactly
[02:33] <^^malajenho^^> cflags ?
[02:34] <jrib> look at the error
[02:34] <jrib> gcc: log.omodes.o: No such file or directory
[02:34] <jrib> does that look funny?
[02:34] <^^malajenho^^> aha
[02:34] <^^malajenho^^> I have to install the library of log.omodes.o ?
[02:35] <jrib> nah
[02:35] <jrib> in your Makefile, you have a line like this:
[02:35] <jrib> gcc  -o wepattack wepattack.o rc4.o wepfilter.o log.o\
[02:35] <jrib> it should be:
[02:35] <jrib> gcc  -o wepattack wepattack.o rc4.o wepfilter.o log.o \
[02:35] <jrib> notice the space at the end
[02:35] <^^malajenho^^> ahhh
[02:37] <^^malajenho^^> ok
[02:37] <^^malajenho^^> now I have a new message
[02:37] <^^malajenho^^> I'll paste
[02:38] <^^malajenho^^> http://paste.ubuntu-nl.org/17711/
[02:38] <jrib> i see no errors, you should have a file called "wepattack" now
[02:39] <^^malajenho^^> sure
[02:39] <^^malajenho^^> hehe
[02:39] <^^malajenho^^> I'm a litle slept
[02:39] <^^malajenho^^> ;)
[02:40] <^^malajenho^^> jrib:  a lot of thanks
[02:40] <^^malajenho^^> :D
[02:40] <jrib> np
[02:42] <^^malajenho^^> sorry for my english
[02:42] <^^malajenho^^> i'm spanish
[02:42] <^^malajenho^^> heheh
[02:42] <jrib> cool, I'm portuguese.  We're basically neighbors
[02:43] <^^malajenho^^> ohh
[02:43] <^^malajenho^^> I'm galician
[02:49] <ubuntu> ihahahahha
[02:49] <ubuntu> someone here.
[02:53] <ubuntu> man
[02:53] <ubuntu> you are here
[02:53] <ubuntu> how are you going
[05:03] <bababian> NICKNAME
[05:37] <tonyyarusso> lurkan: please turn off your away script in Ubuntu channels.
[06:01] <leninz> can someone help me install wxJavaScript on ubuntu 6.06?
[06:02] <leninz> please?
[06:02] <someothernick> try #ubuntu
[06:03] <leninz> can't anyone help me here?
[11:42] <AndrewB> :)
[02:43] <balrok> (j #centerim
[03:21] <Tm_T> jaba: o/
[03:29] <pochu> hey all!
[03:58] <KennethP> @now
[03:58] <ubotu> Current time in Etc/UTC: April 26 2007, 13:58:39 - Next meeting: MOTU in 6 hours 1 minute
[04:02] <KennethP> @schedule
[04:02] <ubotu> Schedule for Etc/UTC: 26 Apr 20:00: MOTU | 26 Apr 21:00: Ubuntu Development Team | 01 May 15:00: Kernel Team | 01 May 18:00: Mozilla Team | 02 May 12:00: Edubuntu | 03 May 16:00: Ubuntu Development Team
[04:04] <sharms> @schedule EST
[04:04] <ubotu> Schedule for EST: 26 Apr 15:00: MOTU | 26 Apr 16:00: Ubuntu Development Team | 01 May 10:00: Kernel Team | 01 May 13:00: Mozilla Team | 02 May 07:00: Edubuntu | 03 May 11:00: Ubuntu Development Team
[04:26] <PriceChild> Hey LjL
[04:28] <sharms> is MOTU still scheduled for 16:00 UTC?
[04:30] <LjL> hi PriceChild
[04:30] <PriceChild> sharms, yes please :)
[04:47] <pwnguin> @schedule CDT
[04:47] <pwnguin> @schedule CST
[04:48] <pwnguin> @schedule Chicago
[04:48] <ubotu> Schedule for America/Chicago:
[04:48] <pwnguin> i guess it pulls from the wiki
[04:51] <PriceChild> @now chicago
[04:51] <ubotu> Current time in America/Chicago: April 26 2007, 09:51:16 - No meetings scheduled
[04:51] <KalleDK_Lap> @now denmark
[04:51] <KalleDK_Lap> :(
[04:51] <PriceChild> use a city
[04:51] <KalleDK_Lap> @now copenhagen
[04:51] <ubotu> Current time in Europe/Copenhagen: April 26 2007, 16:51:56 - No meetings scheduled
[04:51] <KalleDK_Lap> :D
[04:52] <KalleDK_Lap> @schedule copenhagen
[04:52] <ubotu> Schedule for Europe/Copenhagen:
[04:52] <KalleDK_Lap> !love
[04:52] <ubotu> Love is like racing across the frozen tundra on a snowmobile which flips over, trapping you underneath. At night, the ice-weasels come.
[04:52] <zorglu_> hehe i guess that 'no meeting' may the same whatever the location on earth :)
[04:54] <rfdparker2002> @now stourbridge
[04:54] <rfdparker2002> gah
[04:54] <rfdparker2002> @now birmingham
[04:54] <rfdparker2002> oh well
[04:57] <ranf> hi
[04:58] <KalleDK_Lap> !hi ranf
[04:58] <ubotu> Sorry, I don't know anything about hi ranf - try searching on http://bots.ubuntulinux.nl/factoids.cgi
[05:01] <PriceChild> whoops...
[05:03] <PriceChild> Now where is our host? :)
[05:03] <elkbuntu> she seems MIA
[05:03] <mc44> elkbuntu can do it instead :p
[05:04] <elkbuntu> if she's not here in the next 5, i might have to
[05:04] <jono> elkbuntu: :)
[05:05] <nalioth> mc44: looks like a good candidate
[05:07] <Tm_T> elkbuntu: whooo \o/
[05:10] <elkbuntu> Ok, we're currently missing our scheduled hostess, so I will fill in for her
[05:11] <elkbuntu> My name is Melissa Draper, I'm from Australia, and I've been involved with ubuntu for around 18 months
[05:12] <elkbuntu> Ubuntu Women was initially started by Vid Ayer and others.  I Understand that Sabdfl and Canonical helped register the domain and get resources in place.
[05:12] <elkbuntu> For a while we were a group of helpers with no leaders.  Several folks stepped up to get the group moving and now we have several projects that we are working on.
[05:13] <elkbuntu> our scheduled host was one of the ones who helped get the project moving again :)
[05:13] <elkbuntu> Anyway, the biggest question we get is "Why is there an Ubuntu-Women Project?"
[05:14] <elkbuntu> Some believe "Integration by Separation" is A Bad Thing but unfortunately it is necessary. It is not something I ever intended to get involved with, but I am now :)
[05:14] <elkbuntu> Many of our members came from other areas first and then we realized this is an area that still needs work to simply help level the playing field in Ubuntu and within many other F/LOSS projects.
[05:15] <elkbuntu> Unfortunately, even within Ubuntu, several female members have reported problems on mailing lists, within their loco teams and especially on IRC. . .
[05:16] <elkbuntu> Belinda actually posted something like this to a forum: ". . . when we start seeing the "I just got my tech skills insulted because of my gender" or "because I'm a man they just assumed I knew nothing technical about Linux/SysAdmin/prgramming/etc." post by men then we won't need women's groups."
[05:16] <elkbuntu> There are many technically capable women in the group and within F/LOSS, so it can be very frustrating when someone challenges your tech skills simply because "you?re a girl"
[05:17] <elkbuntu> And when we started sharing our experiences in IT, F/LOSS and even Ubuntu we realized that it is still happening.
[05:17] <elkbuntu> Even if you personally have experienced it or seen it happen, it can be very frustrating to see others go through bad experiences.  So the UW Project is also here to help in that area.
[05:18] <elkbuntu> Many of us joined the UW project because we found a welcoming group of folks who were open to questions and people with similar experiences as ours.
[05:18] <elkbuntu> At this point, i run out of notes, so I will start taking questions
[05:18] <elkbuntu> If there are any...
 QUESTION: dont you feel that by putting women in a special group, you actually follow a gender discrimination ?
[05:21] <elkbuntu> zorglu_, I used to feel that way, but then I came to realise that it wasnt 'putting women in a special group', but rather providing an outlet for discussion, mentoring, etc
[05:21] <elkbuntu> The group is more about sharing experiences, good and bad, and feeling comfortable and not along in the F/LOSS world
[05:22] <elkbuntu> When 95+% of people around you are male, it can be *very* lonely
 QUESTION: You mentioned problems with IRC, do you feel this is a problem with IRC itself (also mailing lists), in that essentially they are anonymous and make it difficult to police bad behaviour?
[05:22] <elkbuntu> It's not IRC exclusive by any means. Anywhere people communicate openly is a problem area
[05:23] <elkbuntu> When guys are used to being around guys, and remember, there's <5% women in alot of IT areas, they get used to 'being guys' and often are quite mean, insulting and insensitive without intending it
 QUESTION: should there be more ways to enforce the Code of Conduct on IRC? Like quicker banning people insulting women?
[05:24] <elkbuntu> The ways are already there, but the problem is identifying the problem to start with. Often women don't speak up, and leave instead, so they dont ahve to put up with 'Oh, you're making a huge deal out of nothing' or 'Can't you take a joke?'
 QUESTION: since the creation of this group do you feel like things are getting better?
[05:25] <elkbuntu> I cant really tell. U-W has effectively been around for the duration of my involvement in Ubuntu, so I don't know for sure what it was like beforehand
[05:25] <elkbuntu> However, I hope that it has made some women more comfortable, having people they can relate to in an easy to find place.
 QUESTION: is there a ubuntu-men ?
[05:26] <bababian> QUESTION: will the UW team have some focus on children also? I mean spreading the true UBUNTU idea among the once perceived-to-be disadvantaged group?
[05:26] <elkbuntu> No. But feel free to make one.
[05:26] <elkbuntu> bababian, in #ubuntu-classroom-chat please
[05:26] <elkbuntu> bababian, I've been tossing up with the idea of #ubuntu-youth, where younger Ubunteros can go to find people their own age to geek out with.
 QUESTION: can men help by particiating in the group somehow?
[05:27] <elkbuntu> Definately. Providing they're polite, helpful and dont exhibit the types of behaviours that Ubuntu-Women is there to couteract
 QUESTION: Any plans to have ubuntu-women website in languages other than english?
[05:27] <elkbuntu> It would be great. Translation efforts are always welcome in every part of the Ubuntu community ;)
[05:28] <elkbuntu> Belutz> QUESTION: will the UW team make an ubuntu theme for women?
[05:29] <elkbuntu> Alot of people seem to think all women want is pink and flowers. This is not the point of Ubuntu-Women, or LinuxChix or any $distro-Women groups. It is about social attitude.
[05:29] <elkbuntu> However, there are already feminine themes on gnome-look.org and kde-look.org ;)
 QUESTION: You mentioned problems with people doubting technical skills based on gender, do you think positive promotion would be worthwhile or cause more problems?
[05:30] <elkbuntu> I think it would definately be a good thing. One of the reasons I got involved with Ubuntu-Women, is as a role-model. I am a woman who is active and relatively successful in the community, and if it can inspire women, and give women a face, them I'm happy to do that
 QUESTION: It's important for women and men to speak up against offending behavior against women. However, mostly it is unintended, so the one speaking up should make sure to not also offend, because that just gets up defenses. How can we make sure this doesn't happen?
[05:31] <elkbuntu> I think it is extremely important. 'nipping it in the bud' for a lack of better definition is the best way to stop any problem before it blooms into a disaster
[05:31] <elkbuntu> Negative reinforcement, when guys overstep the line, is one of the most effective ways we have to hammer the concept home
 QUESTION: is UW team is a regional team or worldwide team? will there be a regional team for UW? or do you prefer it to be just a worldwide team?
[05:32] <elkbuntu> It is a world-wide team, At the moment, regional activities etc are probably better done through regional LinuxChix chapters
 QUESTION: what's the estimated percentages of female ubuntu users
[05:33] <elkbuntu> andreas lloyd gathered some statistics, as did i (still unreleased unfortunately), but the number of people who identify as women in the community are around 2.4%
 QUESTION: would you like to add a close in a code of conduct, specific to women ?
[05:34] <elkbuntu> I do not believe this is necessary. The code of conduct already covers respect etc, and that is what this boils down to.
 QUESTION: Do you have many female team members from countries like China, South Africa, and other developing countries?
[05:34] <elkbuntu> I dont know personally where everyone is from, but afaik Vid Ayer is indian
 QUESTION: has any men compained about the existence of UW team?
[05:34] <elkbuntu> Plenty. They're usually the type that 'dont get it' and hence the reason why there does need to be a team
 QUESTION: I'm a woman but never thought or felt that being one or other sex made any difference for me in IT, as the results I feel very confused about UW. However, I feel strongly about equality. Is there some way I can help or at least not harm without getting into UW as such?
[05:36] <elkbuntu> Lynoure, I am, well was with you in this mind at one point. We are the lucky ones
[05:36] <elkbuntu> As I said before, the main reason I did get involved is because I can be a positive rolemodel. I'm not a shrinking violet and it's good to show women who've been unfairly treated that they can be brave.
[05:37] <elkbuntu> I think the best way you can help indirectly, as can anyone here watching this, is to speak up when someone steps out of line. Negative reinforcement is a powerful tool.
 QUESTION: how do you feel about women that use computers only to do a particular jobs done, sometimes they think computer is windows and windos is computer, there are a lot of women who think like that in my country
[05:38] <elkbuntu> Belutz, I know more men like this than I do women.
[05:38] <elkbuntu> The problem is Windows having the majority mindshare, not women being unaware/uneducated.
[05:38] <elkbuntu> Nightrose> Qn: Where do you think is the point groups like UW and linuxchix are no longer needed?
[05:39] <elkbuntu> When women are appropriately represented in the IT industry
[05:39] <elkbuntu> When women don't feel chastised by their workmates and bosses
[05:39] <elkbuntu> When women are on a fair pay scale
[05:40] <elkbuntu> All those things are goals that we need to achieve before the mindset of inequality is filtered out
[05:40] <elkbuntu> Tm_T> elkbuntu: COMMENT: I think it's cultural thing to "teatch" that tecnology is for boys only in some cases (sure it's ridicolous)
[05:41] <elkbuntu> Believe it or not, I used to get that when I was younger. It's a deeper cultural issue than I think we'll see surpassed in our lifetimes, but it is the basis of the problem.
 QUESTION: I also find that women who study computer science in my country still think the same, do you blame the curriculum or the women who don't want to explore the world of computer science?
[05:42] <elkbuntu> I blame the curriculum, the media, etc. It is nothing to do with women. Maybe they just stand out more to you becuase they're already different?
[05:42] <elkbuntu> richb> QUESTION: There seems a popular perception that men assume that women will find Linux "hard to use" or worse still attach preconditions like "If Gnome had a pink theme, more women would use it!", obviously this is nonsense, is there an easy way to fix this perception?
[05:42] <elkbuntu> Convert grandma to Ubuntu ;)
[05:43] <elkbuntu> As i've been saying, this is the underlying issue. Women are not seen as equal, and hence are discriminated, discouraged and chastised.
 QUESTION: Are there efforts by UW to showcase the technical competence of UW members? Wouldn't that help to address one of the problems here--that of a perceived gender/technology gap?
[05:43] <elkbuntu> We would love to, and I believe someone in the group did surveys. It'd be interesting to see the results of that.
 QUESTION: will there be difference of mentality between geeks among women and non-geeks among women in terms of their attitude towards FOSS?
[05:44] <elkbuntu> bababian, Do you mean geeks are more problematic than other people?
[05:45] <elkbuntu> I think this is equally a stereotype. Many perceive geeks as the fat loner who's never had a girlfriend, or the horny teenage geek.
[05:45] <elkbuntu> stereotypes are dangerous no matter when or to whom they're applied
[05:46] <bababian> bababian>elkbuntu : i mean their understanding of the FOSS culture
[05:47] <elkbuntu> I'm still not sure what you're asking. Are you trying to ask if geeky women have more problems than other women?
[05:48] <elkbuntu> The problem is across the board in terms of gender problems, discrimination etc.
 QUESTION: so how do you suggest to educate women about FLOSS?
[05:48] <bababian> bababian>elkbuntu: i think women who tinker with tech would know more about the FOSS issues than their nontech counterparts do, in terms of having a receptive mind towards Linux/Ubuntu
[05:48] <elkbuntu> The same way you educate a man.
[05:49] <elkbuntu> bababian, likewise with men. Geeky men know Foss more than non-geeky men.
[05:50] <elkbuntu> any more questions?
[05:50] <elkbuntu> we still have 10 minutes :)
[05:50] <gnomefreak> may i?
[05:50] <elkbuntu> sure
[05:51] <gnomefreak> elkbuntu: do you expect the women geek or non geek be treated the same as men geek or non geek? I treat everyone same but this is one question ive seen beaten around but never asked to point)
[05:52] <Toma-> QUESTION: elkbuntu- whats the most attractive part about ubuntu that drew you and like minded women towards it?
[05:52] <elkbuntu> Toma-, the same things that drew the men to it.
[05:53] <Toma-> I was after the FOSS women :D but hey, if thats what floats your boat :)
[05:53] <elkbuntu> gnomefreak, I expect everyone to be treated equally. I expect the asian geeks and non-geeks to be treated the same as the american geeks and non-geeks, and so forth.
[05:54] <Toma-> Basically leading to my QUESTION: Whats the best way to sway a not-so-computer savvy girl to Ubuntu?
[05:55] <elkbuntu> Toma-, the same things you'd be swayed by. expecting a women to need a different type of computing environment, color, etc is part of the prooblem
[05:56] <elkbuntu> Toma-, we're all geeks. I like linux because of what it is, not by some girly feature
[05:56] <elkbuntu> the same as you dont need racecars on the desktop to like the system
[05:56] <elkbuntu> or so forth
 QUESTION: so women should be treated as anybody else without special consideration for their gender ?
[05:57] <elkbuntu> *YES* that is *exactly* what we mean
[05:57] <zorglu_> so why a special group for them ?
[05:58] <Toma-> i was thking that too :(
[05:58] <elkbuntu> when you take a characteristic of a someone and make fun of it, it's not nice, it is not respectful. making jokes for about women is like making jokes about someone's race, religion, big nose etc. you treat people as you expect to be treated. you do not tease their characteristics
[05:58] <elkbuntu> the reason we need ubuntu women is because *that is not happening*
[05:59] <elkbuntu> when it does happen, we'll be fine
[05:59] <zorglu_> you mean this is happening more to women than to other minorities ?
[06:00] <elkbuntu> zorglu_, it is happening to every minority. however, the problem with female sterotyping is it exists as a sub-problem of most of the other minorities as well
[06:00] <zorglu_> ok
[06:00] <sharms> @schedule now
[06:01] <Syk1> until my daughter (and I) can feel at ease in the Linux community then we'll appreciate groups like this. For now, an Ubuntu girl / woman is still a novel concept.
[06:01] <elkbuntu> ok, that's all we have time for... lets see who is up next
[06:01] <sharms> @now
[06:01] <ubotu> Current time in Etc/UTC: April 26 2007, 16:01:37 - Next meeting: MOTU in 3 hours 58 minutes
[06:01] <sharms> There we go
[06:02] <Adri2000> hi!
[06:02] <sharms> Welcome.  We are going to do a presentation on the MOTU
[06:02] <sharms> Adri2000: do you want to cover asking questions?
[06:03] <Adri2000> yep, I will take the questions in #ubuntu-classroom-chat
[06:03] <Adri2000> prefix them with "QUESTION:" please
[06:03] <sharms> Ok, well lets get this ball rolling, as we need as many of you to start working with us asap :)
[06:04] <sharms> I'm Steven Harms (www.sharms.org/blog), and work with the MOTU on various tasks.
[06:04] <Adri2000> and I'm Adrien Cunin, a simple MOTU :)
[06:04] <sharms> I am a member of the MOTU Media Team, which never has a shortage of things
[06:04] <sharms> to work on.
[06:04] <sharms> I am also a member of the bugs team, and an official ubuntu member.
[06:04] <sharms> If you are not familiar with the way teams work etc, we basically all collaberate at www.launchpad.net
[06:05] <sharms> That is where all the bugs go, where eventually source will go, and planning etc really happens
[06:05] <sharms> Also if you like anything you hear here, I highly recommend sticking around for the next session "Patching Packages" with Pitti.
[06:05] <sharms> At 19:00 UTC there is a "bug triaging" presentation also, which is a huge part of what I do.
[06:05] <sharms> With our huge userbase, there is never a shortage of bugs.
[06:06] <sharms> If you are not familiar with the way teams work etc, we basically all collaberate at www.launchpad.netMOTU stands for 'Masters Of The Universe' which originates from the Universe component, which holds the biggest amount of our packages.
[06:07] <sharms> Master of the Universe is also a he-man reference for those old enough to remember
[06:07] <elliotjhug> .3
[06:08] <elliotjhug> *sorry*
[06:08] <sharms> Now we have all downloaded packages if we are running Ubuntu, and these packages are stored in repositories
[06:08] <sharms> This is where we come in
[06:08] <sharms> There are various repositories ubuntu offers:  'main' and 'restricted' are supported by Canonical, 'universe' and 'multiverse' by the community.
[06:09] <sharms> 'main' and 'restricted' hold 5167 packages today and 'universe' plus 'multiverse' 16237.
[06:10] <sharms> One of the common misconceptions that people have about contributing to any form of Linux is that it seems that everyone is already working on everything.
[06:10] <sharms> This is not true, and there is a TON of opportunity to give a hand
[06:10] <sharms> As you can imagine, 16,000 packages is a lot to handle
[06:11] <sharms> Also the MOTU team is not secretive, and we are not the tron guy hiding behind 20 monitors
[06:11] <sharms> MOTU is extremely easy to talk to, and you can get involved at #ubuntu-motu
[06:12] <sharms> So what does a MOTU do?
[06:12] <sharms> As a MOTU you're maintaining packages.
[06:13] <sharms> In MOTU there isn't some big "this is my package you can't work on it" issue
[06:13] <sharms> MOTU's work where they are needed, whenever they want
[06:13] <sharms> We have people
[06:13] <sharms>  * taking care only of 'their own packages'
[06:14] <sharms>  * working together with others on a set of packages in a team
[06:14] <sharms>  * fixing lots of different packages
[06:14] <sharms> (* working on no packages at all)
[06:14] <sharms> If you belong to the last category, this might be your first step in the Ubuntu Development Community
[06:15] <sharms> The really important thing to remember is we want, and *need* your help
[06:15] <sharms> So if you are into Linux, you can help improvie it right here right now, give back, and help make great software
[06:15] <sharms> So how do I become a MOTU?
[06:16] <sharms> That's very easy.
[06:16] <sharms> ou basically contribute to the team's efforts, either by packaging a new piece of software or by helping with fixing / updating / merging existing packages.
[06:17] <sharms> One of the easiest ways to get involved is to start reviewing the bug reports, and eventually you will come across very easy to solve bugs that nobody has gotten around to.
[06:17] <sharms> This is great experience, and if you get stuck you can check out our docs at http://wiki.ubuntu.com/MOTU and if that fails, just ask someone in #ubuntu-motu
[06:18] <sharms> As a MOTU hopeful you're not allowed yet to upload to the archive yourself, but you can ask other team members to sponsor the upload for you.
[06:18] <sharms> When working with MOTUs, if you don't have upload access, you can also provide them with debdiffs, but that is probably a better topic for the patching packages talk
[06:18] <sharms> which I really recommend people attend, that is the first step
[06:19] <sharms> To get a package sponsored, we have a very easy to use process in place: https://wiki.ubuntu.com/SponsorshipProcess
[06:20] <sharms> After a while, when you've become more comfortable with packaging, the processes and you've worked with a couple of people, you will hear that people are tired of uploading your packages and you should be able to do so yourself
[06:21] <sharms> It's easy to see that it's not just a matter of technically abilty, but it's also a matter of teamwork and trust
[06:21] <sharms> Once your mentors and people of the MOTU team are happy with you, they will tell you to apply to become a MOTU yourself.
[06:22] <sharms> For that you write an application mail to the MOTU Council and if they're happy with you, they'll approve you.
[06:22] <sharms> I highly recommend anyone who is on the edge, who is thinking about giving back to Ubuntu, checks out the process to get going:
[06:22] <sharms> https://wiki.ubuntu.com/MOTU/Hopeful/Recruitment
[06:22] <sharms> That is where everyone starts pretty much, no matter what your aspiration
[06:22] <sharms> Things the team does:
[06:23] <sharms> We work on Bugs, just to put some numbers into the discussion:
[06:23] <sharms>  * 18484 bugs in Universe/Multiverse    (96084 in Ubuntu total)
[06:23] <sharms>  * 10380 closed bugs Universe/Multiverse (56612 closed in Ubuntu total)
[06:23] <sharms> While the numbers look scary, here's a very good thing about working with the MOTUs: you're not alone.
[06:23] <sharms> If you try to fix a bug in a package you have:
[06:23] <sharms>  1) Fellow MOTU members
[06:24] <sharms> 2) The Debian package maintainer
[06:24] <sharms> 3) The upstream (which is the actual author(s))
[06:24] <sharms> All of which you can pull on to get help on any issue
[06:25] <sharms> Working on bugs is very rewarding: sometimes it's just a one line fix, or it will already be fixed upstream and just needs to be pasted into the current code, and you make a ton of people (including yourself!) happy
[06:25] <sharms> Motu Teams
[06:25] <sharms> MOTU has formed a huge bunch of subteams already:
[06:26] <sharms> * Games Team
[06:26] <sharms> * Media Team
[06:26] <sharms> * Science Team
[06:26] <sharms> * Photo Team
[06:26] <sharms> * UncommonProgrammingLanguages team
[06:26] <sharms> and a lot of other teams, which started in Universe, but now are working across the whole distro, the Mono team is a good example for that.
[06:27] <sharms> If you see a team that doesn't fit your needs, all you need to do is grab a few MOTUs and get one created on launchpad
[06:27] <sharms> It's all about working together, making a great distro even better, and having fun while doing it
[06:27] <sharms> Transitions! That's usually an easy way to get involved.
[06:27] <sharms> In order to use a new technology consistently across the whole archive, we sometimes need to change several hundreds of packages.
[06:28] <sharms> This is gratifying work also, as it's sometimes easy to do and nice to do this within a team. Good examples of this were:
[06:28] <sharms> * the switch from python2.3 to python2.4 (as a default)
[06:28] <sharms> * the use of gcc4
[06:28] <sharms> * the transition to use Xorg
[06:28] <sharms> We used to have  H U G E   working lists on the wiki, nowadays we often use Launchpad to keep track of these
[06:29] <Xander21c> Hello
[06:29] <sharms> One of the questions we get the most is "How do I get X package in?"
[06:29] <sharms> Lots of software is packaged already, but your personal pet project might be missing still.
[06:30] <Toma-> Xander21c: chit chat + Questions in #ubuntu-classroom-chat
[06:30] <sharms> This is a gratifying task, as you make many users happy by providing igh-quality software in the archive.
[06:30] <sharms> or even high-quality
[06:30] <sharms> All NEW packages go through a review process, which currently happens on http://revu.tauware.de - this might change in the near future
[06:31] <sharms> If you want to know how to get a package in, we have a wiki page for that: http://wiki.ubuntu.com/MOTU/Processes/REVU
[06:31] <sharms> eviewing is a great way to mentor, but also to learn, which leads us to our next point.
[06:31] <sharms> Reviewing
[06:32] <sharms> One of the things with MOTU is that people seem to be overwhelmed at first
[06:32] <sharms> There is a lot of documentation out there, but really it isn't rocket science (although I believe laserjock is a rocket scientist)
[06:32] <sharms> One thing we do to help people along is provide a mentor (think Karate Kid style)
[06:33] <sharms> We're doing huge efforts at helping people get up to scratch on packaging, especially #ubuntu-motu on irc.freenode.net is always buzzing and somebody is always awake to answer *your* packaging question.
[06:33] <sharms> But mentoring also happens on our<EMAIL_ADDRESS>mailing list, in private chats, by doing reviews of packages and patches or via mail.
[06:34] <sharms> I personally went through the mentoring process during the beginning, and it was very helpful to get some questions answered that were not totally obvious to me
[06:34] <sharms> Don't hesitate to approach us, join the Master of the Universe today
[06:34] <sharms> The team is also working out details to refine the process and make it easier for MOTU hopefuls and future mentors.
[06:35] <sharms> If you read planet.ubuntu.com, you have probably seen my blog (www.sharms.org/blog) entry on mentoring, and that is getting good responses
[06:35] <sharms> and we are always looking to improve.
[06:35] <sharms> e'll have a session at UDS
[06:35] <sharms> about that:
[06:35] <sharms> https://blueprints.beta.launchpad.net/ubuntu/+spec/better-mentoring
[06:36] <sharms> so if you're in Sevilla at that time, join in, if not add your ideas to the wiki page. We'll also work on getting a Mentoring mailing list ready.
[06:36] <sharms> Merges
[06:36] <sharms> In the beginning of each release cycle we merge our efforts with those of the Debian maintainers.
[06:37] <PriceChild> For everyone not on the launchpad beta, please use the following link: https://blueprints.launchpad.net/ubuntu/+spec/better-mentoring
[06:37] <sharms> So this is what we currently do for Gutsy.
[06:38] <sharms> One thing people need to understand is that we are deeply connected with debian
[06:38] <sharms> Almost every package we have comes from them first
[06:38] <sharms> So at the beginning of the release cycle we take their packages, and "import" them into our repositories, which is called merging
[06:39] <sharms> https://wiki.ubuntu.com/MOTU/Merging and
[06:39] <sharms> https://wiki.ubuntu.com/MOTU/School/Merging-and-Syncing
[06:39] <sharms> are great references on the subject
[06:39] <sharms> Basically debian makes our lives easy, and we like to utilize their work as much as possible, and in turn contribute back
[06:40] <sharms> MOTU School
[06:40] <sharms> In the spirit of the Ubuntu's Open Week we already had some interesting MOTU School sessions: https://wiki.ubuntu.com/MOTU/School
[06:40] <sharms> and I am aware we have a bunch of questions, so let me just say
[06:40] <sharms> Documentation - we are always working on this and trying to make to easy to understand
[06:40] <sharms> https://wiki.ubuntu.com/MOTU/Documentation
[06:41] <sharms> Ok Adri2000 want to start Q&A?
[06:41] <Adri2000> let's go
 (for later) QUESTION: ffmpeg needs to be recompiled from source to get mp3 support, what about having a mp3 enable version in multiverse with other mp3 codes ?
[06:42] <sharms> I would say the first step in that direction would be a file a bug with as much information as you can possibly gather, and then join #ubuntu-motu and get someone from the media team to take a look
[06:43] <Adri2000> and it's a license problem, so it's finally up to the archive admin
[06:43] <sharms> Just be patience waiting for a response in #ubuntu-motu, we are not as fast as mcdonalds, but are probably faster than watching water boil
[06:43] <sharms> next
 QUESTION: If theres a bug in a package, youve posted the problem and the solution on launchpad, and still the maintainer hasnt fixed it, what can you do?
[06:44] <Adri2000> we haven't a maintainer for each package in ubuntu
[06:44] <sharms> That is an awesome question, I bet a lot of people have the same one
[06:44] <sharms> The best thing to do there is: Get involved!
[06:45] <Toma-> (Its in the kernel :))
[06:45] <Adri2000> ah, that's different
[06:45] <sharms> Kernel is generally not motu, we do the 15,000+ extra packages
[06:45] <sharms> next
 QUESTION: Debian has a process to orphan packages that have seen no attention recently. With no ownership of packages, or any commitments to quality, what process does MOTU have to retire unmaintained pacakges?
[06:46] <Adri2000> we can request a removal from the archive
[06:46] <sharms> I would say first and foremost, we do have an extreme commitment to quality
[06:47] <sharms> We have release cycles, and we work through those, along with "hug" days to get as much done on items that might not get as much attention
[06:47] <sharms> If debian drops the package also, we generally do unless there are other circumstances
[06:47] <sharms> so there are several tiers of eyes that take care of that
[06:48] <sharms> next
 QUESTION: are motu members starting to feel overwhelmed with the number of bug reports that are being submitted?  Do they feel that it's getting to be too much, or is it still manageable?
[06:48] <sharms> It is still manageable, but we would love to get more people to help
[06:48] <sharms> That is why we are here today, because it is important to get as many people involved
[06:48] <sharms> When talented people get less work, that is when more innovation can happen
[06:49] <sharms> and really push us into critical-mass
[06:49] <sharms> next
 QUESTION: What will be interesting upcoming "transistion" and when are they planned to occur?
[06:50] <sharms> We are still waiting to flesh out details of gutsy after the UDS, so its hard to say.  Adri2000 have anything to ad?
[06:50] <Adri2000> g77 transition
[06:50] <Adri2000> it's in the email "Opening development for Gutsy Gibbon"
[06:51] <Adri2000> so that's at least one transition for gutsy :)
[06:51] <sharms> Just to verify with everyone, g77 doesn't sound like much fun, but if you stick around #ubuntu-motu you will see items like that come up
[06:51] <Adri2000> next?
[06:51] <sharms> yup
 QUESTION: Any news on revu2?
[06:52] <Adri2000> I don't think it is actively being developed now
[06:52] <Adri2000> because we will eventually use launchpad instead of revu
[06:52] <sharms> Really we want to keep the scope of this talk to people new to MOTU.  If you know what revu2 is, then you just need to hang in #ubuntu-motu
[06:53] <sharms> next
 QUESTION: How do one go about patching a motu universe package for Feisty since feisty has already been released, if the fix (missing dependency in debian/control) is trivial, without having to wait for gusty repos to be open?
[06:53] <sharms> Well first, it has to be a nasty bug to be fixed to make it into feisty
[06:53] <sharms> and definitely nothing to do with changing features etc
[06:54] <sharms> But we have a team just for security fixes, which would be very important
[06:54] <pitti> Loic: https://wiki.ubuntu.com/MOTU/SRU describes that process
[06:54] <Adri2000> you'll have to do an SRU, Stable Release Update: https://wiki.ubuntu.com/MOTU/Processes/SRU
[06:54] <sharms> There we go :) next
 QUESTION: What's the best way to get a mentor?
[06:55] <sharms> When I got a mentor, I just followed the wiki page, and then I found their nick and starting talking on IRC
[06:55] <sharms> when I ran into issues, I tried to figure it out, if I couldn't they were there to help me
[06:56] <Adri2000> or just ask in #ubuntu-motu, on the mailing-list :)
[06:56] <Adri2000> the wiki page is https://wiki.ubuntu.com/MOTU/Mentors
[06:56] <sharms> MOTU members are a big fan of trying to figure out things from documentation first
[06:56] <sharms> but we can definitely help you if the docs are confusing
[06:56] <sharms> next
 QUESTION: I'm the developer of a new program. Are there guides on building a package from scratch for Ubuntu, as opposed to patching? Also, would I become the maintainer of my package?
[06:57] <Adri2000> first question: yes, we have the packaging guide
[06:57] <sharms> We don't have concrete maintainers, but you can chose to just work on your package
[06:57] <sharms> http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html
[06:57] <sharms> that is the first and best step right there
[06:58] <sharms> I would also recommend taking a similar package and looking at their source for packaging
[06:58] <sharms> next
 QUESTION: What if alot of bugs in a package can be fixed by installing the latest release in debian unstable? Is there a chance to get it updated in feisty? eg, 2.16.0 --> 2.16.1
[06:58] <Adri2000> not in feisty
[06:59] <sharms> next
[06:59] <sharms> 1 more minute!
[06:59] <Adri2000> you'll have to take out the appropriate patches from debian
 [18:54]  <zorglu_> QUESTION: revu has been known as a bottleneck, what are the plan to speed it up ?
[06:59] <Adri2000> but that's revu again :)
[06:59] <zorglu_> Adri2000: yep you can skip it :)
[06:59] <sharms> ok well please, everyone join us at #ubuntu-motu
[07:00] <sharms> hang out, get a feel for the people
[07:00] <Toma-> Thanks!
[07:00] <sharms> Thank you very much, stick around for Pitti's talk.  He is awesome and can get into some of the technical, nitty-gritty
[07:00] <Adri2000> thanks everybody for coming! :)
[07:00] <pitti> sharms: thanks :)
[07:01] <MattJ> Thanks all :)
[07:01] <pitti> welcome to my hands-on training about patching packages, an inevitable tool for new developers
[07:01] <pitti> as a warning, this will be the very same talk that I did on Tuesday
[07:01] <pitti> so if you were in that, this won't be particularly interesting
[07:01] <pitti> if anyone has any question, or I'm totally uncomprehensible (sorry for my English, I'm German), please do not hesitate to interrupt and ask *immediately*
[07:01] <pitti> Also, don't bother trying to take notes, we'll sort that out at the end. You can fully concentrate on the discussion and examples.
[07:02] <pitti> who here would learn about patching packages? (quick audience straw-poll)
[07:02] <elliotjhug> me
[07:02] <rrittenhouse> mememe :P
[07:02] <sampbar> me!
[07:02] <el_ericho> me
[07:02] <pitti> that sounds more than manageable :)
[07:03] <sampbar> (not that i have any packages to patch)
[07:03] <pitti> Let's begin with a little bit of history:
[07:03] <pitti> == Why use separate patches ==
[07:03] <pitti> In earlier times, people just applied patches inline (i. e. directly in the source code tree). However, this makes it very hard to extract patches later to modify them, send them upstream, etc. Also this means that new upstream versions are a pain, since they generate a lot of rejections when applying the package diff.gz to them.
[07:03] <pitti> With split-out patches it is much easier to send them upstream, keep track of them, develop them, etc., since you always see which changes belong together.
[07:03] <pitti> The ideal state is an unmodified tarball from upstream, plus clean and separate patches, plus the packaging bits in debian/. That means that lsdiff -z <sourcepackage>.diff.gz only contains debian/.
[07:03] <pitti> oh, btw, I assume that you already know what a source package is and how it looks like in general
[07:04] <pitti> The first attempts to split-out patches were pretty trivial: storing patches in debian/patches/, and adding some patch/patch -R snippets to debian/rules. This worked for small patches, but provided no tools for editing these patches, updating them for new upstream versions, etc.
[07:04] <pitti> (we will see why that is painful)
[07:04] <pitti> Thus several standard patch systems were created which are easy to deploy and provide tools for patch juggling and editing.
 pitti: QUESTION: Will you speak about patching a module for everybodys use or for one'own use?
[07:05] <pitti> that doesn't matter much
[07:05] <pitti> of course packages that will be uploaded need to be more strict and cleaner
[07:05] <pitti> but it's still useful if you personally do a patch and just want to send it to someone, or keep it around for a while
[07:05] <pitti> What I would like to do now is to introduce the most common patch systems and show some hands-on demo how to add a new patch and how to edit one. For this, I will point at a source package from the current feisty archive, quickly explain the patch system, and show how to apply some (braindead) modifications to it. I recommend you to do the same steps in a terminal, so that you get a feeling for the process and can immediately ask questions.
[07:05] <pitti> is everyone fine with this approach?
[07:06] <Elephantman> bye :)
[07:06] <elliotjhug> sounds good
[07:06] <rrittenhouse> sure
[07:06] <Elephantman> (sorry, amsg)
[07:06] <pitti> sampbar: that will make it kind of tricky; well, just listen then and do the steps later according to the documentation and irc log
[07:06] <pitti> If you want to try the stuff yourself, please do the following commands (on feisty) as preparation:
[07:06] <pitti>   sudo apt-get install dpatch cdbs quilt patchutils devscripts
[07:06] <pitti>   apt-get source cron udev pmount gnome-volume-manager ed xterm
[07:06] <pitti>   wget http://people.ubuntu.com/~pitti/scripts/dsrc-new-patch
[07:06] <pitti>   chmod 755 dsrc-new-patch
[07:07] <pitti> I deliberately picked the smallest packages I could find
[07:07] <Toma-> Hows the weather? :)
[07:07] <sampbar> Pitti: good plan :)
[07:07] <pitti> Toma-: splendid here :) (but please stay on topic)
[07:08] <pitti> please make a noise when you are ready
[07:08] <ranf> done
[07:08] <elliotjhug> done
[07:08] <Toma-> Ok, can you upload patches to launchpad? Is that a good way of getting it applied?
[07:08] <Loic> done
[07:08] <pitti> Toma-: later, please queue in #chat
[07:09] <Toma-> ok!
[07:09] <pitti> == udev: separate patches, but no standard patch system ==
[07:09] <pitti> erm, sorry, scratch that ^
[07:09] <pitti> == cron: inline patches ==
[07:09] <pitti> No patch system at all, nothing much to say about this.  You directly edit the files in the source tree. This is convenient for a simple and quick change, but will bite back for new upstream versions (see above) and is inconvenient for submitting patches upstream, or reviewing for merges.
[07:09] <pitti> just because all patches you apply will end up as a giant big mess in the diff.gz
[07:10] <pitti> if you do 'lsdiff -z <package>.diff.gz' and you see changes which are not in debian/, then you probably have such a package
[07:10] <pitti> so, I think I do not need to say anything else about cron, unless someone has a question
[07:10] <pitti> == udev: separate patches, but no standard patch system ==
[07:11] <pitti> This case is the most complicated one since you have to do all the hard work manually. In order to make you understand what a patch system does, and to give you a fallback method that will *always* work with any patch system, I handle this first.
[07:11] <pitti> The good news is that you will seldomly be required to actually do this procedure, since for many packages there are nice tools which make things a charm.
[07:11] <pitti> The bad news is that it may seem utterly complicated for people who never did it before, but I would like you to understand what's actually going on behind the curtains of the tools.
[07:11] <pitti> So please do not desperate if you do not fully understand it at first; there's written documentation and you can always take your time to grok it.
[07:11] <pitti> The general approach is:
[07:11] <pitti> 1. copy the clean source tree to a temporary directory /tmp/old
[07:11] <pitti> 2. apply all patches up to the one you want to edit; if you want to create a new patch, apply all existing ones (this is necessary since in general patches depend on previous patches)
[07:12] <pitti> 3. copy the whole source tree again: cp -a /tmp/old /tmp/new
[07:12] <pitti> 4. go into /tmp/new, do your modifications
[07:12] <pitti> 5. go back into /tmp and generate the patch with
[07:12] <pitti>   diff -Nurp old new > mypatchname.patch
[07:12] <pitti> 6. move the newly generated patch to <original source dir>/debian/patches/mypatchname.patch
[07:12] <pitti> in general we want the following diff options:
[07:12] <pitti> -N -> include new files
[07:12] <pitti> -u -> unified patches (context diffs are ugly)
[07:12] <pitti> -r -> recursive
[07:12] <pitti> -p -> bonus, you can see the name of the affected function in the patch
[07:13] <pitti> does anyone have a question about the principle method?
[07:13] <pitti> ok, some hands-on example
[07:13] <pitti> open a shell, ready your fingers :)
[07:13] <pitti> udev example 1, let's create a new patch 92_penguins.patch:
[07:14] <pitti>   cd /whereever/you/unpacked/the/source/udev-108
[07:14] <pitti> -> now we are in our original source tree where we want to add a new patch
[07:14] <pitti>   cp -a . /tmp/old
[07:14] <pitti> -> create a copy of the clean sources as reference tree
[07:14] <pitti>   pushd /tmp/old
[07:14] <pitti> -> go to /tmp/old; 'pushd' to remember the previous directory, so that we can go back conveniently
[07:14] <bullgard4> pitti: I am ready.
[07:15] <pitti>   debian/rules patch
[07:15] <pitti> -> apply all already existing patches; of course we could use the 'patch' program to do it manually, but since debian/rules already knows how to do it, let's use it. The actual name for the patch target varies, I have seen the following ones so far: patch, setup, apply-patches, unpack, patch-stamp. You have to look in debian/rules how it is called.
[07:15] <pitti>   cp -a . /tmp/new; cd ../new
[07:15] <pitti> -> copies our patched reference tree to our new work directory /tmp/new where we can hack in
[07:15] <pitti> that's the preparatory part
[07:15] <pitti> let's do a braindead modification now
[07:16] <pitti>   sed -i 's/Linux/Penguin/g' README
[07:16] <pitti> -> changes the README file; of course you can use your favourite editor, but I wanted to keep my examples copy&pasteable
[07:16] <pitti> and now we create a patch between the reference and our new tree:
[07:16] <pitti>   cd ..
[07:16] <pitti> -> go back to /tmp, i. e. where our reference tree (old) and hacked tree (new) is located
[07:16] <pitti>   diff -Nurp old new > 95_penguins.patch
[07:16] <pitti> -> generate the patch (Ignore the 'recursive directory loop' warnings)
[07:17] <pitti>   popd
[07:17] <pitti> -> now you should be back in your original source tree (when you did the pushd)
[07:17] <pitti>   rm -rf /tmp/old /tmp/new
[07:17] <pitti> -> clean up the temporary trees
[07:17] <pitti>   mv /tmp/95_penguins.patch debian/patches
[07:17] <pitti> -> move the patch from /tmp to the source tree's patch directory, where it belongs.
[07:17] <pitti> *uff* :)
[07:17] <pitti> Now take a look at your shiny new debian/patches/95_penguins.patch.
[07:18] <pitti> after that, if you do 'debian/rules patch', you'll see that the patch applies cleanly; please do 'debclean' afterwards to unapply the patches and get back a pristine source tree
[07:18] <pitti> so, obviously that's not the end of the wisdom, but if you do these steps a couple of times, you should get a feeling for how to create the most complicated patch conceivable
[07:18] <pitti> so this procedure is the life safer if anything else fails
[07:18] <pitti> questions so far?
[07:19] <pitti> are you guys still with me? Am I too fast? (cry and slow me down if so)
[07:20] <pitti> but promised, from now on it will get really easy :)
[07:21] <sampbar> im still here but im not doing the commands
 COMMENT: debclean complains about missing build dependencies
[07:22] <pitti> ranf: ah, right; you can use 'fakeroot debian/rules clean' to work around that, or just apt-get install them
[07:23] <ranf> k
[07:23] <pitti> Since this case happens pretty often, I created a very dumb helper script 'dsrc-new-patch' for this purpose.
[07:23] <pitti> Using this, above steps would reduce to:
[07:23] <pitti>   ../dsrc-new-patch 95_penguins.patch
[07:24] <pitti>   sed -i 's/Linux/Penguin/g' README
[07:24] <pitti>   <press Control-D to leave the subshell>
[07:24] <pitti> that looks slightly better, doesn't it? If you like the script, please put it into your ~/bin, so that it is in your $PATH
[07:24] <pitti> but I had to torture you with the close-to-the-metal method for the sake of understanding.
[07:24] <pitti> dsrc-new-patch is currently too dumb to edit existing patches, or to put patches somewhere else than the top of the patch stack. If you need this, then you need to do the manual approach.
[07:25] <pitti> everyone in sync?
[07:27] <pitti> oh, just answer here, btw
[07:27] <pitti> Loic: just needing more time, or some difficulties?
[07:28] <Loic> What r the steps done by dsrc-new-patch
[07:28] <pitti> Loic: the script does the exact same steps that you did manually before
[07:29] <pitti> ok, let's go on then
[07:30] <pitti> Since this is so hideously complicated, patch systems were invented to aid you with that. Let's look at the most popular ones now (they are sufficient to allow you to patch about 90% of the archive's source packages; for the rest you have to resort to the manual approach above).
[07:30] <pitti> == pmount: cdbs with simple-patchsys ==
[07:30] <pitti> cdbs' simple-patchsys.mk module matches its name, it has no bells and whistles whatsoever. However, it is pretty popular since it is sufficient for most tasks, and long ago I wrote a script 'cdbs-edit-patch' which most people can live with pretty well. This script is contained in the normal cdbs package.
[07:30] <pitti> if you have a package, you can tell that it uses this system by checking debian/rules
[07:31] <pitti> it has 'include /usr/share/cdbs/1/rules/simple-patchsys.mk'
[07:31] <pitti> You just supply the name of a patch to the script, and depending on whether it already exists or not, it will create a new patch or edit an existing one.
[07:31] <pitti> everyone please look in debian/patches, debian/rules to get a feeling how it looks like
[07:31] <pitti> so, let's mess up pmount a bit
[07:31] <pitti> and add a new patch
[07:31] <pitti>   cd /whereever/you/unpacked/the/source/pmount-0.9.13
[07:31] <pitti>   cdbs-edit-patch 03-simple-readme.patch
[07:31] <pitti>   echo 'This should document pmount' > README
[07:31] <pitti>   <press Control-D to leave the subshell>
[07:32] <pitti> easy, isn't it?
[07:33] <pitti> this will take care of applying all patches that need to be applied, can change patches in the middle of the stack, and also create new ones
[07:33] <pitti> Editing an already existing patch works exactly the same way.
[07:33] <pitti> so I won't give a demo
[07:33] <pitti> (BTW, "cdbs-edit-patch" is slightly misleading, since it actually only applies to simple-patchsys.mk. You can also use other cdbs patch system plugins, such as dpatch or quilt.)
[07:34] <pitti> questions?
[07:34] <pitti> == ed: dpatch ==
[07:35] <pitti> dpatch is a pretty robust and proven patch system which also ships a script 'dpatch-edit-patch'
[07:35] <pitti> packages which use this build-depend on 'dpatch', and debian/rules includes 'dpatch.mk'
[07:35] <pitti> The two most important things you should be aware of:
[07:36] <pitti>  * dpatch does not apply debian/patches/*, but instead applies all patches mentioned in debian/patches/00list, in the mentioned order. That means that you do not have to rely on asciibetical ordering of the patches and can easily disable patches, but you have to make sure to not forget to update 00list if you add a new patch.
[07:36] <pitti> (forgetting to update 00list is a common cause of followup uploads)
[07:36] <ranf> "dpatch.make" that is in debian/rules
[07:36] <pitti> right, sorry
[07:37] <pitti>  * dpatch patches are actually scripts that are executed, not just patches fed to 'patch'. That means you can also do fancy things like calling autoconf or using sed in a dpatch if you want.
[07:37] <pitti> using dpatch for non-native patches is rare, and normally you do not need to worry about how a .dpatch file looks like
[07:37] <pitti> but I think it's important to mention it
[07:37] <pitti> so if you ever want to replace *all* instances of Debian with Ubuntu in all files, write a dpatch with a small shell script that uses sed
[07:37] <pitti> instead of doing a 300 KB static patch which won't apply to the next version anyway :)
[07:37] <pitti> The manpage is very good and has examples, too, so I will only give an example here:
[07:37] <pitti> This will edit an already existing patch and take care that all previous patches are applied in order:
[07:37] <pitti>   cd /whereever/you/unpacked/the/source/ed-0.2
[07:37] <pitti>   dpatch-edit-patch 05_ed.1-warning-fix
[07:37] <pitti>   <edit stuff, press Ctrl+D>
[07:38] <pitti> so that's exactly like cdbs-edit-patch
[07:39] <pitti> ok, now we edited a patch, that was pretty straightforward now
[07:39] <pitti> now let's create a new one; this is a bit different from cdbs-e-p
[07:39] <pitti>   dpatch-edit-patch foo.dpatch 06_testsuite-Makefile.dpatch
[07:39] <pitti>   <edit stuff, press Ctrl+D>
[07:39] <pitti>   echo foo.dpatch >> debian/patches/00list
[07:40] <pitti> This will create a new patch foo.dpatch relative to the already existing 06_testsuite-Makefile.dpatch. If your patch is very confined and does not depend on other patches, you can leave out the second argument.
[07:40] <kalila> Rosetta classroom on?
[07:40] <pitti> please note the last action (adding your new patch at the appropriate position in the patch list)
[07:40] <pitti> kalila: not yet, 'patching source packages' ATM
[07:41] <pitti> is the issue of patch dependencies clear to everyone or do you have questions about it?
[07:42] <pitti> there's a third (and last) common patch system, quilt, but it's a bit more difficult
[07:42] <mastroDani> 20 minutes to the next lesson?
[07:42] <pitti> do you want to learn about this as well, or rather digest the stuff above and discuss it more in-depth?
[07:43] <jjstwerff> doesn't matter much to me... I will try all of those for myself soon ;)
[07:44] <pitti> then let's discuss the question of patch ordering a bit
[07:44] <pitti> usually, when you maintain packages, there are several types of patches
[07:45] <pitti> sometimes you create a distro-specific patch which will not go upstream
[07:45] <pitti> those should go at the top of the patch stack
[07:45] <pitti> but sometimes you get a bug fix from upstream cvs, etc.
[07:45] <pitti> those should go at the bottom, i. e. be applied to the original code *first*
[07:46] <pitti> so that (a) they have a better chance to actually apply (you might modify the same code in a custom patch)
[07:46] <pitti> and (b) you keep your custom patches up to date, so that you have a better chance to send them to upstream
[07:46] <pitti> upstreams really like patches which apply to their cvs head :)
[07:49] <pitti> if you need a reference of patch systems (including quilt), there is a wiki page https://wiki.ubuntu.com/MOTU/School/PatchingSources which provides most of above information in a more convenient format.
[07:49] <pitti> However, it might be slightly out of date (it's from dapper times). Feel free to update the page and and add missing bits.
[07:49] <pitti> [07:49] <pitti> As you saw, Debian source packages do not have any requirements wrt. structure, patch systems, etc., other source package systems like SRPM are much stricter wrt that. This of course means more flexibility, but also much more learning overhead.
[07:49] <pitti> As a member of the security team I can tell tales of the pain of a gazillion different source package layouts... :)
[07:50] <pitti> Therefore some clever people sat together the other day to propose a new design which would both give us a new and unified source package and patch system that uses bzr (with a quilt-like workflow). This would also integrate packages and patches much better into Launchpad and revision control in general.
[07:50] <pitti> Please take a look at https://wiki.ubuntu.com/NoMoreSourcePackages if you are interested in this.
 <pitti> Thanks. I can also just edit any file in debian/ as well?
[07:50] <pitti> that's indeed an interesting question
[07:51] <pitti> in general I recommend *not* to patch debian/ control files in patches
[07:51] <pitti> since developers expect that they can change debian/* stuff at will
[07:51] <pitti> patches should really just patching the upstream bits, i. e. everything except debian/*
 QUESTION: 2nd question : in dpatch-edit-patch foo.dpatch 06_testsuite-Makefile.dpatch why do you have 2 *.dpatch files? Why not just 06_testsuite-Makefile.dpatch ?
[07:52] <pitti> "This will create a new patch foo.dpatch relative to the already existing 06_testsuite-Makefile.dpatch."
[07:52] <kalila> I am hoping this is recorded somewhere
[07:52] <pitti> Loic: i. e. this command will not touch 06_testsuite-Makefile.dpatch *at all*
[07:53] <pitti> Loic: instead, it will apply all existing patches up to 06_testsuite-Makefile.dpatch and then create a new patch foo.dpatch relative to that with the modifications you do in the subshell
[07:53] <ranf> So foo lands before or after 06_test...
[07:53] <pitti> kalila: https://wiki.ubuntu.com/MOTU/School/PatchingSources
[07:53] <pitti> ranf: if you use the 'echo foo.dpatch >> debian/patches/00list' command that I gave, it will land after it
[07:54] <pitti> ranf: since in dpatch there is no asciibetical patch order, but it is defined in the debian/patches/00list file
 "those should go at the bottom, i. e. be applied to the original code *first*" How do I make a patch get at the botom instead?
[07:55] <pitti> Loic: with dpatch, you leave out the second argument (which specifies the 'parent' patch)
[07:56] <pitti> Loic: and then add the new patch file name at the top in 00list
 "and then add the new patch file name at the top in 00list" can I just manually edit 00list after patching?
[07:57] <pitti> yes, as I said, when you create a new dpatch, you *have* to add it to 00list manually
[07:57] <pitti> unlike cdbs-edit-patch, where there is no explicit list
[07:57] <pitti> i. e. there the list is 'ls debian/patches/*'
 pitti do you use meld or something like this?
[07:59] <pitti> ranf: I don't; maybe you can explain what meld is?
[07:59] <ranf> a graphical diff.
[07:59] <jjstwerff> it can show differences between directories of files
[07:59] <jjstwerff> including an editor
[07:59] <pitti> ah; well, I'm a hopeless hardcore 'diff | vim -' user, I'm afraid :)
[08:00] <ranf> np
[08:00] <pitti> if you have some good hints how to use that to make patching more efficient, I invite you to mention it on the wiki page
[08:00] <pitti> but time is up, I'm afraid, so I'll give away the microphone here
[08:01] <danilos> pitti: thanks
[08:01] <pitti> I'm still available in #chat
[08:01] <danilos> Welcome to "Translating with Launchpad" Session.  Thanks for joining us.
[08:01] <danilos> I am Danilo Segan, and I will be your host together with Carlos Perello Marin ("carlos" on the channel).
[08:02] <danilos> I'd also like to announce that since recently, we've got a new member of the Launchpad Translations development team: Jeroen Vermeulen or jtv on IRC (when online), and you can catch all three of us regularly on #launchpad channel for any questions or issues.
[08:02] <danilos> Launchpad is a platform for collaborative development of free software, and a major component of free software development is doing translations.
[08:03] <danilos> Launchpad provides system for management of translation work, and system for doing translations over the web or offline.
[08:03] <danilos> To start doing translations, head over to http://translations.launchpad.net/
[08:03] <danilos> Launchpad can help translate distributions and projects, and help their maintainers organise entire translation effort.
[08:03] <danilos> Launchpad can help individual translators find software to translate, translation teams to join, and makes it easier for them to do translations.
[08:03] <danilos> Launchpad can help translation teams organise, share effort and standardize terminology to use.
[08:04] <danilos> = Distributions and Projects =
[08:04] <danilos> For distributions or projects, there are many benefits.
[08:04] <danilos> They can leave entire translation organisation on Launchpad, which provides privilege control, team management, PO uploads and downloads via tarballs, use of big existing pool of translators and translations.
[08:04] <danilos> For example of a distribution taking maximum advantage of Launchpad Translations system, check out https://translations.launchpad.net/ubuntu/ (but you probably knew that already)
[08:04] <danilos> Maintainers/distributors can track their imports using translations import queue page at https://translations.launchpad.net/translations/imports
[08:05] <danilos> Since we love helping project maintainers use Launchpad as their translation service, you can send any questions in the Q&A part of the session (I am leaving a lot of time for questions).
[08:05] <danilos> So get your questions ready, there will be plenty of time to answer them :)
[08:05] <danilos> = Translators  =
[08:05] <danilos> Last session showed that we get most interest from translators, so here's what it can do for them.  I'll describe the basic usage and how you can make most of Launchpad.
[08:05] <danilos> As a translator, first thing you'd want to do is set your preferred languages (Launchpad can sometimes pick them up based on your IP address, but don't rely on that):
[08:05] <danilos> https://translations.launchpad.net/+editmylanguages
[08:06] <danilos> Then you can either join one of Ubuntu translation teams (https://translations.launchpad.net/translations/groups/ubuntu-translators) or start your own, or you can simply translate any of the projects which are using Launchpad for their translations: https://translations.launchpad.net/translations/+products-with-translations
[08:06] <danilos> When you go either to a translation overview page for a package (https://translations.launchpad.net/ubuntu/feisty/+source/debian-installer/+translations) or a product (https://translations.launchpad.net/silva/), you'll see a list of templates which you can translate, and their translation status for your preferred languages (so you can see why was that important above).
[08:07] <danilos> Clicking on the language title will take you directly to the page where you can add your translation suggestions (or review other suggestions, depending on your privileges).
[08:07] <danilos> Alternative way to find what to translate is to head over to choose distribution release from the start page, such as Ubuntu Feisty, and then choose language you want to work on from that page: https://translations.launchpad.net/ubuntu/feisty/+translations
[08:08] <danilos> When you click on a language, you'll get a list of all packages you can translate for Ubuntu Feisty, sorted by priority (as given by Ubuntu packagers and Launchpad Translations team).
[08:08] <danilos> When finally on the translation page, you see a list of translatable messages, ten per page, with their translations, suggestions and a field to enter new translation.  Using that is, hopefully, clear, and if not, file a bug so we can make it clear.  Some things are trickier (such as 'need review' marking), so feel free to drop by #launchpad and ask for explanation any time.
[08:09] <danilos> It's important to note that your privileges determine what you can do: eg. for Ubuntu, if you are a member of Spanish translation team, you can submit translations directly.  If you are not, your submissions will only appear as suggestions in Spanish translation, and a member of Spanish team will have to approve it.
[08:10] <danilos> Translation page also allows filtering translated, untranslated and entries which need review.  This can help you complete big translations which lack only a few translations to be complete again.
[08:10] <danilos> On that same translate page, you can download (look for 'Download' in the Actions menu) PO files to work offline using any of the PO editors (GTranslator, KBabel, POEdit, Emacs+po-mode, any text editor), and you can upload them back using 'Upload a file' in the Action menu on the left.
[08:11] <danilos> Now, lets get to organising translation teams.
[08:11] <danilos> = Translation teams =
[08:11] <danilos> Launchpad can help you organise your translation teams.
[08:11] <danilos> Translation teams are general Launchpad teams which can be assigned one of the translation duties (eg. https://launchpad.net/~ubuntu-l10n-es is in charge of translating Ubuntu into Spanish)
[08:11] <danilos> This is controlled using something we call 'Translation Groups'--https://translations.launchpad.net/translations/groups/.  This provides a mapping between languages and teams which translate for them.
[08:12] <danilos> Every distribution or project can select a translation group they want to use for their translations.
[08:12] <danilos> Members of translation teams should *only* be trusted translators: they will have full power over translations for that language, and you should NOT let anyone in.
[08:13] <danilos> We've had a lot of problems upstreams complaining about bad translations, and most of them were due to badly managed teams (i.e. teams allowing anyone in). So, don't do that, and be strict about who you let in :)
[08:13] <danilos> At the moment, to organise work you need to coordinate outside Launchpad: use mailing lists, IRC, Jabber or whatever.  We will be solving this.
[08:14] <danilos> And I am done with my short overview of what can Launchpad do for translators. I *do* expect a lot of questions later on, but now I'm continuing with our plans for the future.
[08:15] <danilos> = Future =
[08:15] <danilos> We've got big plans for the future, and some of the priorities are the
[08:15] <danilos> following:
[08:15] <danilos> - Search for translations (yes, infamous bug 44 in LP)
[08:15] <danilos> (you all saw that coming, didn't you)
[08:15] <danilos> - Support for legacy KDE PO files (plural forms and context)
[08:15] <danilos> - Native support for other translation formats (Mozilla, OpenOffice.org...)
[08:16] <danilos> - Fixing import queue to give priority to human provided PO files and PO files for products over PO files for distribution (which there are usually too many of, so products and people wait because of them)
[08:16] <danilos> - Improve speed (we're taking concrete steps to make this happen :)
[08:16] <danilos> - Improve mechanisms for upstream cooperation (I expect some Qs in Q&A about this)
[08:17] <danilos> - Make team management more flexible and powerful
[08:17] <kalila> hehe
[08:17] <danilos> - 'Open' Gutsy translation by May 31st
[08:17] <danilos> We welcome suggestions on what should we focus on, even if we've got so much work to do already to make Launchpad rock.
[08:17] <danilos> So, now to some interesting bits.
[08:17] <danilos> = Tips, tricks and trivia =
[08:17] <danilos> There's got to be some stuff you didn't know. Or you did, but didn't share with others :)
[08:18] <danilos> When uploading, choose 'Published upload' if you don't want to override others' translations that have happened in the meantime.
[08:18] <danilos> You can download PO files to find a specific string in it (many have done this already)
[08:18] <danilos> For Ubuntu, start translating from the top of https://translations.beta.launchpad.net/ubuntu/feisty/+lang/sr (for Serbian): they are sorted by priority.
[08:19] <carlos> (remove beta from the given URL)
[08:19] <danilos> Don't forget to update Last-Translator field when translating via PO files, and also never remove or change X-Rosetta-Export-Date field from PO header (or you won't be able to re-import it).
[08:19] <danilos> carlos: thanks, that's right, the link should be https://translations.launchpad.net/ubuntu/feisty/+lang/sr
[08:19] <danilos> Use Google with "site:translations.launchpad.net" to search for strings as a workaround.  This will commonly give you pointer to someone's translations page, but you can pick a template name from there, visit it, and switch over to your own language.
[08:20] <danilos> For those of you familiar with 'Rosetta', you can notice that we rarely use it, and we are favouring just 'Launchpad' or 'Launchpad Translations' for the present and future :)
[08:20] <danilos> You can use [nbsp]  to get non-breaking spaces if you've got problems inserting them directly (Firefox is known to be buggy with them).
[08:20] <danilos> Don't upload wrong PO files (eg. wrong language): this will mess up suggestions for entire PO file.
[08:20] <danilos> No need to email us back with 'thank you' for automatic exports (though, we indeed appreciate those :).
[08:21] <danilos> When you get message that your language is missing plural forms, either email us at<EMAIL_ADDRESS>or file a ticket using https://answers.launchpad.net/rosetta/
[08:21] <danilos> And that's it: I'd welcome you to #launchpad on FreeNode and rosetta-users and ubuntu-translators lists
[08:21] <danilos> = Questions and Answers =
[08:21] <danilos> This is where I expect Carlos to be a big help.  Guys, shoot.
 danilos: QUESTION: Does Ubuntu prefer American English or British English?
[08:22] <danilos> I've seen this one already answered on chat channel, but lets repeat: it's supposed to be American English, and British English provides a translation
[08:22] <kalila> QUESTION: ok, let me get this out of the way :)     are there any plans for "locking" translations? especially ones that are coming from upstream, and only allowing the ones that need to be customised?
[08:23] <danilos> however, it's still very much dependent on the project what base language they use
[08:23] <carlos> kalila: please, use #ubuntu-classroom-chat for the questions, I will paste them one by one, don't worry
[08:24] <danilos> for example, GNOME does use American English, but some other projects might not (I don't know them off the top of my head)
[08:24] <danilos> hope this clears it up about the language in use
[08:24] <danilos> carlos: next question, please :)
 danilos: QUESTION: How do you define a 'trusted translator'?
[08:25] <danilos> ok, this one is tricky, and doesn't have much to do with Launchpad
[08:25] <danilos> I generally trust community processes to determine who is a 'trusted translator'
[08:25] <danilos> That means that, over time, people become generally satisfied or dissatisfied with someone
[08:26] <danilos> Launchpad helps there with Karma counts, but that's not enough for proper conclusion
[08:26] <carlos> bullgard4: for instance in spanish team
[08:26] <carlos> we require two approved translators to validate the new member translations quality
[08:27] <carlos> before we actually accept him
 danilos: QUESTION: Why are the Feisty translations of Gnome so patchy in German? Some parts are in English, others in German, and I cannot recognize any regular pattern in it.
[08:27] <danilos> for this one, we'd need more details
[08:28] <carlos> yeah, and a bug report so we can debug it
[08:28] <danilos> there are several possible reasons: bad translation from package, bad translation using Launchpad, or a bug
 danilos: QUESTION: How do you secure that a translation is objectively of high standard and not prone to subjective preferences of one ore two translators in power?
[08:29] <danilos> but it's a problem, and if you've run into case like that, please report it either using answer tracker, or file a bug
[08:29] <danilos> ok, on to next question
[08:29] <danilos> again a hard one, and not really tied to Launchpad
[08:30] <danilos> we simply don't secure that, but again trust community processes which have given us the most of free software and their translations so far
[08:30] <carlos> bullgard4: if you think there is any abuse on people approving translators, you can always use Ubuntu mechanisms to resolve conflicts
[08:31] <carlos> abuse of having extra rights or permissions is against Ubuntu CoC
[08:31] <danilos> since we don't have native speakers for all of Worlds languages, we simply cannot ensure quality of translations ourselves
[08:31] <danilos> but if enough people complain about people in power, that should be a good indicator that they are doing a bad job, and we can fix that
 danilos: QUESTION: How can a rank-and-file Ubuntu user contribute to an improved translation without being admitted to the elusive circle of admitted Ubuntu tranlators?
[08:33] <danilos> like some other free software projects, Ubuntu seems to be meritocracy: you are valued as much as you contribute
[08:33] <danilos> when you start, you start by giving out suggestions
[08:34] <danilos> then you ask already 'trusted translators' to review your translations
[08:34] <danilos> and they'll have a few suggestions to comply with glossary, terminology, etc.
[08:34] <danilos> or they'll be extremely satisfied
[08:34] <danilos> and once you contributed enough, they'd probably welcome you to the team, having gotten trust in you
 QUESTION: ok, let me get this out of the way :)     are there any plans for "locking" translations? especially ones that are coming from upstream, and only allowing the ones that need to be customised?
[08:36] <danilos> We have not planned locking translations yet, but we have planned making it easier to roll back to translations coming from packages (which are usually almost exactly like upstream :)
[08:36] <danilos> There are several things we plan to do to make this happen
[08:36] <danilos> First thing we'll do is provide filter on translation pages to look only at strings which are changed from upstream
[08:37] <danilos> and another is to provide a PO file download which includes only such changed translations (so you can easily merge them with upstream PO files)
[08:37] <danilos> We'll consider allowing locking translations as well
[08:38] <danilos> but not in the short term
 QUESTION: How will the translation teams initially form? (So they have the ability to let others in.)
[08:38] <danilos> I am glad we are getting this many questions on translation teams: proper organisation is key to good work
[08:39] <danilos> In practice, translation teams form from one person who is devoted and dedicated to working on translations for a language
[08:39] <danilos> well, one or a couple
[08:39] <danilos> only "larger" languages (I won't define 'larger', but you can guess what I mean) don't have a problem finding enough translators
[08:39] <danilos> those initial members usually grow out to be team leaders
[08:40] <danilos> and they need to be diplomatic and constructive in their work, ready to change courses, and welcoming to new members
[08:40] <danilos> if they are not, they risk staying the only members in the long run
[08:40] <danilos> of course, proper knowledge of English and language they translate to is very useful
[08:40] <danilos> and how they organise effort is important, but there are many right ways to do it
 QUESTION: In my country most of thie translation job is done in KDE or GNOME groups and people from several different distros work there. So translated GNOME applications are used both for Ubuntu and other distros, KDE both for Kubuntu and others. Some applications such as Firefox and OpenOffice have their own teams. Now, won't it create a conflict and mess if we begin to do some translations under Launchpad?
[08:41] <danilos> (I know successful teams who have used mailing lists, others who used bug trackers, web pages, CVS/SVN, or something entirely different for organising themselves)
[08:42] <danilos> There is indeed risk for conflict
[08:42] <danilos> but we try to ensure it's minimal
[08:42] <carlos> we ask translators to coordinate with them and send them back changes done in Rosetta
[08:42] <danilos> We are generally using stable releases of most software in Ubuntu, which already have their translation work finished
[08:43] <danilos> but other than that, we hope Ubuntu translators are able to coordinate with them, as carlos said
[08:43] <carlos> the main problem we try to solve is that once GNOME does a release
[08:43] <carlos> the don't release new translations after a couple of months
[08:43] <danilos> we can also suggest people to use Launchpad for translations for upstream projects, and they can contribute their translations back upstream (i.e. it can work the other way as well)
[08:44] <carlos> but we could have that version around for 2 more years
[08:44] <carlos> so we allow Ubuntu translators to have a full translated GNOME/KDE for all that time
[08:45] <danilos> the main advantage of Launchpad is that it allows you to have almost real-time updates to translations as translators do them
[08:45] <danilos> well, not the main advantage, but one of advantages :)
[08:46] <carlos> and final question (we have more time, so feel free to ask more on #ubuntu-classroom-chat)
 danilos: QUESTION: Do make available International Standards (e. g. of ISO) to translators in order to improve the quality of tranlations?
[08:47] <danilos> I don't understand what is meant with this question
[08:47] <carlos> bullgard4: could you give us more details about it?
[08:47] <danilos> ok, so bullgard4 explains
 A tranlator who is knowleadgable will deliver better tranlations.
 ISO takes care of terminology also.
[08:48] <danilos> ISO terminology is usually limited to English (and French, sometimes)
[08:49] <danilos> what translators usually need to turn to is *national* standards, not international ones
[08:49] <bullgard4> yes of course, they are important.
[08:49] <danilos> national and linguistic standards provide good reference for translators
[08:50] <danilos> knowing international standards is useful when translating specific applications
[08:50] <carlos> ok, we got another question:
 QUESTION: Does it give any harm to the process if I translate an application "very partially", online via Launchpad. I mean; I have 15 minutes today, do some; 2 hours next week... and so on.
[08:51] <danilos> no, not at all: this is a big advantage of Launchpad way of doing translations
[08:51] <danilos> it's designed specifically to allow such workflow
[08:51] <danilos> it can even be several people translating bit by bit
[08:52] <danilos> of course, when several people are doing it, it's important to have standard terminology and style guide
[08:52] <danilos> but that's something you organise and coordinate inside your team
[08:52] <carlos> next one,
 QUESTION: what about languages not using english character set ? e.g. hindi ? is it just as easy to translate ? do i put the translated strings using copy paste or so ?
[08:53] <carlos> well
[08:53] <danilos> rohan: I must admit that I don't know much about hindi input
[08:53] <danilos> so, I'll let carlos take this one over
[08:53] <carlos> the good think about Launchpad is that we are not directly and editor
[08:54] <carlos> so we rely on your web browser
[08:54] <carlos> if your web browser/system supports it, Launchpad does too
[08:54] <carlos> we already implement the required tags to control text direction
[08:55] <carlos> based on the language the user is translated into, the rest should be supported by your computer
[08:56] <carlos> ok, seems like there is no other questions
[08:56] <danilos> any more questions folks? if we missed something, you've got 5 more minutes, or you can catch us regularly on #launchpad
[08:56] <carlos> we still have 4 minutes
[08:56] <carlos> :-)
[08:56] <danilos> yes, 4 :)
[08:56] <danilos> ok, so no questions
 carlos: QUESTION: any ETA for the search feature in rosetta? ;)
[08:57] <carlos> that's more a question for danilos, he's working on that task
[08:57] <carlos> but I don't think we have an ETA yet
[08:57] <carlos> we started with that task
[08:58] <carlos> we hope to finish it soon, but we don't know exactly when
[08:58] <danilos> I am very bad at giving ETA's, so I can't give it out for you... It won't happen in a month since we've got other important things to work on
[08:58] <pochu> now that you're three in the team, you should get it soon ;)
[08:58] <danilos> but it's one of major things we know everybody is interested in (and so are we)
 danilos: QUESTION: Some translators are proud that their translations are better than those of M$. Do you agree?
[08:58] <danilos> pochu: yeah, having help from jtv is very welcome :)
[08:59] <danilos> I indeed agree. I can positively say that Serbian translations of Ubuntu/GNOME/OpenOffice are better than Microsoft translation of Windows
[08:59] <danilos> :)
[09:00] <danilos> However, note that MS is indeed lacking in i18n framework in several places
[09:00] <carlos> ok, we ran out of time
[09:00] <danilos> like plural forms support
[09:00] <carlos> danilos: thanks for driving this session
[09:00] <carlos> and thanks for coming !!
[09:00] <danilos> thanks everybody, I'll stick around -chat for a few minutes as well
[09:00] <carlos> and remember, we are always around at #launchpad
[09:01] <carlos> BjornT: the channel is all yours
[09:01] <BjornT> thanks carlos
[09:01] <BjornT> PriceChild: could you please give bdmurray +o as well?
[09:02] <BjornT> Ok, so let's start this session about triaging bugs with Launchpad.
[09:02] <BjornT> I'm Bjorn Tillenius, the lead developer of the bug tracking part of Launchpad.
[09:03] <BjornT> This session will be more or less a repeat of the previous one on Monday, but I'll be giving more priorities to questions, trying to answer as many as possible.
[09:04] <BjornT> Also, this time Brian Murray (bdmurray) from the Ubuntu BugSquad is here to help me answer questions.
[09:05] <BjornT> At least he should be joining us shortly.
[09:05] <bdmurray> Yes, hello.
[09:05] <BjornT> Cool.
[09:05] <BjornT> For those of you that don't already know, Launchpad (https://launchpad.net) is a web application for managing software projects, i.e. it provides bug tracking, feature tracking, code hosting, and more.
[09:05] <BjornT> A lot more could be said about Launchpad. If you're intested in knowing more, mrevell gives an introduction to Launchpad tomorrow.
[09:06] <BjornT> First of all, let's define "triage", since it's not a commonly used word. The
[09:06] <BjornT> dictionary defintion is:
[09:06] <BjornT>     1.   the process of sorting victims, as of a battle or disast er, to determine medical priority in order to increase the number of survivors.
[09:06] <BjornT>      2.   the determination of priorities for action in an emergency.
[09:07] <BjornT> When I talk about triaging here, it has a slightly different meaning, though. :) It involves prioritisation of bugs, but more importantly it means to prepare the bug reporter for a bug fixer, so that he can focus on what he can do best.
[09:07] <BjornT> Now, let's talk about getting started with triaging bug.
[09:07] <BjornT> Triaging bugs is a great way of getting involved with a project. It doesn't require that you know how to code, and pretty much anyone can learn how do it.
[09:07] <BjornT> Doing this session actually made me realize that it can be quite hard to know how to get involved with triaging bugs, but don't let that put you off!
[09:08] <BjornT> If you just contact the right people, they will most of the time be happy that you want to help, since that can improve the experience for their bug reporters.
[09:08] <BjornT> Do contact someone related to the project before triaging bugs, though. Each project has their policy of how to triage bugs, and it might not be that well documented. It's important to have a good dialog, so that you know that you are triaging correctly.
[09:08] <BjornT> As a bug reporter, you want that someone cares about your bug report, so having bug triagers that can reply promptly to new bug reports is a great asset for a project.
[09:09] <BjornT> By triaging bugs you'll also help the developers focus more on bug fixing, and less on talking.
[09:09] <BjornT> There are a few different ways you can triage bugs; some require more knowledge and authority than the others.
[09:09] <BjornT> I'd say the two most common meanings of triaging are:
[09:09] <BjornT>     - making sure that the bug report contains enough information
[09:09] <BjornT>      - prioritize the bug
[09:10] <BjornT> The latter can be quite difficult to do, and it requires that you are trusted by the project, so i'll be concentrating on the first point, which basically means to make the bug report good enough so that more experienced people can prioritize and fix the bug.
[09:10] <BjornT> So, what kind of information should the bug report contain?
[09:10] <BjornT> Basically it should contain enough information so that someone could reproduce the bug, and it should also clearly state what the actual bugs is.
[09:11] <BjornT> i.e., it should contain the answers to the following questions:
[09:11] <BjornT>     - what did you do?
[09:11] <BjornT>      - what happened?
[09:11] <BjornT>      - what did you expect to happen?
[09:11] <BjornT> But this is not the only information that is needed;  each project have their set of requirements and guidelines as to what exactly a bug report should contain.
[09:11] <BjornT> So before starting to triage bugs for a project, you should get in contact with the people that are dealing with bugs within the project.
[09:11] <BjornT> Your best bet is usually to look at who's the designated "Bug Contact"
[09:11] <BjornT> of the project, find them on IRC or drop them an e-mail.
[09:12] <BjornT> Since this is *Ubuntu* Open Week, let's take Ubuntu as an example. Note that most of the things I will talk about here apply to any project using Launchpad, not just Ubuntu.
[09:12] <BjornT> If you look at https://launchpad.net/ubuntu you can see that the 'Ubuntu Bugs' team is the bug contact. If you follow that link to https://launchpad.net/~ubuntu-bugs, you can see that you shouldn't join that team, though!
[09:13] <BjornT> The ubuntu-bugs team is used mostly to get all the bug notifications sent to a mailing list.
[09:13] <BjornT> On the same page you can see that the Ubuntu QA Team is listed as the owner, so if you'd follow that link you'd be pointed to the Ubuntu BugSquad, which is that team that deals with bugs in Ubuntu.
[09:13] <BjornT> https://wiki.ubuntu.com/BugSquad contains all information you need to join the team and start triaging Ubuntu bugs. Don't be shy, they will appreciate any help you can give them. :) They usually hang out in #ubuntu-bugs here on freenode.
[09:13] <BjornT> But don't go off reading all that information just yet, though, since it would take most of this session. Instead I will talk a bit about triaging bugs here.
[09:14] <BjornT> So, now that we know who we should talk to about triaging bugs, we can talk about picking which bugs to triage.
[09:14] <BjornT> If you look at https://bugs.launchpad.net/ubuntu you can see that there's a great deal of Unconfirmed bugs. It's those bugs that you want to turn to either Confirmed or Rejected.
[09:15] <BjornT> Confirmed basically means that the bug report contains enough information for someone to fix the bug, and Rejected means that it's not really a bug, for example, it could be a support request disguised as a bug report.
[09:15] <BjornT> When you triage bugs, you start to have a conversation with the bug reporter. This is important work, since it gives the bug reporter someone to talk to, and it shows him that someone does care about his bug report.
[09:16] <BjornT> Be sure to be polite to the reporter, though :), we don't want him to get a bad impression of the community.
[09:16] <BjornT> In order to avoid more than one people triage the same bug, it's a good idea to assign the bug you want to triage to yourself. This gives you a list of bugs you need to pay extra attention to at https://launchpad.net/people/+me/+assignedbugs.
[09:16] <BjornT> Assigning the bug to yourself also makes it easier for triager to find bugs you want to triage, since you can exclude bugs that are assigned to someone.
[09:17] <BjornT> To find bugs to triage, you can go back to https://bugs.launchpad.net/ubuntu and click on the "Advanced search" link, which will allow you to filter the bug listing in a great number of ways.
[09:17] <BjornT> In Ubuntu, bugs are considered untriaged if they are Unconfirmed, have an Undecided importance, and doesn't have an assignee.
[09:17] <BjornT> So you should make sure that no other statuses or importances are checked, as well as making sure that "Nobody" is specified as the assignee.
[09:18] <BjornT> After you've done this and clicked on "Search", you probably want to bookmark that page.
[09:18] <BjornT> When you have the list of bugs, it's a good idea to open each bug you want to triage into a new browser tab. That makes it easier to get back to the bug listing after you're done with the bug.
[09:18] <BjornT> Now, let's talk about how you actually triage a bug report that you've found.
[09:18] <BjornT> First, you should read through the bug report and make sure that you understand what the bug report is about. If it's unclear, ask the reporter to clarify.
[09:19] <BjornT> When you ask the reporter something, you should set the status to "Needs Info", so that the reporter (and you) knows that action is required from him.
[09:19] <BjornT> Sometimes the bug reporter doesn't respond, so if a bug in "Needs Info" hasn't gotten a reply for a while, it's usally a good idea to Reject the bug, since it can't be fixed without knowing more about the problem.
[09:20] <BjornT> Now, it might not be completely obvious how to change a bug's status, so I'll better tell you how to do it :).
[09:20] <BjornT> You change the status of the bug by clicking on the package name (e.g.  "amule (Ubuntu)"), which will expand the edit form, where you can edit things like status, assignee, and package name, and you can also leave a comment while editing.
[09:21] <BjornT> Anyone is allowed to edit the status of a bug, you don't need any special privileges.
[09:21] <BjornT> Now, let's get back to actually triaging the bug.
[09:21] <BjornT> There are a number of different things you can to do. A good first step is to try to reproduce the bug. If you don't know what steps are necessary, you should ask the bug reporter for more information.
[09:22] <BjornT> Now, after he's given all the information, it will be there in the comments. But sometimes there are a great number of comments in a bug, so the needed information can be hard to find there.
[09:22] <BjornT> So, to make it easier to find, Launchpad allows you to edit the bug description, by clicking on the "Edit description/tags" link in the action menu to the left.
[09:23] <BjornT> Moving the important information to the description will make it much easier for the next person looking at the bug to understand the bug.
[09:23] <BjornT> The next thing you should do is to try to decide whether the bug is filed under the correct source package. In Launchpad bugs are associated with source packages, not binary packages, and it can be hard for people to know on which package to file the bug on.
[09:24] <BjornT> If a bug doesn't have a package at all, or an incorrect one, it could lead to the bug not getting looked at by the people that should.
[09:24] <BjornT> Also, each package generally have few different guidelines as to what information a bug should contain, and it narrows down the scope of possible duplicate bugs.
[09:25] <BjornT> You can change/set the source package on the same form as editing the status, which is expanded by clicking on the package name on the bug page. You can find more information about finding the right source package at https://wiki.ubuntu.com/Bugs/FindRightPackage.
[09:25] <BjornT> Let's break for a quick question.
[09:26] <BjornT>  < zorglu_> q. is there some kind of voting system ... i mean something
[09:26] <BjornT>                  which say 1 people reported this bug but 300 others have seens
[09:26] <BjornT>                  it as well ?
[09:26] <zorglu_> it was more for -chat, but ok :)
[09:26] <BjornT> no, there's no such voting system.
[09:27] <BjornT> but you if someone experiences a bug, he might subscribe to the bug, so you can look at how many duplicates and subscribers a bug has.
[09:28] <BjornT> < Belutz> QUESTION: should we triage bugs for the recent release? or all. release that is still supported?
[09:28] <BjornT> bdmurray: can you answer that one?
[09:28] <bdmurray> For all releases that are supported should be triaged.  However, it is possible that something might be fixed in Feisty and not get backported to Dapper or Edgy.
[09:29] <bdmurray> It is also possible to find bugs about unsupported releases for example Breezy in launchpad.
[09:29] <BjornT> < dcomsa> <question> what are the conditions to be met, so that a. developer will have a look at a bug report?
[09:30] <BjornT> In general, if a bug is Confirmed and have an importance set, it should be good enough for a developer to look at.
[09:30] <bdmurray> The information needed for a developer to be successful is dependent on the package the bug is in.
[09:31] <BjornT> < Belutz> QUESTION: so if i use feisty now, i can't reproduce bugs that. happened in dapper/edgy so I should leave those bugs to other. people to triage?
[09:31] <BjornT> bdmurray: ^^^
[09:32] <bdmurray> To a degree.  It is still possible to gather the right information for a bug that happens in Edgy or Dapper you just may not be able to verify or reproduce it.  Furthermore you could help find duplicates for Dapper and Edgy without running it.
[09:33] <BjornT> Ok, let's continue with the session. There'll be more time for questions later.
[09:33] <BjornT> After you decided that the source package is correct, you can start to search for similar bug reports, to see if the bug has already been reported before.
[09:33] <BjornT> You should start by going to the package's bug listing, which you can reach by expanding the edit form by clicking on the package name, and then click on the package name next to "Affecting:" to the right in the edit form.
[09:33] <BjornT> It's good to open this page in a new browser tab, so that you can easily return to the bug report.
[09:33] <BjornT> On the package bugs page, e.g.  https://bugs.launchpad.net/ubuntu/+source/amule, you can search for bugs that are reported on the amule package. The search will include all the bug reports that include the search words that you specify.
[09:34] <BjornT> If you found a bug report that is about the same bug as the report you are triaging, you can go back to the latter and indicate that it's a duplicate bug by clicking on "Mark as duplicate" and enter the id of the bug you've found.
[09:35] <BjornT> It can be hard to identify duplicate bug sometimes, though. The important thing is that the root cause is the same. Sometime two different bugs can appear to be the same, but have different root causes.
[09:36] <BjornT> e.g., two different bugs could cause the error message "An error occured" to be printed out.
[09:36] <BjornT> Now, if the bug isn't a duplicate, you can continue making sure that the bug report contains enough information so that a developer can debug what's wrong, ideally without having to request more information for the bug reporter.
[09:37] <BjornT> The most common thing is to ask the user what version of the related packages he's using. The reporter might not know how to get at this information, so be prepared to tell him how to do it.
[09:37] <BjornT> Apart from the general version information, each package, or subsystem has their own set of information they want a bug report to contain. For example, bugs involving a USB printer should contain a list of loaded usb modules, as well as some specific log output. The BugSquad can tell you more about this.
[09:38] <BjornT> Now, since each part of a project is different, it can makes sense to focus on a specific part. This is especially true for large projects like Ubuntu. For example, in Ubuntu you could choose to focus on printing bugs, desktop bugs, firefox bugs, etc.
[09:39] <BjornT> Focusing on a smaller set of bugs gives you an opportunity to learn more about it, so that you, after a while, can do more advanced triaging, and maybe even fix bugs yourself.
[09:40] <BjornT> There are usually teams you can join if you want to focus on some specific kind of bugs.
[09:40] <BjornT> Let's break for some more questions.
[09:41] <BjornT> < habeeb> QUESTION: Right now I'm using a distro other than Ubuntu. Can I. still help on the bug triaging? What would you suggest to be. sure that I don't mess up stuff?
[09:41] <BjornT> bdmurray: ^^^
[09:42] <bdmurray> Frequently bug reports come in without all the necessary information to recreate the bug.  So you could still ask questions to make sure the right information is gathered.  We have a list of standard response at https://wiki.ubuntu.com/Bugs/Responses
[09:42] <BjornT> < bullgard4> BjornT: QUESTION: I have started Ubuntu 7.04 Herd4 and when. it announced a crash I would file it to the uggested. channels. Usually I could only add some circumstances under. which the error occurred. I noticed some answers I've got.. But more I could not contribute, I'm afraid. Is this still. helpful?
[09:42] <BjornT> bdmurray: ^^^
[09:44] <bdmurray> It sounds like you were using apport to report a crash and yes the information it reported was helpful.  However, it is best to have the circumstances around the crash reported.
[09:45] <BjornT> Ok, let's finish off with talking a bit about more advanced triaging, which you can do when you are a bit more experienced.
[09:45] <BjornT> One example of more advanced triaging is forwarding bugs to other projects.
[09:45] <BjornT> Most of the time, the bugs reported on Ubuntu, aren't bugs in the actual packaging of the software, but a bug in the software itself, which is better fixed by someone else.
[09:45] <BjornT> In this case Launchpad allows you to link bug to the other software's bug tracker. For example, if you look at https://bugs.launchpad.net/ubuntu/+source/abiword/+bug/6710 you can see that there are two abiword rows in the "Affects" table, one (upstream), and one (Ubuntu).
[09:46] <BjornT> The abiword (upstream) one is linked to bug #6857 in abiword's real bug tracker, and when that bug change its status, Launchpad will send a notification it, so that the Ubuntu developer fixing the bug may choose to pull in the upstream fix.
[09:47] <BjornT> You can create such an (upstream) row by clicking on the "Also affects: +Upstream..." link. There you will first get prompted to enter the name of upstream project.
[09:47] <BjornT> Launchpad does have some knowledge of which upstream project corresponds to which Ubuntu package, so sometimes you don't have to specify anything at all, and can simply continue linking to the external bug report.
[09:48] <BjornT> However, if Launchpad doesn't know which project you want to link to, you have to specify the name yourself, and sometimes you even have to register it in Launchpad.  Registering projects in Launchpad for this purpose is ok to do, even if you aren't associated with that project.
[09:49] <BjornT> When doing this it's good to be aquinted with upstream project. You should always try to be a good upstream community citizen, which will help Ubuntu.
[09:50] <BjornT> < Belutz> QUESTION: how do we know that the bugs also affect upstream?
[09:50] <BjornT> bdmurray: ^^^
[09:52] <bdmurray> That's a good question.  Some of it is knowing how different Ubuntu's code base for a pacakge is from upstreams.  Part of it is also looking to see if the bug has already been reported upstream.  Another way to find out would be to ask the packager of the product for Ubuntu.
[09:53] <BjornT> < RainCT> QUESTION: How can I set that a bug is affecting many Ubuntu. version?
[09:54] <BjornT> You can do this by clicking on "Also affects:... +Distribution"
[09:55] <bdmurray> That is not releases of Ubuntu though.
[09:55] <BjornT> That page is used both for saying that a bug affects another distribution (e.g. Debian), as well as saying that it affects another source package.
[09:55] <BjornT> oh, wait, misread the question :_
[09:55] <nevermind_> QUESTION: having timeouts with irq on using synaptics touchpad on my acer travelmate 250, running latest stable ubuntu
[09:56] <nevermind_> had same prob with all linux distris so far, on the web there are a few bootloader tricks, that didnt do for me
[09:56] <BjornT> bdmurray: maybe you'd like to answer how you deal with bugs affecting more than one ubuntu version? do you care about it?
[09:56] <nevermind_> tried kernels: 2.6.1x, 2.6.0x, 2.4.x, 2.2.x
[09:56] <nevermind_> and 2.6.20
[09:56] <bdmurray> That sounds like a specific bug question and should be asked in #ubuntu-bugs
[09:57] <nevermind_> still seems to have the problem, sadly
[09:57] <nevermind_> ok, thx for the tip)
[09:58] <bdmurray> For bugs affecting more than one version of Ubuntu it is dependent on the severity of the bug as to whether or not it will be fixed in a previous release.  If a bug is filed on a specific package it is understood that it affects all versions with that version of the package.
[09:58] <bdmurray> all releases rather
[09:58] <nevermind_> well, its not exactly a ubuntu problem
[09:58] <nevermind_> id say its a kernel thing
[09:58] <nevermind_> )
[09:59] <nevermind_> tried with ubuntu's own, and build my own stock packages too, same result
[10:00] <BjornT> Ok, I think it's time to let the next session begin. Thanks for listening.
[10:00] <BjornT> To remind you, if you want to start triaging Ubuntu bugs (you really should give it a try), read https://wiki.ubuntu.com/BugSquad and https://wiki.ubuntu.com/Bugs/HowToTriage.
[10:01] <bdmurray> And feel free to ask me questions in ubuntu-bugs
[10:01] <Belutz> BjornT, bdmurray thanks for a great session
[10:01] <jenda> Hello :)
[10:02] <jenda> I'm Jenda, and I'll be presenting the Marketing Team in this session
[10:02] <jenda> Although I'll be leading this session, the Marketing Team itself (MT) does not have a leader.
[10:02] <jenda> I'll return to the actual structure of it later.
[10:03] <jenda> I'm hoping some other marketing team folks will appear and drop in a few words about their individual projects.
[10:03] <jenda> Jono mentioned earlier that I might be talking about marketing...
[10:03] <jenda> ...don't be fooled, I know nothing about marketing ;)
[10:04] <jenda> I'll be talking about Ubuntu's marketing _team_.
[10:04] <jenda> I'm still hoping others, more qualified in actual marketing, will appear later on :)
[10:05] <jenda> The MT's most interesting attribute, I'd say, is that it's an area in Ubuntu where even the least technical of us (of you, too) can contribute.
[10:05] <jenda> (By the way, feel free to interrupt me at any time with questions)
[10:06] <jenda> The Marketing Team is a group of loosely knit projects, which are listed at http://wiki.ubuntu.com/MarketingTeam
[10:06] <jenda> The most obvious shortcoming of not having a team leader is that nobody is responsible for that page being up to date ;)
[10:07] <jenda> And nobody but the actual project members will usually dare mark a project 'inactive'.
[10:08] <jenda> The MT is a purely community effort, there is little or no contact with Canonical's professional Marketing - save occassional consultation.
[10:08] <jenda> (us consulting them, I'd say, is more common ;))
[10:09] <jenda> This means the MT has no budget or formal existence - and thus can't and doesn't actually participate in professional marketing per se.
[10:09] <jenda> What the MT focuses on is what the community does best: grassroots marketing.
[10:10] <Richard> Is there a meeting currently in place?
[10:10] <jenda> Richard: kinda ;) see #ubuntu-classroom-chat
[10:11] <jenda> Currently, what the MT is doing, what I think it should be doing, and what it probably could be doing are three largely disjunct categories.
[10:11] <jenda> (well, no the latter two are actually nearly identical ;))
[10:12] <jenda> The MT's only truly active projects are the Ubuntu Weekly Newsletter (you all read that, don't you? Don't you??) and the Fridge, which likes to distance itself a bit from the MT itself.
[10:13] <jenda> There is also the ubuntu counter.
[10:13] <jenda> These three projects all have one thing in common:
[10:13] <jenda> They focus within the community.
[10:14] <jenda> The UWN does a _great_ job of keeping the community up to date of itself.
[10:14] <jenda> The Fridge fulfills a similar role, in a slightly different style.
[10:15] <jenda> Experience has shown that (IMO, at least) these two are not mutually redundant and each has their place.
[10:15] <jenda> But they can hardly be considered Marketing Projects.
[10:16] <jenda> (In the FLOSS world, I imagine marketing as raising public awareness of the existence, benefits and malefits of (the particular piece of) FLOSS, it's promotion and advocacy.)
[10:16] <jenda> The counter is clearly only of interest to us, members who like being counted.
[10:17] <jenda> The Joe User does care about how many people use Ubuntu, of course, but he cares more about "We estimate 5-8 million users" than "We have reliably counted 20,000 users..."
[10:18] <jenda> In this line of thought, I'll admit that my own project within the MT, DIY Marketing, also focuses mainly on existing community members as is, and even when complete will still be of more interest to them than to non-users.
[10:19] <jenda> I'll get to the details of the project towards the end of the sesion.
[10:19] <jenda> *ss
[10:20] <jenda> The pattern I described is, I believe clear: it's immensely easier to work for a target audience within the existing community than the TA without.
[10:20] <jenda> From this I conclude - we should focus on the latter ;)
[10:21] <jenda> My personal opinion (and observation) is that the only _real_ marketing, as described above, can be done by LoCo teams.
[10:21] <jenda> Only the LoCo teams are close enough to the target audience (TA) to be able to appeal to it.
[10:22] <jenda> This doesn't mean there is no place for the MT to do its work
[10:23] <jenda> It means it needs to adjust its work, taking the above into account.
[10:23] <jenda> This allows us to split marketing efforts into two basic categories
[10:24] <jenda> The first category would be activities done by LoCos
[10:25] <jenda> This includes Press Relations, RL fests, conferences and expos, face-to-face advocacy etc.
[10:26] <jenda> The other category includes marketing efforts that are targeted towards the global audience, and I personally believe this category to be nearly empty.
[10:26] <jenda> It might contain stuff like web advertisements.
[10:26] <jenda> They do not require further attention, I think.
[10:27] <jenda> So, if category #2 is negligeable, and category #1 is better suited for LoCos... what can the MT do?
[10:27] <jenda> That is the question ;)
[10:27] <jenda> The answer is: a lot of the work the locoteams do will have to be replicated by other locoteams in order to achieve the same result.
[10:28] <jenda> This means, a lot of effort can be saved by them either sharing their work, or someone (hint: MT) to predict their needs and cater to them, centrally.
[10:30] <jenda> My focus within the team, and my vision for the entire team is just that - it should provide resources for the LoCo teams to use.
[10:31] <jenda> I find it remarkable how close this envisioned role gets to the only role the MT manages to fulfill to date (which is of intra-community communication)
[10:32] <jenda> I ran out of words for the MT's role, I hope what I had to say was understandable :) I'll now move on...
[10:32] <jenda> I said I'd get back to the structure of the MT.
[10:33] <jenda> The MT is quite simply composed of individual projects, who's sub-teams overlap.
[10:34] <jenda> There is rarely a need to decide for teh entire team, and when there is, it is decided by consensus or simply acquiesced.
[10:34] <jenda> (I'm sure I spelt that wrong :))
[10:35] <jenda> Most notably, the decisions we make for the entire team are times of meetings. It's usually one of teh MT members who write them out, and unless there's a complaint from someone who really has something to say at the meeting, it usually stays at that.
[10:35] <jenda> I'll now move on to the individual projects.
[10:36] <jenda> I'm not sure if there are any of the MT folks here who'd like to talk about theirs...
[10:36] <jenda> Going once... ;)
[10:37] <jenda> OK, beuno will now tell you a bit about the UWN
[10:37] <jenda> He has sent out the past few issues.
[10:38] <jenda> (sent out and largely made happen, i sohuld say ;))
[10:38] <beuno> Hi everyone, I'm Martin Albisetti and I've been the editor for the past (7 or 8 I think) issues. I'm probably a good example of what Jenda is trying to explain by how the Marketing Team works
[10:38] <jenda> hehe
[10:39] <beuno> the Ubuntu Weekly Newsletter was stalled, and I just picked it up, finished it and nagged people until it got released
[10:39] <beuno> so that's a good example of how you can get involved pretty quickly
[10:40] <beuno> the UWN is a great place to start since it doesn't require any prior experience in marketing or ubuntu itself
[10:40] <jenda> (In fact, it's what I did to the Marketing Team a little over a year ago ;))
[10:41] <beuno> there is a secret to it which I think we should advertise more, which is if you actually go on the wiki page (ie: https://wiki.ubuntu.com/UbuntuWeeklyNewsletter/Issue37), and you click on edit
[10:42] <beuno> you will see many comments on how to contribute to each specific section
[10:42] <PriceChild> (if you're logged in to the wiki with your launchpad account)
[10:42] <beuno> a lot of work has gone into making it as clear as possible
[10:43] <beuno> and as jenda mentioned, the main focus is keeping the community updated on what's been going on, so anything you *hear* might be useful
[10:44] <beuno> much of our material come from random emails in our mailing list and users on IRC mentioning specific topics or articles
[10:45] <beuno> right now the UWN is keeping up with a weekly release every sunday, which means a lot of presure on very few people, so if you're looking for something to help out with, you are more the welcome in UWN
[10:47] <beuno> a great way to help out is to hang around in #ubuntu-marketing and ask what needs to be done this week, as simple as that
[10:47] <beuno> another effort that has been going on the past few issues is translating the UWN
[10:48] <beuno> since the goal is to keep as many users as possible informed, we want it to be available in as many languages as possible
[10:49] <beuno> my very rough estimate is that it's being translated into 5 or 6 languages on a weekly basis, which is a lot considering how often it's released
[10:50] <beuno> again, translations, like the rest of the projects in the MT has a "just do it approach"
[10:50] <beuno> login to the wiki, create a new page for the translation, and get it done
[10:51] <jenda> (not all projects have that approach!)
[10:51] <beuno> some translations are done through LoCo groups, some are done individually, and it even changes every week
[10:51] <beuno> right, sorry, not all projects have that approach
[10:52] <beuno> but there are many areas where you can help out without necessarly participating actively in the marketing team (although that does help)
[10:53] <jenda> beuno: shhh ;)
[10:53] <jenda> beuno: anything else about the UWN?
[10:53] <beuno> not unless someone has a question
[10:53] <jenda> I was about to move on to my own DIY project, but I'll pass as we are running short on time.
[10:54] <jenda> You can read pretty much all I have to say about DIY on wiki.ubuntu.com/MarketingTeam/DIYWebsite
[10:54] <jenda> I believe now's a good time for any questions you might have :)
[10:54] <zorglu_> q. have you guys already tried to provide extension which are not the pex one (with the extension protocol i mean) ? i may try to make one but im afraid of the compatibility with other. even if the spec says it is ok, this is unusual so may trigger bugs in remote implementation
[10:54] <jenda> If you don't get them answered here and now, feel free to come into #ubuntu-marketing at any time and ask there.
[10:54] <zorglu_> argg wrong cutpaste
[10:55] <jenda> zorglu_: entirely OT
[10:55] <jenda> kk
[10:55] <zorglu_> QUESTION: any plan to produce a study on how to make a living from opensource ? (more people paid to do opensource means more people doing that full time, so a lot more contribution)
[10:55] <jenda> ANSWER: no
 QUESTION: for offline marketing, do you to use your own money or someone paid for it?
[10:56] <jenda> zorglu_: please ask in #ubuntu-classroom-chat
[10:56] <jenda> zorglu_: Personal gain is of no concern to the Marketing Team.
[10:56] <jenda> Belutz: I use my own money.
[10:57] <mc44> (except for jenda's profit margin)
 QUESTION: is full circle magazine also a marketing team project?
[10:57] <jenda> Belutz: however, I've managed to use it effectively, so as to earn a certain 'fund' from which I can draw
[10:57] <jenda> mc44: :)
[10:57] <jenda> Belutz: it's been communicating with the Marketing Team, and it's very much supported. But it has never explicitly declared itself as such to my knowledge.
 QUESTION:  I often end up touting Ubuntu to friends and family members, but when it comes down to actual argumentation vs. other options (Windows), I find I lack a lot of reasons to give (I know that I prefer linux/Ubuntu...);  Are there any resources out there to help learn how to promote effectively?
[10:58] <beuno> Belutz: some members from the Marketing Team participate in it, but it was started (and is run by) from someone outside the team
[10:58] <PriceChild> arg I'm rubbish tonight :)
[10:59] <jenda> BHSPitMonkey: there is whylinuxisbetter.com :)
[10:59] <jenda> BHSPitMonkey: it's maintained by an Ubuntu person, but it's general in nature.
[10:59] <beuno> jenda: that link doesn't seem to be correct
[10:59] <jenda> BHSPitMonkey: That would be a very useful section of the DIY project's HOWTO section
[11:00] <jenda> beuno: It's correct when I say it's correct ;)
[11:00] <BHSPitMonkey> ( .net )
[11:00] <jenda> sorry, it could also be whyislinuxbetter.com or .net or something ;)
[11:00] <jenda> BHSPitMonkey: thansk ):
[11:00] <jenda> ehm
[11:00] <jenda> *thanks :)
 QUESTION: any suggestion for promoting ubuntu to companies/schools/governments?
[11:00] <jenda> BHSPitMonkey: so, to answer the question clearly - not yet for Ubuntu in particular
[11:01] <jenda> Belutz: Didn't I say I knew nothing about marketing?
[11:01] <jenda> Belutz: I have one
[11:01] <jenda> Belutz: Get your LoCo team interested, and make it come up with a plan.
[11:02] <beuno> Belutz: the argentina LoCo, for example, is installing Ubuntu in an installfest tomorrow
[11:02] <jenda> Once that happens - the MT would be very interested in the results and process, and might publish info on it for other LoCos to draw upon.
[11:02] <jenda> Belutz: Your LoCo is _bound_ to have many talented and qualified people in it who can answer that question on teh local scale much better than I..
[11:03] <jenda> Any more questions?
[11:04] <PriceChild> Thanks very much jenda :)
[11:04] <jenda> I take that as a 'no' :)
[11:04] <jenda> Thanks for your attention.
[11:04] <mikesown> were you talking about MOTU?
 QUESTION: Is there any updated ODP presentation for Ubuntu project and I can take and give a presentation with at my LUG?
[11:04] <habeeb> Marketing.
[11:04] <PriceChild> jenda, one last one ^
[11:04] <mikesown> ah, ok
[11:04] <jenda> and thanks beuno for your help :)
[11:05] <jenda> tomtig: sorry, not that I know of.
[11:05] <jenda> tomtig: if you find one, as always, the MT is very interested :)
[11:05] <beuno> jenda, np.  and if anyone isn't sure on how to approach helping with UWN, feel free to contact me
[11:05] <jenda> (the DIY project more than anyone else)
[11:05] <PriceChild> imbrandon, You around? :)
[11:06] <Belutz> thanks jenda, thanks beuno :)
[11:06] <PriceChild> SCHEDULE: https://wiki.ubuntu.com/UbuntuOpenWeek - SCHEDULE CHANGES, PLEASE SEE THE TIMETABLE || RULES: https://wiki.ubuntu.com/UbuntuOpenWeek/Rules Please respect them || LOGS: https://wiki.ubuntu.com/MeetingLogs || Ask questions and chat in #ubuntu-classroom-chat, "QUESTION: <insert question here>/cs o || CURRENT SESSION: Kubuntu - Brandon Holtsclaw
[11:06] <jenda> Oh, and before I give way to imbrandon... you're all very welcome to hang around in #ubuntu-marketing, and if you have questions unanswered, you might get them answered there, too.
[11:06] <habeeb> Thanks for the session, jenda .
[11:06] <Riddell> PriceChild: he doesn't seem to be
[11:07] <PriceChild> Riddell, arg he wasn't around yesterday either :(
[11:07] <Riddell> mm, hope he's ok
[11:07] <Riddell> well I'm happy to take question
[11:07] <Riddell> questions
[11:11] <PriceChild> Ok this session is supposed to be taken by Brandon. However he seems to be afk and Riddell has offered to take his place. Do we have any questions? Could you introduce yourself Riddell?
[11:11] <Riddell> hi, I'm Jonathan Riddell
[11:11] <Riddell> I work on Kubuntu
[11:11] <Riddell> along with an excellent bunch of the coolest people you'll ever know
[11:11] <Riddell> who all have a 24 hour party on #kubuntu-devel
[11:12] <Riddell> with gusty open there's loads of merges to be done so if you're looking for an easy way to help out, that's very welcome
[11:13] <Riddell> any questions?
 QUESTION: i haven't tried kubuntu 7.04 is desktop effects also available in kubuntu?
[11:14] <Riddell> it's not on the CD and there's no tick box way to turn it on
[11:14] <Riddell> that's because compiz doesn't integrate with KDE yet
[11:14] <Riddell> and also because the proper way to do it is to wait for KDE 4
[11:14] <Riddell> which will have funky desktop effects built in
[11:14] <Riddell> http://www.kdedevelopers.org/node/2787
[11:14] <Riddell> however...
[11:14] <Riddell> beryl does have kde integration with aquamarine
[11:15] <Riddell> so you can install beryl and aquamarine and beryl-manager and beryl-kubuntu and get it working just lovely
[11:15] <Riddell> (I believe, I don't have any hardware that works with it myself)
[11:15] <nevermind_> ubuntu is amazing, and ive seen many gnu distributions in my life
[11:15] <Riddell> with beryl and compiz merging that will make it easyer for us to have a tickbox for turning on desktop effects
[11:16] <Riddell> so hopefully with gusty it'll be simple to do
[11:16] <auge> hi
 QUESTION: do you feel the need for any more paid developers on kubuntu? if so, what is the likelihood of more?
[11:16] <nevermind_> hi eye
[11:16] <Riddell> there's always a need for more developers
[11:17] <Riddell> that goes for any free software project (and I expect for proprietry software too, although I've never worked with any)
[11:17] <Riddell> one problem is that trolltech keeps hiring all the elite kde developers
[11:17] <Riddell> the ones that don't work for suse anyway
[11:17] <Riddell> canonical only hire the best developers
[11:18] <Riddell> but I'm keeping my eye out for elite KDE people who need a job and will encourage them to send CVs to canonical
[11:18] <auge> .oO(pay more money :))
[11:18] <nevermind_> QUESTION: how about teaching your own developers up from schools or colleges?
[11:18] <nevermind_> ahh
[11:18] <Riddell> nevermind_: #ubuntu-classroom-chat please
[11:18] <nevermind_> yea
[11:18] <Riddell> then PriceChild can feed it back here :)
[11:18] <nevermind_> on my way, sorry
[11:18] <nevermind_> )
[11:18] <jenda> < Tm_T> QUESTION: Will next LTS have KDE4 or still hold on "good old" KDE3 ?
[11:18] <jenda> Riddell: not him anymore ;)
[11:19] <Riddell> jenda: dunno, if next LTS is gusty+1 then I don't think KDE 4 will be read for LTS treatment
[11:19] <Riddell> if it's gutsy+2 then maybe, we'll have to see at the time
[11:19] <jenda> Riddell: Tm_T asked, not I ;)
[11:20] <Riddell> er, aye
[11:21] <Riddell> any more questions?
[11:21] <jenda> < nevermind_> QUESTION: how about teaching your own developers up from schools or colleges?
[11:22] <Riddell> nevermind_: I'm not sure I understand what you mean
[11:22] <jenda> nevermind_: feel free to rephrase the question here
[11:23] <jenda> hm, next, then
[11:23] <jenda> < xerosis> QUESTION: I appreciate, there's not even been a UDS yet, but what are your personal goals for inclusion in gutsy?
[11:23] <jenda> Riddell?
[11:23] <Riddell> well KDE 4 is due to be released shortly after gutsy, so I hope to be in a position to have a KDE 4 Kubuntu CD when 4.0 is out
[11:24] <jenda> k ;)
[11:24] <Riddell> also..
[11:24] <Riddell> improvements to adept to make it match synaptic functionality
[11:24] <Riddell> make kiosktool work with sudo
[11:24] <Riddell> porting some of the kubuntu apps to KDE 4 like system settings and guidance
[11:25] <Riddell> getting an onscreen keyboard since that's something we lack
[11:25] <Riddell> and our summer of code student is working on a port of gdebi
[11:25] <Riddell> oh and a port of restricted-manager
[11:25] <nevermind_> ok, time to read up a bit better on the tutorials for these sessions
[11:25] <Riddell> other suggestions welcome
[11:26] <Riddell> nevermind_: did you mean getting university students into kubuntu development?
[11:26] <nevermind_> not only university students
[11:26] <nevermind_> more like... offering courses at the teaching centers at cities and such
[11:26] <Riddell> I'm just one programmer, I'm not a teacher
[11:27] <nevermind_> base courses like "usage" maybe some admining or networking, maybe some base programming
[11:27] <Riddell> but canonical is working on a training programme
[11:27] <Riddell> so you can get trained up in various aspects of ubuntu usage
[11:27] <nevermind_> yah, but id guess there are some ppls around who may be actually interrested)
[11:27] <nevermind_> might wanna bring it up at some lug meetings even
[11:27] <Riddell> I also think that university students are a much under-used resource for free software
[11:27] <nevermind_> yea
[11:27] <Riddell> computing science students have to do a dissertation on something which usually ends up written up and forgotten about
[11:28] <Riddell> I made a programme called Umbrello UML Modeller which has a lot of real world users
[11:28] <Riddell> recently a university in france had a course where their students worked on Umbrello and KPlato
[11:28] <Riddell> we got good features
[11:28] <nevermind_> ive just read some paper of a japanese student who did cpu virtualisation
[11:28] <jenda> Riddell: you'll prolly have to poke me for each next question ;)
[11:28] <Riddell> and they got real world experience of code
[11:28] <nevermind_> theres alot of good papers and ideas out there one could continue to work with
[11:28] <Riddell> so if you're trying to learn about programming, there's no better way than to code free software
[11:29] <Riddell> it's a guaranteed A for a uni dissertation
[11:29] <Riddell> in my experience anyway
[11:29] <nevermind_> hehehe
[11:29] <Riddell> jenda: go
[11:29] <jenda> < Belutz> QUESTION: all the websites i visited always highlights the new features of ubuntu 7.04 and give screenshots of that feature. Is there a website that highlights new features in kubuntu with screenshots?
[11:29] <Riddell> well, kubuntu.org would
[11:29] <Riddell> except it's died in the data centre crash that happened earlier today
[11:30] <Riddell> but I'm sure it'll be up soon
[11:30] <nevermind_> ouch
[11:30] <Riddell> https://wiki.kubuntu.org/FeistyFawn/Beta/Kubuntu is a good guide
[11:30] <Riddell> and the previous Herd ones it links to
[11:30] <Riddell> thanks to nixternal, he does a great job on them
[11:30] <Riddell> jenda: yo
[11:30] <jenda> < Belutz> QUESTION: i haven't tried kubuntu 7.04 is desktop effects also available in kubuntu?
[11:30] <jenda> gargh
[11:30] <jenda> sorry
[11:31] <Riddell> I refer the honourable gentleman to the answer I gave some moments ago