[01:35] <Alucard> bashohII> おはよう〜
[01:35] <bashohII> Hello
[01:36] <Alucard> にほんじんですか？
[01:36] <bashohII> はい
[01:36] <Alucard> おぉ〜
[01:37] <Alucard> 関東からですか？
[01:37] <bashohII> はい
[01:37] <bashohII> 神奈川です
[01:37] <Alucard> ＠＿＠
[01:38] <Alucard> 神奈川 オールスターですか？
[01:38] <Alucard> SLAM DUNKから
[01:38] <bashohII> 湘南ボーイ です。
[01:38] <Alucard> www
[01:39] <Alucard> 爆走族＠＠？
[01:39] <bashohII> ゴールド免許の らいだ～ ですｗ
[01:40] <Alucard> そうね〜www
[01:40] <bashohII> Alucard > 日本人ですか？
[01:40] <Alucard> bashohII> ホンコンじんです
[01:40] <Alucard> ４６４９ね
[01:43] <bashohII> 你的日语很好
[01:43] <Alucard> bashohII>謝謝您
[01:44] <bashohII> 我已经留学了在中国
[01:44] <Alucard> bashohII> おぉ〜
[01:44] <Alucard> "我已经在中国留学了" これでいいよ〜：P
[01:45] <bashohII> 以后也请多多关照
[01:45] <bashohII> 谢谢您
[01:45] <Alucard> bashohII> 在中國的生活怎樣?
[01:45] <bashohII> 很好
[01:46] <Alucard> bashohII> これから４６４９
[01:46] <bashohII> 我在沈阳
[01:46] <bashohII> ｋｋ
[01:46] <Alucard> 沈陽不錯的
[01:48] <Alucard> bashohII> 有吃過了什麼不錯的東西呢?
[01:50] <bashohII> 写简体字可以吗？
[01:50] <Alucard> 現在はできない〜XD
[01:51] <bashohII> ｋｋ
[01:51] <Alucard> 看不懂嗎?
[01:51] <Alucard> 還是看不到?
[01:51] <bashohII> 看不懂
[01:52] <Alucard> おぉ〜すまん
[01:52] <bashohII> 有的汉字不能读
[01:53] <Alucard> 显示不到吗?
[01:53] <Alucard> あはっは〜忘了可以使用firefox的extension
[01:54] <bashohII> 可能表示
[01:58] <bashohII> 但繁体字读得很难
[01:59] <Alucard> 哈哈~只是简体字简化程度太高了~
[02:00] <bashohII> 学的时候太乐
[02:00] <bashohII> 我还学口语
[02:01] <Alucard> 国语吗(國語嗎)?
[02:01] <bashohII> 听的时候太难
[02:02] <bashohII> 普通话
[02:03] <Alucard> 哈哈~也是呢~国语中有很多字词跟日语近似(哈哈~也是呢~國語中有很多字詞跟日語近似)
[02:04] <bashohII> 对
[02:05] <bashohII> 但，在中国的时候忘了日语ｗｗｗ
[02:05] <Alucard> 也有点字词的意思跟日语一样呢~(也有點字詞的意思跟日語一樣呢~)
[02:05] <Alucard> www
[02:08] <bashohII> 现在我有在日本国的中国人的朋友
[02:08] <Alucard> @@
[02:10] <bashohII> 跟一起聊天儿的时候，不要汉字ｗｗｗ
[02:10] <Alucard> bashohII> 有来过香港吗(有來過香港嗎)?
[02:11] <Alucard> bashohII> 哈哈~
[02:12] <bashohII> 以后，我想去香港
[02:12] <Alucard> 好~^^~
[02:12] <bashohII> 我已经去澳门
[02:13] <bashohII> 但，我不能广东语
[02:13] <Alucard> 呵呵~说普通话也行的喔~(呵呵~說普通話也行的喔~)
[02:16] <bashohII> 以后也请多多关照^^
[02:16] <Alucard> 猪排面包也有吃过吗(豬排麵包也有吃過嗎)?
[02:17] <bashohII> 没有经验
[02:18] <bashohII> 好吃吗？
[02:18] <Alucard> もちろんだよ〜：P
[02:19] <Alucard> Next meeting    When: 21st February 2008    Start: 16:00    End: 17:00    Timezone:  UTC    Where: #ubuntu-training on irc.freenode.net    Chaired By: Billy Cina
[02:19] <bashohII> こんど、中国に行ったら食べるよ。
[02:19] <bashohII> ｋｋ
[02:20] <Alucard> 明天有课可以上了(明天有課可以上了)
[02:20] <Alucard> 中国人有句说话"民以食为天"(中國人有句說話"民以食為天")
[02:22] <bashohII> 南方的料理是很好
[02:23] <bashohII> 我，喜欢周杰伦ｗｗｗ
[02:24] <Alucard> 北方的面也很好的喔(北方的麵也很好的喔)
[02:24] <bashohII> 味不同
[02:24] <bashohII> 但，好吃
[02:25] <Alucard> 我喜欢(我喜歡)L'ARC~en~Ciel www
[02:26] <bashohII> 我周杰伦，孙燕姿的歌常常听
[02:26] <Alucard> d21 UTC 1600 = d22 GMT+8 0000/d22 GMT+9 0100
[02:27] <Alucard> 后晚才有课,我先离开了(後晚才有課,我先離開了)
[02:27] <Alucard> それじゃ〜
[02:28] <bashohII> 再见
[10:35] <Seeker`> .names
[10:37] <popey> bah
[10:37] <popey> beat me
[14:56] <v0lksman> #ubuntu-classroom-chat
[14:56] <v0lksman> hahah..oops
[15:49] <nxvl_work> bug #192887
[15:50] <slytherin> nxvl_work: Wrong window probably
[15:50] <nxvl_work> slytherin: nop, testing ubotu for my talk
[15:51] <slytherin> nxvl_work: Remove the #
[15:51] <dholbach> there's just ubuntulog in here
[15:51] <dholbach> so no dice
[15:51] <nxvl_work> bug 192887
[15:51] <nxvl_work> dholbach: it doesn't put the links to the bugs inhere?
[15:52] <jpatrick> odd, ubotu is here
[15:52] <dholbach> oh... it is
[15:52] <dholbach> sorry
[15:52] <daishujin> does it need a !
[15:52] <daishujin> !bug 192887
[15:53] <slytherin> ubotu: wakeup
[15:53] <ubotu> Sorry, I don't know anything about wakeup - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi
[15:53] <dholbach> maybe best to ask Seveas in some other channel
[15:53] <daishujin> lol
[15:53] <sistpoty|work> Launchpad bug 192887 in ubuntu "FeatureFreeze exception request for sun-javadb" [Undecided,New] https://launchpad.net/bugs/192887 (sorry, I'm a busy bot :P)
[15:53] <dholbach> sistpoty|work: hehe
[15:54] <nxvl_work> dholbach: doesn't mind i will paste the link by myself
[15:55] <dholbach> nxvl_work: if you type manually: http://launchpad.net/bugs/<number> will be the shortest
[15:55] <jpatrick> dholbach: pinged him
[15:55] <nxvl_work> dholbach: yep, i know
[15:55] <dholbach> rock on
[15:55] <nxvl_work> dholbach: thanks
[15:59] <dholbach> WELCOME EVERYBODY TO DAY THREE OF UBUNTU DEVELOPER WEEK!
[16:00] <dholbach> I hope that's enough caps for today and you don't mind if I write lower case from now on :)
[16:00]  * mruiz waves
[16:00] <InsClusoe> Hurray!
[16:00] <mrsno> hey :)
[16:00] <dholbach> please ask questions in #ubuntu-classroom-chat, prefixed with QUESTION:
[16:00] <dholbach> everybody excited?
[16:00] <dholbach> ready to go?
[16:00]  * InsClusoe wags his tail furiously..
[16:00] <dholbach> hehehe :-)
[16:01] <dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek has the schedule of today and we'll start off with "MOTU Processes"
[16:01] <nxvl_work> \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/ \o\ /o/
[16:01] <Iulian> Wooah
[16:01] <dholbach> I gave a session with the same title yesterday and will cover the same topics because I think they're important
[16:02] <dholbach> please don't hesitate to ask all questions related to MOTU, Ubuntu Development and other stuff you're wondering about
[16:02] <nxvl_work> dholbach: i will handle the questons again
[16:02] <dholbach> nxvl_work: you ROCK
[16:02] <dholbach> so there's been talk about MOTU for the whole week already - I hope you all know what MOTU is about :)
[16:03] <dholbach> MOTU is the first stepping stone into Ubuntu Development and the team who will help you get started
[16:03] <dholbach> as member of the MOTU team you can upload packages to universe and multiverse
[16:03] <dholbach> the process to join the team is pretty straight-forward:
[16:04] <dholbach>  - you work with sponsors (more about that in a bit) who will review your packages and patches and upload them into the archive once they're happy
[16:05] <dholbach>  - once the sponsors tell you: "hey man, you should be able to do this on your own - you're really good", you should probably consider applying for MOTU membership at the MOTU Council
[16:05] <dholbach> and that's all there is to it
[16:05] <dholbach> Sponsoring means: somebody who's member of ~ubuntu-dev will review your patch or package, sign it with their gpg key, then upload to the build daemon
[16:06] <dholbach> the advantage of this process is: you don't have a fixed sponsor but work with a team, so you can learn a lot of different things from a lot of different people
[16:06] <dholbach> also you get to know a lot of people who can help you out in the Ubuntu community
[16:07] <dholbach> the sponsorship process is explained at https://wiki.ubuntu.com/SponsorshipProcess and means in a nutshell:
[16:07] <dholbach>  - you attach your patch on a bug report
[16:07] <dholbach>  - then subscribe the sponsors team (which for main/restricted packages is ubuntu-main-sponsors    and     for universe/multiverse packages is ubuntu-universe-sponsors)
[16:08] <dholbach> does that make sense so far?
[16:08] <dholbach> any questions about what it's like to go through the process or anything that's unclear?
 QUESTION:  What's the difference between a sponsor and the REVU site?
[16:09] <dholbach> v0lksman: good point
[16:09] <dholbach> REVU is a page we set up quite a while ago to help us with reviewing NEW packages
[16:09] <dholbach> NEW packages generally mean software that has never been in Ubuntu, so fresh new software :)
[16:09] <dholbach> http://revu.tauware.de/
[16:10] <dholbach> https://wiki.ubuntu.com/MOTU/Packages/REVU explains how to upload software there
[16:10] <dholbach> NEW packages are a bit different as they require much closer review, the review of a 'diff' is just not enough
[16:10] <v0lksman> gotcha...thanks
 QUESTION: How is ensured that patches don't break something else inadvertently?
[16:10] <mruiz> dholbach, http://revu.ubuntuwire.com
[16:11] <dholbach> getting a NEW package in requires two ACKs from ubuntu-dev members and is something we work on in the first half of the release cycle, the second half (after Feature Freeze) is dedicated to fix the packages we already have :)
[16:11] <dholbach> InsClusoe: excellent question
[16:11] <dholbach> there are a lot of things you can test:
[16:11] <dholbach>  - does it still build with the patch applied?
[16:11] <dholbach>  - is the patch integrated upstream or in debian already?
[16:11] <dholbach>  - checking the resulting binary packages: are there removed files?
[16:12] <dholbach>  - checking library packages: are there symbols which were removed from the library
[16:12] <dholbach>  - etc etc etc
[16:13] <dholbach> there are lots of things to look at, especially when the patches are big - you learn a lot when you try to get patches included, it's the same kind of things you test when you review other patches :)
 QUESTION: How is ensured that patches don't break something else inadvertently?
[16:14] <dholbach>  QUESTION: Ok.. Is there any checklist that I can refer to so that I can have a certain level of confidence in the patch I submit?
[16:14] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews has a good overview but is probably not complete :)
[16:15] <dholbach> InsClusoe: if you have doubts about the patch you're about to submit, it's probably best to point that concern out in the bug report so people know what to look at
[16:15] <InsClusoe> Yup.. Makes sense.. Thanks.
[16:15] <dholbach> I personally trust people more who point out that they're unsure - it's a sign of good collaboration
 QUESTION: Recently the process for new versions of packages was changed from 'submit interdiff' to 'submit .diff.gz'. What are the reasons and how does newer process helps sponsoring?
[16:16] <dholbach> slytherin: the process was changed back to .diff.gz
[16:16] <dholbach> some developers found using and reviewing an interdiff to be a bit cumbersome
[16:17] <slytherin> Makes sense. Thanks. :-)
[16:17] <dholbach> people seemed to be more familiar with using filterdiff on diff files, but I have to admit there were other more technical reasons, I can't find the reference right now
[16:18] <dholbach> excusez-moi :)
[16:18] <dholbach> any more questions on how to get your packages / patches included? what is expected of a MOTU or anything else?
[16:18] <nxvl_work> dholbach: mi list is empty
[16:19] <nxvl_work> my*
[16:19] <dholbach> ok, let me talk a bit about Events - it's not so much a process but something that might help get you started
[16:19] <dholbach> every Friday at 13:00 UTC (minus the coming Friday) we have a MOTU Q&A session in this very channel
[16:19] <dholbach> it's a good time to meet developers and talk about problems you're having or things you don't understand in a smaller forum than this IRC session :)
[16:20] <dholbach> also we do Packaging 101 session once a month
[16:20] <dholbach> all of these happen in #ubuntu-classroom
[16:20] <dholbach> other things that might be beneficial for you
[16:20] <dholbach>  - #ubuntu-motu of course :)
[16:20] <dholbach>  - ubuntu-motu-mentors@lists.ubuntu.com
[16:20] <dholbach> don't hesitate to ask - there's always *somebody* awake :)
[16:21] <dholbach> nxvl will give a session later on about how to get started on MOTU/TODO and MOTU/TODO/Bugs - that's going to be excellent
[16:21] <yannick_lm> hi there
[16:22] <dholbach> I talked a bit about Feature Freeze earlier
[16:22] <dholbach> FF is the time when specs that are targetted for the current release need to be in a good shape already
[16:22] <dholbach> and for us who do package maintenance it means: stabilisation
[16:22] <dholbach> so we need to get exceptions for NEW packages and new upstream releases (if it's not 100% clear that it's a bugfix-only release)
[16:23] <dholbach> some days before the release day we enter Hard Freeze where every single change will be reviewed
[16:23] <dholbach> https://wiki.ubuntu.com/HardyReleaseSchedule for reference
[16:23] <dholbach> does that make sense so far?
[16:24] <dholbach> ok, it seems so :)
[16:24] <dholbach> another important topic is the Sync Request Process
[16:24] <dholbach> there's always some bit of confusion about what a sync actually is
[16:25] <dholbach> a sync means: copy the source package from debian as-is, build it in ubuntu
[16:25] <dholbach> this implies that all changes in the current Ubuntu package are overwritten
[16:25] <dholbach> so if you decide to ask for a sync, you need to make 100% sure it'S OK to do that
[16:26] <dholbach> if you've checked that the new package from debian builds, it's OK to sync it in the current time of the release cycle, you can file a bug report asking for the sync
[16:26] <dholbach> you include the changelog of the debian package to indicate what has happened in the meantime
[16:27] <dholbach> then (if you're not in ubuntu-dev yet) subscribe ubuntu-universe-sponsors if it's in unvierse/multiverse (ubuntu-main-sponsors accordingly)
[16:27] <dholbach> they will ACK the report if it's OK, then get the ubuntu-archive team to do it :)
[16:28] <dholbach> https://wiki.ubuntu.com/SyncRequestProcess also explains about a tool called requestsync which makes your life even easier
[16:28] <dholbach> the same checks that InsClusoe and I talked about earlier apply to sync too
[16:28] <dholbach> so if the synced debian package does not build on ubuntu we have a problem and need to fix it, etc etc
[16:29] <dholbach> being in sync is a very good thing, but we need to be careful
[16:29] <dholbach> what does it mean to be in sync?
[16:30] <InsClusoe> It means we are using the latest version from upstream.
[16:30] <dholbach> if you look at https://wiki.ubuntu.com/HardyReleaseSchedule again you will notice that from start of the release cycle to some time nine weeks later (until Debian Import Freeze) the status is all green
[16:30] <dholbach> in this time we will sync the newest version of the debian package automatically
[16:31] <dholbach> if you're in sync with debian and you run into problems you have more eyes on the problem, because you both use the same unmodified source
[16:31] <dholbach> even better if the debian version is in sync with the version of the upstream authors :)
[16:32] <dholbach> also: if we're not in sync we need to merge our changes manually in that green timeline of the release schedule
[16:32] <dholbach> and that's a lot of work
[16:33] <dholbach> for those of you who didn't have the time to attend James Westby's and nxvl's session about collaborating with debian here's the link: https://wiki.ubuntu.com/MeetingLogs/devweek0802/Debian
[16:33] <dholbach> if we pass on our patches, we can make sure we get in sync quicker again, which we all benefit from
[16:33] <dholbach> any questions? :)
[16:33] <nxvl_work> dholbach: empty list again
[16:34] <dholbach> nxvl_work: I just wanted to leave some time for people to ask questions :)
[16:34] <dholbach> https://wiki.ubuntu.com/UbuntuDevelopment/Merging is a pretty good page of how to do merging
[16:34] <nxvl_work> dholbach: yes, i know, but i was trying to tell you to wait for questions cause there are no one on queue :D
[16:34]  * dholbach hugs nxvl_work
[16:35]  * nxvl_work HUGS dholbach back
 QUESTION: Between two releases, if there is no change in debian version of a package and there are a few ubuntu fixes, would we still sync with Debian at the start of the release cycle?
[16:35] <dholbach> when Hardy+1 opens this is going to be the first big portion of things we work on and excellent to help out with :)
[16:35] <dholbach> InsClusoe: no, as soon as a package contains "ubuntu" in the version string it is not synced
[16:36] <dholbach> or hang on - did I understand your question correctly?
[16:36] <dholbach> if there are no debian changes, there's nothing to sync
[16:37] <dholbach> we can still try to pass on our ubuntu changes to the debian maintainer though
[16:37] <dholbach> that's always advisable
[16:37] <dholbach> James Westby and nxvl_work might have talked about a tool called submittodebian which makes the process of sending patches virtually painless
[16:37] <dholbach> it makes use of https://wiki.ubuntu.com/Bugs/Debian/Usertagging internally
[16:38] <dholbach> so that patches in the debian bugtracker get a tag called 'origin-ubuntu': http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=origin-ubuntu;users=ubuntu-devel@lists.ubuntu.com
[16:39] <dholbach> other patches are directly grabbed by debian maintainers or live in some kind of revision control system, so you probably won't find every patch that was ever sent in that list
[16:39] <dholbach> a few things I always highlight are:
[16:40] <dholbach>  - https://wiki.ubuntu.com/UbuntuDevelopment (for general process questions - like How does the archive work? When can I request a sync? etc)
[16:40] <dholbach>  - https://wiki.ubuntu.com/PackagingGuide (which helps with packaging, it has tutorials and everything)
[16:40] <dholbach>  - and https://wiki.ubuntu.com/MOTU (which lists team meetings, team organisation and so on)
[16:41] <dholbach> https://wiki.ubuntu.com/MOTU/GettingStarted is the general first address :)
[16:41] <dholbach> Who of you could imagine helping out in the MOTU team any time soon? :-)
[16:41] <nxvl_work> o/
[16:42] <dholbach> that's all? :-)
[16:42] <xander21c> I
[16:42]  * InsClusoe says yes if [soon=now].
[16:42] <daishujin> I'd like to try
[16:42] <Picklesworth> :)
[16:42] <dholbach> ROCK and ROLL - that's the spirit :-)
[16:42] <Iulian> Who knows, I still have many things to learn.
[16:43] <dholbach> What's your general impression of Ubutnu Development? Daunting? Crazy?
[16:43] <Iulian> Impressive
[16:43] <nxvl_work> HUGGY
[16:43] <nxvl_work> :D
[16:43] <dholbach> :-)
[16:43] <Iulian> Heh :)
[16:43] <dholbach> Iulian: impressive how?
[16:44] <daishujin> these talks have certainly made me appreciate my desktop alot more!
[16:44] <Iulian> dholbach: In many areas.
[16:44] <bazhang> amazing what all of you do
[16:44] <Iulian> I mean, I like how the team is working, helping each others...
[16:44] <InsClusoe> It's really cool.
[16:45] <slytherin> What is amazing is that you can help improve your own user experience. :-0
[16:45] <Iulian> Yes, indeed.
[16:45] <slytherin> :-)
[16:45] <dholbach> slytherin: exactly
[16:45] <dholbach> what's important to me is to show you that you can help each other too and that the whole processes are no rocket science :)
[16:46] <dholbach> but that with some patience, some detective skills and motivation you can be part of the whole thing too :)
[16:46] <InsClusoe> QUESTION: How do you guys manage to ensure high levels of usability without any kind of automated testing? Or is there any wrong assumption on my part?
[16:46] <dholbach> InsClusoe: automatic testing as in how? testing of usability?
[16:47] <dholbach> by the way: Thursday 17:00 UTC: Writing Scripts For Automated Desktop Testing (Lars Wirzenius)
[16:47] <InsClusoe> Companies usually have robots for UI testing and things like that.
[16:48] <dholbach> Lars has been putting a lot of effort into figuring out the problem of UI testing
[16:48] <dholbach> but we benefit of course of a lot of other developers working with us
[16:48] <dholbach> so for example gnome packages before they are released in ubuntu have gone through a lot of hands already: the GNOME upstream developers have regular SVN checkouts and so on
[16:49] <dholbach> some software (unfortunately not all) comes with HUGE test suites
[16:49] <dholbach> if you look at the code of bzr for example - it's just amazing
[16:50] <slytherin> And then there are beta testers. :-D
[16:50] <dholbach> of course :)
 QUESTION: Do the packages have associate test suites to ensure quality?
[16:50] <dholbach> Shiv: we run regular installability test of packages and regular lintian checks too
[16:51] <dholbach> lintian and linda are tools to check how policy compliant packages are
[16:51] <dholbach> when it comes to test suites regarding the software itself we mostly depend on the test suites that upstream authors have written
[16:51] <dholbach> a large degree of software written just for ubuntu has test suites too (like apport, jockey, etc)
[16:52] <dholbach> and as far as I know the security team writes tests for the fixes they upload too
[16:52] <dholbach> so if there should be a security regression it should be caught
 QUESTION: How do you test installation and functionality of a base package (say glibc)
[16:52] <nxvl> < Shiv> QUESTION: How do you test installation and functionality of a base package (say  glibc)
[16:53] <dholbach> :)
[16:53] <dholbach> Shiv: piuparts is a tool that Lars Wirzenius has written which test installation of packages in a chroot (a fresh minimal environment)
[16:53] <dholbach> libc6 is tested like all other packages too
[16:53] <dholbach> another huge part of what we test is upgrades
[16:54] <dholbach> we have machines doing nothing else but testing upgrades from gutsy to hardy, from dapper to hardy and so on
 QUESTION: For a developer to test this, it would be painful. If a newer ubuntu release needs newer toolchain, building all of them is a difficult proposition.
[16:55] <dholbach> Shiv: absolutely, which is why at least main is built with a new toolchain once it is put in place
[16:55] <dholbach> https://wiki.ubuntu.com/HardyReleaseSchedule indicates when those tests are run
[16:55] <dholbach> any more questions about Ubuntu Development? :)
[16:56] <dholbach> what I like about the questions from you guys today is: you absolutely want to do it right - that's great
[16:56] <nxvl>  < Shiv> QUESTION: Is toolchain uploading done by MOTUs or core-dev
[16:56] <dholbach> Shiv: doko is your man - he's in charge of the toolchain and an awesome guy
[16:57] <lsaavedr> holas
[16:57] <dholbach> he's employed by Canonical, a core-dev and works in the Debian Toolchain team too
[16:58] <dholbach> more questions? :)
[16:58] <dholbach> if not, you have two more minutes until the next session :)
[16:58] <dholbach> thanks everybody for coming to the session!
[16:58] <russell__> no problem ;)
[16:59]  * mruiz hugs dholbach 
[16:59] <Iulian> dholbach: No, thank you!
[16:59] <dholbach> :-))))
[16:59]  * dholbach hugs Iulian
[16:59] <Iulian> Hehe
[16:59] <dholbach> oh.... I completely forgot something! Packaging Jams!
[16:59] <dholbach> watch out for Packaging Jams in your area :)
[17:00] <dholbach> ok it's 17:00 UTC
[17:00] <dholbach> and thumper is already here
[17:00] <thumper> I am
[17:00] <thumper> dholbach: get into it now?
[17:00] <dholbach> thumper is Tim Penhey, a Launchpad Hacker who among others made the goodness that http://code.launchpad.net/ is possible
[17:00]  * thumper bows
[17:01] <thumper> = Hosting Code With Launchpad =
[17:01] <dholbach> I hope you all enjoy the session and ask your questions in #ubuntu-classroom-chat
[17:01] <dholbach> thumper: the stage is yours :)
[17:01] <thumper> dholbach: thanks
[17:01] <thumper> This is my first time working with dholbach and ubuntu open week
[17:01] <thumper> so be gentle
[17:01] <thumper> Just so I feel like I'm not just talking to myself the whole time
[17:02] <thumper> who is around for this one?
[17:02] <InsClusoe> 0/
[17:02] <Shiv> 1/
[17:02] <nxvl> o/
[17:02] <daishujin> +1
[17:02] <Iulian> I am
[17:02] <thumper> cool
[17:02] <dustinlange> +1
[17:02] <db-keen> +1
[17:03] <thumper> As dholbach said, my name is Tim and I am the team lead for the launchpad-bazaar integration
[17:03] <thumper> Our job as a team is to make using Launchpad with Bazaar better than the sum of the parts
[17:03] <thumper> Launchpad by itself is really nifty
[17:03] <KEB1> is teh sessoin alreday running?
[17:03] <thumper> Bazaar by itself rocks
[17:03] <thumper> KEB1: yep
[17:03] <thumper> our job is to make using Launchpad and Bazaar together really blow your socks off
[17:03] <thumper> As some of you may suspect, part of this was prepared in advance :)
[17:04] <thumper> == Bazaar ==
[17:04] <thumper> A very quick intro
[17:04] <Grazieno> +1
[17:04] <thumper> Bazaar is a distributed version control system found at http://bazaar-vcs.org
[17:04] <thumper> Bazaar is installed on all ubuntu machines by default, and is the command 'bzr'
[17:04] <thumper> You don't need a central repository to manage your code
[17:04] <thumper> and that's all I'm going to say about it right now
[17:05] <thumper> == Launchpad ==
[17:05] <thumper> Trying to describe what Launchpad is in just a few words is really hard
 QUESTION: Sounds lame, but nevertheless - is bazaar by ubuntu and for what purpose ?
[17:05] <thumper> Bazaar is a community project
[17:05] <thumper> but several lead developers a canonical employees
[17:07] <thumper> Bazaar was sponsored by canonical because at the time there were no DVCS available that provided the functionality that was looked for
[17:07] <thumper>  <Shiv> QUESTION: (continue) so what role does bzr play for ubuntu, or is it a standalong product ?
[17:07] <thumper> bzr is a standalone product
[17:07] <thumper> but it is also a tool for collaborative software development
[17:08] <thumper> more will become apparent as I go on
[17:08] <thumper> Launchpad aims to make it easier to collaborate in open source software development
[17:08] <thumper> Launchpad is a bug tracker, feature planner, translation manager, handles questions and answers, and a source code repository
[17:08] <thumper> or as kiko has mentioned in a blog post, a source code supermarket
[17:08] <thumper> What we are here to talk about today is working with code and launchpad together
[17:09] <thumper> (using bzr as a package management tool is a whole different session, sorry Shiv)
[17:09] <thumper> As far as Launchpad is concerned, code is stuff in Bazaar branches
[17:09] <thumper> Yes, you can put other stuff in branches too, but we think of it as code
[17:10] <thumper> To get a quick overview of the projects that have code available, you can look at https://code.launchpad.net/+project-cloud (hopefully you don't all go there at once)
[17:10] <thumper> Bazaar is a relative new-comer in the version control stakes, and as such many projects use other revision control systems
[17:10] <thumper> Launchpad can import CVS and Subversion branches into bazaar branches and make these available through Launchpad
[17:11] <thumper> These are considered "imported" branches, and are owned by the vcs-imports user (https://code.launchpad.net/~vcs-imports)
[17:11] <thumper> If you have your code in a bazaar branch now, you can either "push" your branch to Launchpad (using `bzr push`) or get Launchpad to mirror your branch from a public, accessible location
[17:12] <thumper> One of the recent improvements to the user interface to bzr (read that as command line), is to be able to use an URL scheme of lp: to reference launchpad.
 QUESTION: given all that Launchpad is, is it intended to be like SourceForge, Novell Forge, GNU Savannah, etc.?
[17:12] <thumper> Yes, and then some
[17:12] <thumper> So I can go `bzr branch lp:gnuhello` to get a copy of gnuhello (you can too).
[17:13] <thumper> If you have a launchpad identity, you need to make sure that you have specified a SSH key in order to push to launchpad (https://launchpad.net/people/+me/+editsshkeys).
[17:13] <thumper> This is how launchpad confirms that it is you
[17:13]  * thumper pours more coffee
 QUESTION: Why another tool (bzr) instead of adapting distributed versioning tool like hg ?
[17:14] <thumper> bzr and hg both have a similar basis and both started development at around the same time
[17:14] <thumper> bzr had a different set of ideals than hg
[17:14] <thumper> and we believe the future is bzr (but we are biased)
[17:15] <thumper> Since my username is thumper for Launchpad, I can push a copy of gnuhello that I'd just branches by using `bzr push bzr+ssh://thumper@bazaar.launchpad.net/~thumper/gnuhello/my-branch`
[17:15] <thumper> I'm sure you can agree that is somewhat unwieldy
[17:15] <thumper> Bazaar gets shipped with a launchpad plugin which allows some nifty additions
[17:15] <thumper> You can tell bzr about your launchpad id by using `bzr launchpad-login` and your launchpad id
[17:16] <thumper> so mine would be `bzr launchpad-login thumper`
[17:16] <thumper> Then you can push directly to launchpad using `bzr push lp:~thumper/gnuhello/my-branch` which is somewhat shorter
 QUESTION: are there plugins for git, hg, etc. planned for LP integration?
[17:17] <thumper> before we could look at integrating them, they need to be able to handle incremental imports
[17:17] <thumper> but yes, we are considering them
[17:17] <thumper> The push to an lp scheme url require bzr 1.1 I think
[17:17] <thumper> QUESTION: by "bazaar" you mean "bazaar-ng", right?  ;)
[17:18] <thumper> bazaar-ng is an old term that has been superseded
[17:18] <thumper> :-)
[17:18] <thumper> there is quite a history with the tool
[17:18] <thumper> There was an older bazaar with the command 'baz'
[17:18] <thumper> which was replaced by Bazaar-NG
[17:19] <thumper> which then took over the name
[17:19] <thumper> so we don't call it Bazaar-NG any more, just Bazaar
[17:19] <thumper> BTW if you are wanting the latest bzr, use the Bazaar developers PPA (https://launchpad.net/~bzr/+archive)
[17:19] <thumper> Branches in Launchpad are identified by a tripartite name, the owner of the branch, the project, and the branch name these three parts need to be unique in Launchpad
[17:20] <thumper> Branches can be owned by individuals, like you and me, or by teams, such as bzr (https://launchpad.net/~bzr) or mailman-coders (https://launchpad.net/~mailman-coders)
[17:20] <thumper> When a branch is owned by a team, any active member of that team can push to that branch to update it (providing it is not mirrored from elsewhere)
[17:20] <thumper> Why put branches on Launchpad I hear you say?
[17:21]  * thumper hits the end of his pre-prepared notes 
[17:21] <thumper> Firstly it makes you code available to others
[17:21] <thumper> since bzr is a distributed version control system, your commits for your work are local
[17:21] <thumper> until you make them available to other, people can't merge them
[17:21] <thumper> (bundles and merge-directives aside)
[17:22] <thumper> and as of Launchpad 1.2.2 you'll get karma for registering brances :)
[17:22] <thumper> You are able to link branches to bugs and blueprints to show intent
[17:22] <thumper> branches linked to bugs indicate that the branch will fix, or does fix the bug
[17:23] <thumper> branch linked to a blueprint indicate that the branch does or will implement the feature
 QUESTION: Are branches in bzr a neat way to submit patches, a way of different people working on different chunks of project, or both, or neither?
[17:23] <thumper> Picklesworth: you've hit the nail on the head with that one
[17:23] <thumper> that is exactly the intent
[17:24] <thumper> with traditional centralised source control systems you need commit rights to write to the central repository
[17:24] <thumper> like with CVS and Subversion
[17:24] <thumper> with bzr you can make your own branch
[17:24] <thumper> commit with useful messages
[17:24] <thumper> and there is a tracability there
[17:24] <thumper> you can make the branch available for the core developers
[17:24] <steffen_> cool!
[17:25] <thumper> and if the like your change, they can merge your branch in
[17:25] <thumper> which keeps the attribution to the original author, commit message, complete history et al
 QUESTION: given that, what's the point of bundles?
[17:26] <thumper> bundles are the ability to send bzr revisions (your work) to people using email
[17:26] <thumper> bundles have been superseded by bzr merge-directives which contains additional meta-data
 QUESTION: Given that a big aim of LP is to promote coordination and collaboration in FOSS, what are you doing to interoperate with the aforementioned source-forge alikes?
[17:27] <thumper> Launchpad has the ability to have bug-watches on the other systems to where the primary bug tracker is elsewhere
[17:27] <thumper> Launchpad can also import the code from CVS or Subversion to make it available to be used in the way mentioned above
[17:27] <thumper> QUESTION: how does LP handle (write) permissions?  Can you give a project member access to a portion of the branch, or is it all/nothing?
[17:28] <thumper> No you cannot give access to portions of a branch
[17:28] <thumper> that is limited by the bzr tool
[17:28] <thumper> however there are other options
[17:28] <thumper> projects like zope have recently broken up the large source tree into many small ones
[17:28] <thumper> this allows them to have fine grained control over permissions
[17:29] <thumper> Launchpad controls write access to branches through the owner of the branch
[17:29] <thumper> if the owner is a team, then the team can write to the branch
 QUESTION: what sort of IM/voice/email/whiteboard/video capabilities does LP have?
[17:29] <thumper> While this is somewhat off topic...
[17:30] <thumper> Launchpad has email lists in beta test
[17:30] <thumper> and many Launchpad elements have either whiteborads to leave comments on or can be commented on my any logged in user (like bugs)
[17:30] <thumper> no video, im or voice right now
 QUESTION: any eclipse and emacs integration planned?
[17:31] <thumper> there is an eclipse plug-in for bzr, but not launchpad at this time
[17:31] <thumper> there is an api project in the works that will open up all you can do with Launchpad through the web ui to external developers
[17:32] <thumper> but that is most likely still a few months off before parts start becoming available
 QUESTION: why doesn't launchpad allow getting bugs from an arbitrary gforge site since they all use the same soap interface
[17:32] <thumper> db-keen: sorry, don't know the answer for that
 QUESTION: how does LP mesh with the debian system?  E.g. support for dch and friends, as discussed yesterday.
[17:32] <thumper> Solarion: sorry, don't know that either
 QUESTION: what would you say the biggest limitations of LP are in terms of what you would like it to do and in terms of what its competitors do?
[17:33] <thumper> Solarion: not enough time in the day
[17:33] <Solarion> thumper: isn't that ubuntu bug #2?  ;)
[17:33] <thumper> we have some really amazing things in the works
 QUESTION: how does bzr communicated with LP?
[17:34] <thumper> bzr can talk to Launchpad using either SFTP or the bzr smart server (bzr+ssh)
[17:35] <thumper> The SFTP is being deprecated (soon maybe) in favour of bzr+ssh due to the speed improvements that the smart server gives us
 QUESTION: what interfaces does LP provide for those wishing to integrate with it, e.g. with a gnome applet or something?
[17:35] <thumper> Solarion: that'll be the afore mentioned API that's in the works
 QUESTION: so bzr's LP integration is just for dealing with branches, not bugs or whatever?
[17:36] <thumper> bzr has an option on commit to say --fixes
[17:36] <thumper> I think the option looks something like `bzr commit -m "Fixed foo" --fixes=lp:1234`
[17:37] <thumper> when Launchpad scans this revision it creates the link between the bug and the branch
[17:37] <thumper> we are considering how to determine other think like actually updating the bug task status
[17:37] <R1CHARD> alo
[17:37] <thumper> but you have the question of what is fix committed and what is fix released in the DVCS world
[17:37] <thumper> is a bug fix committed when there is a fix on *some* branch, or is it fix committed when it is on trunk?
[17:38] <thumper> for these reasons, we haven't yet hooked that bit up
[17:38] <thumper> now for some new interesting developments
 QUESTION: Is it planned that project can host their websites on LP?
[17:39] <thumper> yes it is planned, but I can't give an ETA right now
[17:39] <thumper> another way to show intent in Launchpad is the "Propose for merging"
[17:39] <thumper> when you have a branch associated with a project in Launchpad, you can say that it is to be merged into another branch
[17:40] <thumper> the default option is to be merged into the development focus branch, but you can specify any branch for the project as a target
[17:40] <thumper> this will create a link between the two branches
[17:40] <thumper> initially this link has a "Work in progress" state
[17:40] <thumper> You can update this to "Needs review" when it is ready
[17:41] <thumper> here is where we are linking in the new code review feature
[17:41] <thumper> this is work in development
[17:41] <thumper> well the code review feature is
[17:41] <thumper> a person who is in the owner team of the target branch can approve or reject the proposal to merge
[17:42] <thumper> and here is were we get to more work in development...
[17:42] <thumper> soon you'll be able to queue up approved proposals
[17:42] <thumper> and there will be a robot (read some magic script) that'll talk to launchpad
[17:42] <thumper> get the branch at the head of the queue
[17:42] <thumper> merge the source into the target
[17:43] <thumper> run the tests (just like PQM)
[17:43] <thumper> and push the resulting branch to Launchpad
[17:43] <thumper> PQM is a bzr tool
[17:43] <thumper> PQM stands for "Patch Queue Manager"
[17:43] <thumper> however now it deals with branches
[17:44] <thumper> PQM uses email to manage the queue, so you email it to tell it to merge something
[17:44] <thumper> we are going to use the same central code, but use launchpad to control the queue rather than email
 QUESTION: Is it planned to include in LP a resource for project management in the shape of Planner or MS Project?
[17:45] <thumper> Mirrado: yes that is planned
[17:45] <thumper> although I'm not sure exactly what is planned
[17:45] <thumper> it has been mentioned that we'd like some more detail along that front
[17:46] <thumper> so, any other questions now?
 QUESTION: Ohloh recently released their code analysis code http://labs.ohloh.net/ohcount/, is that sort of thing expected to be in launchpad?
[17:48] <thumper> db-keen: maybe is all I can say right now
[17:48] <thumper> I don't think we have any definite plans right now
[17:48] <jsauer> aso
[17:49] <thumper> The main thing we are trying to do is make it easier for people to collaborate on code through Launchpad
[17:49] <thumper> We want Launchpad to be a place where people can get code for (almost) any project
[17:50] <thumper> through the `bzr branch lp:some-project`
 QUESTION: how can LP help with dependency tracking? or autotools integration
[17:50] <thumper> Solarion: I don't think we have anything there, and to be honest I don't really know how we'd model it
 QUESTION: Through LP is any way to get metrics about code hosted on bzr?
[17:51] <thumper> Mirrado: what sort of metrics are you after?
[17:51] <thumper> but the answer right now is no
[17:51] <thumper> the only thing we show right now is how many branches there are
[17:51] <thumper> not what's inside them
 QUESTION: If I want to migrate a project from Trac to Launchpad, how challenging of a task is it?
[17:52] <thumper> eddyMul: I guess it depends on how much you want to take with you
[17:53] <thumper> eddyMul: I think there are bug importers around but worthwhile asking on #launchpad
[17:54] <thumper> FYI most of the LP bug developers are in the EU timezone
[17:54] <thumper> if you have other questions you think of later, I'm always around in #launchpad
[17:54] <thumper> so feel free to ping me, and if I'm not around, I'll get to it when I get back
 QUESTION: came in late, but are there any license restriction w.r.t. code hosted in LP?
[17:55] <thumper> Whey you register a project in launchpad, you tell launchpad which licence it uses
[17:56] <thumper> eddyMul: does that answer your question?
 (what source code license are "hostable"?)
[17:56] <eddyMul> thumper: I've never registered a project before... but I assume I'll be presented w/ a list of licenses.... What if my license is not there?
[17:56] <thumper> there is an other box
[17:57] <thumper> any open source code is hostable on launchpad
[17:57] <thumper> we have around 2.5 minutes left
[17:57] <thumper> any last requests?
[17:58] <eddyMul> thumper: does LP support multi-licensed software? (e.g. Mozilla)
[17:58] <thumper> You could look to see what http://launchpad.net/firefox says
[17:59] <eddyMul> thumper: Licenses: None specified.   :)
[17:59] <thumper> :)
[17:59] <thumper> so, that's a wrap
[18:00] <Picklesworth> thumper: Thank you! This was really informative
[18:00] <thumper> dholbach: back to you
[18:00] <Solarion> thumper: thanks
[18:00] <dholbach> thanks a lot thumper for this great session!
[18:00] <eddyMul> thanx, thumper
 code branches, bugs over time, bugs over release cycle, commits over release cycle, lines of code over project life time, etc
[18:00] <barcc> thanks
[18:00] <jsauer> thanks thumper
[18:00]  * nxvl dances 
[18:00] <nxvl> \o> <o> \o/ <o/ \o>
[18:00] <thumper> Mirrado: some of those are there, more are planned
[18:01] <Mirrado> Thanks thumper
[18:01] <dholbach> next up is MOTU Contributor nxvl, also known as Nicolas Valcárcel :-)
[18:01] <nxvl> dholbach: thnx
[18:01] <dholbach> He will talk about First Steps On Contributing (MOTU/TODO & MOTU/TODO/Bugs)
[18:01] <dholbach> enjoy the session :-)
[18:01]  * nxvl waves
[18:01] <nxvl> Ok, so you want to become a MOTU and start developing for ubuntu?
[18:01] <nxvl> There are many ways to start and many things to do
[18:01] <nxvl> sometimes it's hard to find bugs to work and also the places where they are
[18:01] <nxvl> i will try to show you the places where you can find them and how to work with them
[18:01] <nxvl> this will not be a technical talk, so i will not cover packaging aspects
[18:02] <nxvl> but if you have questions about packaging feel free to ask them
[18:02] <nxvl> So, let's start
[18:02] <nxvl> You want to become a MOTU?
[18:02] <InsClusoe> Yes.
[18:02] <nxvl> raise your hans if answer is yes
[18:02] <eddyMul> yes
[18:02] <Iulian> Yes
[18:02] <Solarion> surewhynot
[18:02] <dholbach> party on! :-)
[18:02] <nxvl> ok
[18:02] <nxvl> The first place you need to read is https://wiki.ubuntu.com/MOTU/GettingStarted
[18:02] <nxvl> which has links to the most needed documents you need to read
[18:02]  * dustinlange raises hands
[18:03] <jsauer> yeah
[18:03] <nxvl> and other usefull places to learn how to packages, the MOTU process and so on
[18:03] <nxvl> Daniel have gave a talk about the MOTU process earlier today
[18:03] <nxvl> if you missed it you can find the log here -> https://wiki.ubuntu.com/MeetingLogs/devweek0802/Process2
[18:03] <nxvl> the most important of those documents is the Packaging Guide
[18:03] <nxvl> https://wiki.ubuntu.com/PackagingGuide
[18:03] <Mirrado> Yes
[18:03] <nxvl> in this document you can find how the deb packages are done
[18:03] <nxvl> how you can debianize a package which isn't included on debian/ubuntu already
[18:03] <nxvl> how to patch the package to include bug fixes and new features
[18:03] <nxvl> and all what you need to become a packager
[18:04] <nxvl> If you are interested on packaging new stuff to fully understand the packaging process
[18:04] <nxvl> you can take a look here -> https://edge.launchpad.net/ubuntu/+bugs?field.tag=needs-packaging
[18:04] <nxvl> where you can find all the request of others to package new stuff so it can be included in ubuntu
[18:04] <nxvl> many of the reporters are the upstream developers
[18:04] <nxvl> but, what is an upstream developer?
[18:04] <nxvl> They are the developers of a project which package has been included in ubuntu
[18:05] <nxvl> for example take gnome
[18:05] <nxvl> the developers of the gnome software are the members of the Desktop Team
[18:05] <nxvl> BUT the upstream developers are the members of Gnome project
[18:06] <nxvl> So, if the reporter is the (one of the) upstream developer he/she can help you a lot as he/she knows the package well and can tell you how it builds, the dependencies and such things
[18:07] <nxvl> those are really important things because they are needed by the .deb package to work, build and install
 QUESTION: if upstream already has a debian/ sub-directory in their code, how do we package it (can you talk more aboute "native" packages?)
[18:07] <nxvl> eddyMul: good question
[18:07] <nxvl> yes, it's called native packages
[18:07] <nxvl> but you need to be carefull with them
[18:07] <nxvl> somethimes they are packaged with the project policies, and not Ubuntu ones
[18:08] <queke> o/
[18:08] <nxvl> or packages for debian or another debian-derivate project
[18:08] <nxvl> so it maybe don't work on ubuntu
[18:08] <nxvl> if you test it and it works fine you have not much work to do
[18:09] <nxvl> just package, test it and ask for someone to upload it
[18:09] <nxvl> but as i said, be very carefull with that because they not always work on ubuntu
[18:09] <nxvl> eddyMul: does it is clear now?
[18:10] <nxvl> ok, let move on
 QUESTION: are the packaging tools smart enough to know that some parts of the debian/ is from orig.tar.gz, and some are from .diff.tar.gz...?
[18:11] <nxvl> eddyMul: build tools doesn't work this way
[18:12] <nxvl> when you first package something there is no diff.tar.gz
[18:12] <nxvl> you only have a orig.tar.gz and then they create the diff.tar.gz
[18:13] <nxvl> the diff.gz is not anything but a patch
[18:14] <nxvl> which is applied to the source (extracted from orig.tar.gz) so in practical way yes, they are smarter enought
[18:14] <nxvl>  QUESTION: what about versioning for these native debs?
[18:14] <nxvl> it doesn change anythink
[18:14] <eddyMul> nxvl: got it. thanx.
[18:15] <nxvl> sorry
[18:15] <nxvl> iÂ'm wrong it actually changes it
[18:15] <nxvl> you don't need to use -XubuntuY part anymomre
[18:15] <nxvl> just the upstream version number
[18:15] <nxvl> so if it is 0.8
[18:16] <nxvl> your ubuntu version is still 0.8 not 0.8-0ubuntu1
[18:16] <nxvl> BUT if you made ubuntu changes to it, you need to version it on this way
[18:16] <nxvl> ok now move on
[18:16] <nxvl> One of the hardest part i found when i start
[18:17] <nxvl> was to find the right bugs to start working with
[18:17] <nxvl> you can look at are the bitesize bugs
[18:17] <nxvl> you can fin them here -> https://edge.launchpad.net/ubuntu/+bugs?field.tag=bitesize
[18:17] <nxvl> But what are those bitesize things?
[18:18] <nxvl> They are bugs that you can fix easy
[18:18] <nxvl> don't worry if it's not easy for you, take on count that you aren't familiar with packaging
[18:18] <nxvl> but they are bugs of easy fixing where you can practice your packaging more that focusing on the fix
[18:18] <nxvl> so they are a really good point to start with
[18:18] <nxvl> on this packages the fixes are most of them simple ones
[18:19] <nxvl> add somthing to the man pages, add some man pages and such easy things
[18:19] <nxvl> so you can only break your head with the packaging part if the fix
[18:19] <nxvl> Ok, you are having trouble and want someone to help you?
[18:19] <nxvl> there is an option on LP called "Mentoring available" (yes, the light green button)
[18:20] <nxvl> on this button (which on ubuntu LP page will take you to https://edge.launchpad.net/ubuntu/+mentoring)
[18:20] <nxvl> you will find a list of bug reports which someone has offered to help new contributors with
[18:20] <nxvl> so for example take Bug #174252
[18:21] <nxvl> (https://bugs.edge.launchpad.net/ubuntu/+source/libungif4/+bug/174252)
[18:21] <nxvl> you can see that in this bug sais "Mentors: Jonathan Riddell" near the white cross on the red background
[18:21] <nxvl> that means that Jonathan is offering his help on this bug, so you can work on it and ping him for help
[18:22] <Riddell> moi?
 QUESTION: Does this bitesize fixing mean to make a new package or to fix a bug inside the software/project?
[18:22] <nxvl> jsauer: fix/edit an existing one
[18:22] <nxvl> jsauer: those are real bug reports that some developers mark as bitesize as they are easy to fix ones
[18:23] <nxvl> that means that some user report it and ask us to change something but the developers realize it was easy to fix, so they mark them for the new ones :D
 QUESTION: man pages: where can I find a guide to writing man pages?
[18:24] <jsauer> nxvl: ok now I understand, thanks
[18:25] <nxvl> sorry i had connection problems
[18:26] <nxvl> eddyMul: i not sure, but there is a graphical tool for it
[18:26] <nxvl> itÅ's called manedit IIRC
 QUESTION: If I understood correctly, unless there is a mentoring available sign in the bug, we are pretty much on our own?
[18:26] <nxvl> InsClusoe: not that drastic
[18:26] <nxvl> you can always as on #ubuntu-motu or on the Mailing list
[18:27] <Solarion> looks good for manpages  ---->  http://www.schweikhardt.net/man_page_howto.html
[18:27] <nxvl> BUT the mentoring available means that you will have someone taking care of the fix with you as a plus
[18:27] <InsClusoe> nxvl: hmm..  thanks.
[18:28] <nxvl> but you can always ask in the IRC or the ML or in the LP bug report also
 QUESTION: manpages: is there a "documentation" guide to it, where it talks about what should be in a man page (how detailed should the man page be, etc)
[18:28] <nxvl> eddyMul: i really don't know
[18:28] <nxvl> eddyMul: i'm not a man pages expert, but they should be something like that
[18:28] <nxvl> ok
[18:28] <nxvl> let's move on
[18:28] <nxvl> There is also a Big TODO list for MOTU
[18:29] <nxvl> you can find it here -> https://wiki.ubuntu.com/MOTU/TODO
[18:29] <nxvl> you can find there a lot of task to do, most of them bitesize ones
[18:29] <nxvl> also there is a problem i don't know why ubuntuwire is down
[18:29] <nxvl> but i hope it to be up soon
[18:30] <nxvl> you can find a lot of easy to resolve bug reports in there
[18:30] <nxvl> there are debian bugs that maybe are also present in ubuntu
[18:30] <nxvl> and we need people to check if they are also present
[18:31] <nxvl> and if it is so try to fix them or include/adapt the debian patch which may be on BTS
[18:31] <nxvl> also you can see on the bottom of the TODO wiki page a table with some bugs
[18:32] <nxvl> there are some unchecked bugs to work with
[18:32] <nxvl> the first table are bitesize ones
[18:32] <nxvl> so you can alwas take a look and work with them
[18:32] <nxvl> the table is updated every week (monday ?) so there is always something new
[18:33] <nxvl> also most of them only need a triager
[18:33] <nxvl> so don't be scared by hard bugs, you will help a lot changing their status and/or asking for more information from the reporter
[18:34] <nxvl> so that the developers can fix them easy
[18:34] <nxvl> any questions so far?
[18:35] <nxvl> ok
[18:35] <nxvl> it seems there is no questions
[18:35] <nxvl> so
[18:35] <nxvl> let's move to TODO/BUGS
[18:36] <nxvl> So, you want to contribute but you don't feel you are ready for edit code and develop bug fixings?
[18:36] <nxvl> you can find som other ways to contribute with bug reports
[18:36] <nxvl> here -> https://wiki.ubuntu.com/MOTU/TODO/Bugs
[18:37] <nxvl> (yes, if you want you can also fix those bugs)
[18:37] <nxvl> in those bug "categories"
[18:37] <nxvl> there are some that only need to check if the status if correct
[18:37] <nxvl> if it is still present
[18:38] <nxvl> or if the work in progress is actually in progress and has not been losed on his way
[18:38] <nxvl> it's called triage, you only need to take a look at bug reports and ask for information
[18:38] <nxvl> find the package to which a bug report belongs
[18:38] <nxvl> tag it or mark it with the correct Status
[18:39] <nxvl> and some other which are already fixed but the fix isn't included yet
[18:39] <nxvl> that means that someone has included a patch, but hasn't package it
[18:39] <nxvl> (yes this happends, my first contribution was a patch of the source which i didn't package)
[18:40] <nxvl> so you only need to deal with packaging
[18:40] <nxvl> other way to contribute is to ping upstream
[18:40] <nxvl> you need to keep in mind that upstream knows theirs packages well
[18:40] <nxvl> so they will maybe find the best solutions for bugs
[18:41] <nxvl> so you can not fix the bug but report back to upstream
[18:41] <nxvl> or to the debian maintainer by filling a bug on BTS
[18:41] <nxvl> and this way you help to resolve a bug without coding nothing
[18:42] <nxvl> also you need to coordinate always with upstream because maybe they have already fix this bug or they are working on some patches for it
[18:43] <nxvl> so try to avoid the duplicity of efforts and ping them
[18:43] <nxvl> LP has also an option to link upstream bug reports to the LP one
[18:43] <nxvl> please use it as much as you can so it's easier to find if upstream has something to say about the report
[18:44] <nxvl> but be carefull, don't report everything, there are some reports of ubuntu and nothing else that ubuntu
[18:44] <nxvl> so be carefull and check if it's also present on upstream, it may not be
[18:45] <nxvl> ok
[18:45] <nxvl> is there any questions?
[18:45] <nxvl> or something you want to know i haven't talk about?
[18:46] <nxvl> are you alive?
[18:46]  * eddyMul thinks he's alive
[18:46] <nxvl> heh now i feel less lonely :D
[18:46] <Iulian> I think this one is pretty easy to understand.
[18:47] <Iulian> So, no questions from me.
[18:47] <InsClusoe> am here as well.... Picked up a bite sized bug.  :-)
[18:47] <Iulian> Heh, already?
[18:47] <Iulian> That's great!
[18:47] <nxvl> ok
[18:47] <nxvl> sorry i was having conection problems again
[18:48] <nxvl> mi ISP is not as good as it should be
[18:48] <Iulian> nxvl: Change it then.
[18:48] <nxvl> InsClusoe: Great!
[18:48] <nxvl> Iulian: i at work, so i can't
[18:48] <nxvl> ok
[18:48] <nxvl> so let's move to the mentoring program
[18:48] <nxvl> i thing i have already give you a lot of resource to work with
[18:49] <nxvl> when you feel you are a little more involved you can ask for a mentor
[18:49] <nxvl> (see https://wiki.ubuntu.com/MOTU/Mentoring)
[18:49] <nxvl> who will help you on your way to become a MOTU
[18:49] <nxvl> learn more about packaging
[18:49] <nxvl> and introduce you to the community
[18:50] <nxvl> BUT they won't think for you
[18:50] <nxvl> the will point you to documentation
[18:50] <nxvl> ask you to reach a goals and/or make some task
[18:50] <nxvl> and guide your way
[18:50] <nxvl> also he/she will not be your only resource of help
[18:51] <nxvl> you can always attend to the Q&A sessions, or packaging 101 that dholbach always do
[18:51] <nxvl> or ask on the #ubuntu-motu IRC channel
[18:52] <nxvl> there is always someone awake that wants to help
[18:52] <nxvl> don't feel scare of asking
[18:52] <nxvl> also you can always use the Mailling lists
[18:52] <nxvl> or put your questions on the comments of the LP bug reports
[18:52] <nxvl> there is always someone checking them
[18:53] <nxvl> well, now i have made my patch, how do i get it uploaded?
[18:53] <nxvl> there is a sponsoring process and team
[18:54] <nxvl> you only need to suscribe the ubuntu-universe-sponsors or ubuntu-main-sponsors and wait for them to check it and upload them
[18:54] <nxvl> but be patient, keep in mind that all (most?) of us are voluntaries
[18:54] <nxvl> and have other works and things to do
[18:55] <nxvl> not only ubuntu developing
[18:55] <nxvl> So i think this is it, thanks for comming and have a nice hack
[18:55] <nxvl> any one has some last questions?
[18:55] <nxvl> or comments?
[18:55] <dustinlange> how much time do you spend on being a MOTU?
[18:56] <nxvl> spend is hours in a day or as in time i'm involved?
[18:56] <nxvl> as in*
[18:56] <dustinlange> in hours a week or so - or whatever makes sense to you ;-)
[18:56] <nxvl> heh
[18:56] <nxvl> mm
[18:56] <nxvl> depend on the week
[18:56] <nxvl> i have a full time work
[18:57] <nxvl> and MOTU is just a free time hobbie if want to call it so
[18:57] <nxvl> there have been entirely weeks i haven't even check my mail
[18:57] <nxvl> and some other i spend long time
[18:57] <nxvl> but is up to you
[18:57] <dustinlange> so you can decide how much time you want to spend... ok, thank you
[18:58] <nxvl> yep, this is a free time job
[18:58] <nxvl> no ones tell you how much time you need to spend
[18:58] <InsClusoe> This might interest some ppl.. https://wiki.ubuntu.com/5-A-Day
[18:58] <nxvl> but if you say you will do something you need to do it (or try to), as you gave your word
[18:59] <nxvl> ok
[18:59] <nxvl> we have 2 minutres left
[18:59] <nxvl> and seb128 has already come to talk
[18:59] <nxvl> any last question?
[18:59] <seb128> nxvl: feel free to finish, I'm not in a hurry ;-)
[18:59] <nxvl> seb128: i have not much more to say :D
[18:59] <nxvl> seb128: just asking questions
[19:00] <nxvl> ok, so no one has more cuestions
[19:00] <nxvl> i think this is it
[19:00]  * nxvl HUGS everyone
[19:00]  * nxvl HUGS everyone
[19:00] <nxvl> thanks for comming! i hope it helps you
[19:00] <nxvl> oh! i was forgoting
[19:01] <dustinlange> nxvl, thank you!
[19:01] <nxvl> the MOST important thing to become a MOTU and be involved in Ubuntu is to HUG everyone
[19:01] <nxvl> we are HUGGY Developers :D
[19:01] <nxvl> now it's seb128 time
[19:01] <Iulian> Aww, thanks nxvl
[19:01] <nxvl> he's one of our best Desktop hackers
[19:01] <nxvl> and his kicking as in the desktop team
[19:02] <nxvl> so don't miss his talke
[19:02]  * nxvl waves on seb128 
[19:02] <seb128> thanks nxvl
[19:02] <seb128> hello everybody
[19:02] <Picklesworth> Hm... Hello :)
[19:02] <seb128> I'm Sebastien Bacher and I'm working in the Ubuntu Desktop Team
[19:03] <seb128> I'll start by presenting the team, what we do and how you can contribute
[19:03] <seb128> and then we can do questions and answers
[19:03] <seb128>  
[19:04] <seb128> First, where you can find desktop teams members or read about what the team is doing:
[19:04] <seb128> - #ubuntu-desktop on freenode
[19:04] <seb128> that's the chan where we hang and discuss work we are doing etc
[19:04] <seb128> - ubuntu-desktop@lists.ubuntu.com
[19:04] <seb128> IRC is good for quick question, and discussion but the mailing list is also a good place to discuss changes, bugs, et
[19:04] <seb128> etc
[19:05] <seb128> especially than everybody doesn't use IRC
[19:05] <seb128> - https://wiki.ubuntu.com/DesktopTeam
[19:05] <seb128> that's the wiki section concerning the team
[19:06] <seb128> we have details about the team goals and the work we are doing there
[19:06] <seb128> we use https://wiki.ubuntu.com/DesktopTeam/TODO for keeping track of what is being currectly working and what we would like to get done for hardy, etc
[19:06] <seb128> - the desktop-bugs team on launchpad for bug fixing and triaging
[19:07] <seb128> the team has a mailing list which receives all the desktop bugs
[19:08] <seb128> if you want to look at the bugs which would be nice to fix for hardy those are assigned to the team and milestone ubuntu-8.04
[19:08] <seb128> if you have issue you think should be adressed for the coming lts feel free to discuss with us to get those milestoned
[19:08] <seb128> - ubuntu-desktop team on launchpad
[19:08] <seb128> that team is not really used yet
[19:09] <seb128> but we plan to move packaging to bzr (we did experiment but there it still some work to get that as smooth as apt-get update, change, upload)
[19:09] <seb128> and the team members will have access to the packaging
[19:09] <seb128> so the membership is limited to known contributors
[19:09] <seb128>  
[19:10] <seb128> So what is our mission?
[19:10] <seb128> basically we try to provide the best desktop experience
[19:10] <seb128> for that we:
[19:10] <seb128> - keep the desktop components uptodate
[19:10] <seb128> the ubuntu team is pretty small and most of the code comes from upstream
[19:11] <seb128> we try to make sure their code is available in the current versions and as easy to use that it can be
[19:11] <seb128> - work on the usability of our existing desktop and on developing innovating new interface concepts
[19:12] <seb128> we have team members working on that
[19:12] <seb128> their goal is basically to determine what changes could improve the user desktop experience
[19:12] <seb128> and to discuss, design and implement those changes
[19:13] <seb128> the team was quite small until recently and we didn't do a lot of those
[19:13] <seb128> but that's changing ;-)
[19:14] <seb128> - triage and fix desktops bug
[19:14] <seb128> we get a lot of bugs
[19:14] <seb128> some are user question and redirected to the answer tracker
[19:14] <seb128> some are upstream issues and we try to get all the useful details and send them to the upstream bug tracker
[19:14] <seb128> some are ubuntu bugs and we try to fix those
[19:15] <seb128> we also try to help upstream fixing issues when possible
[19:15] <seb128>  
[19:15] <seb128> how we are organized?
[19:16] <seb128> we use IRC usually for discussion
[19:16] <seb128> that's because most of the people and that's a quick way
[19:17] <seb128> but we also use the mail list and encourage people to use it too when possible, because there is lot of people not using IRC and giving some activity to the list is good to get new people to participate
[19:17] <seb128> anybody can help on bug triage, just go on launchpad and look at the desktop bugs if you want
[19:18] <seb128> https://bugs.launchpad.net/~desktop-bugs/ has the list of bugs
[19:18] <seb128> there is a lot of those listed there
[19:19] <seb128> usually those which need triaging are those in the New state
[19:19] <seb128> you might prefer the https://bugs.launchpad.net/~desktop-bugs/+packagebugs view
[19:19] <seb128> that one list stats by packages
[19:19] <seb128> if you have any question feel free to ask on #ubuntu-bugs or #ubuntu-desktop
[19:19] <seb128>  
[19:20] <seb128> contributors are also welcome to help updating packages
[19:20] <seb128> we use https://wiki.ubuntu.com/DesktopTeam/TODO for that
[19:20] <seb128> we claim packages update we are working on there
[19:20] <seb128> the page is being redesigned right now so there is a list without a lot of things listed
[19:21] <seb128> but the goal is to let people know which packages are being actively maintained and which ones are not
[19:21] <seb128> if you have special interest in a package and want to be the contact for it let we know ;-)
[19:21] <seb128>  
[19:22] <seb128> we are also trying to move the packaging to bzr
[19:22] <seb128> there is still some usability issue there
[19:22] <seb128> but eventually we will manage to do that soon and that will make contributors and reviewer job easier
[19:22] <seb128>  
[19:22] <seb128> you are also welcome to help fixing issues
[19:23] <seb128> if you submit a patch on a bug you can subscribe the ubuntu-main-sponsors team (or universe if the package is there)
[19:23] <seb128> we will try to do our best to review the contribution quickly ;-)
[19:24] <seb128> and again feel free to ask on IRC, the list or launchpad if you have any question on a bug or if you are trying to work on something and are not sure and what to do
[19:24] <seb128>  
[19:25] <seb128> if you have idea on what changes we could do to improve the desktop experience
[19:25] <seb128> either small things we can change for hardy
[19:25] <seb128> or new inovation for the next cycles
[19:25] <seb128> you can also join IRC or the list and discuss those
[19:25] <seb128> we always welcome ideas and discussions ;-)
[19:25] <seb128>  
[19:26] <seb128> that's about it for what the team is doing
[19:26] <seb128> so if you have questions now feel free to ask in #ubuntu-classroom-chat
[19:26] <seb128> I'll pick questions there and reply on this chan
[19:27] <seb128> hum
[19:27] <seb128> no question then?
 QUESTION: Will we have a tablet edition like Windows XP does?
[19:28] <seb128> I don't think there is anything table specific planned no
[19:28] <seb128> the mobile team is working on a mobile edition
[19:28] <seb128> I don't know if that's far from what is required on a tablet device though
[19:29] <seb128> might be a good project for a team of people interested in tablets though ;-)
[19:29] <InsClusoe> Hmm... ok.
[19:29] <InsClusoe> :-)
[19:29] <seb128> I know we have applications like xournal which let you take notes on a tablet
[19:30] <seb128> and I've seen people using Ubuntu on a tablet
[19:30] <seb128> not sure if there is a real need for a specific edition though ;-)
[19:30] <seb128>  
[19:30] <seb128> next? ;-)
 QUESTION: is there a policy for correct units of measure for Ubuntu applications? specifically KiB vs KB and the like?
[19:30] <seb128> hum hum
[19:30] <seb128> hum hum hum
[19:30] <seb128> not really ;-)
[19:30] <seb128> we basically use whatever GNOME is using right now
[19:31] <awalton__> I guess more specifically, should there be?
[19:31] <seb128> that's a controversial topic I think
[19:31] <awalton__> or is that better a discussion for the list/later?
[19:31] <seb128> there is quite some people who are reluctant to use the new units
[19:32] <seb128> I think there was a discussion on #ubuntu-devel some time ago
[19:32] <seb128> you can look in the archives
[19:32] <awalton__> will do. thank you.
[19:32] <seb128> and it has been discussed upstream on the gnome-vfs bugzilla
[19:32] <seb128> but none reached a consensus I think
[19:32] <seb128>  
 QUESTION: How is the relationship with Debian desktop team? How is the procedure to update packages: wait for Debian (and request a sync) or just do it?
[19:33] <seb128> that's a good question ;-)
[19:33] <mruiz> :-)
[19:33] <seb128> we try to be in sync with Debian when possible
[19:33] <seb128> we didn't do an optimal job there until now I think
[19:33] <seb128> but we have quite some people in the ubuntu team which are also in debian pkg-gnome
[19:34] <seb128> and some active new people who are trying to get packages in sync whenever it's possible
[19:34] <seb128> lool, pochu and slomo are good example and have been doing great work there ;-)
[19:34] <seb128> we try now to keep the platform packages in sync
[19:35] <seb128> desktop applications are not that easy because we often have changes (like launchpad integration) and debian doesn't has the ressources to deal with unstable series packaging
[19:35] <seb128> mruiz: does that reply to the question?
[19:36] <seb128> we welcome people who try to work with debian to lower the delta ;-)
[19:36] <seb128>  
 QUESTION: Will there be a no services-on-on-default install-option ;-) for Ubuntu-lite in the future. kind like openbsd does? Will there be "hardened" kernels?
[19:36] <mruiz> seb128, thanks ;-)
[19:36] <seb128> no idea about that, that's not really an ubuntu-desktop thing
[19:37] <seb128> that looks rather an installer option or a derivative thing
[19:37] <seb128> I don't know about any work being done in this direction
[19:37] <seb128> but we have this "no open port" policy by default
[19:37] <seb128> which is slightly modified for avahi nowadays
[19:38] <seb128> there is an ubuntu-hardened team though, you might want to bring the subject there
[19:38] <seb128>  
[19:38] <seb128> next?
 QUESTION: Does Desktop team have a mentoring plan to encourage new members (packagers)?
[19:39] <seb128> nothing desktop specific no
[19:39] <seb128> people usually starts in the MOTU land
[19:39] <seb128> we welcome people starting by contributing on desktop packages and are happy to reply to their questions too
[19:39] <seb128> we have sponsor teams and there is a mentoring project too
[19:40] <seb128> but for most of the packaging there is nothing desktop specific and no need to have a special effort there I think
[19:40] <seb128>  
[19:40] <seb128> next?
[19:42] <seb128> no other question?
[19:45] <seb128> ok, so it seems there is no other questions
[19:45] <seb128> thank you everybody
[19:45] <mruiz> thanks seb128
[19:45] <daishujin> Thank you!
[19:45] <awalton__> thank you seb128.
[19:46] <seb128> anybody interested in joining the team maybe? ;-)
[19:46]  * ember hugs seb128
[19:46] <awalton__> +1 from me seb.
[19:46] <seb128> ah, another question
 QUESTION: How is usability measured? Like for example, take the shutdown dialog. When you decide that the user is getting swamped with too many confusing choices... maybe all he needs is 3 or 4 simple buttons most of the time?
[19:47] <seb128> InsClusoe: usually we discuss changes at UDS, write specs, get those approved and implement the changes
[19:47] <seb128> the process is open and you are welcome to participate in discussions or comment on the spec, etc
[19:48] <seb128> speaking about this dialog, that is being redesigned
[19:49] <seb128> the spec is listed on https://wiki.ubuntu.com/DesktopTeam/Specs
[19:49] <InsClusoe> seb128: Great.. Thanks. Can't wait to see the new dialog. Apologies. I didn't notice that you had closed the session and popped my question.
[19:49] <seb128> that's likely something that will be worked next cycle
[19:50] <seb128> InsClusoe: I didn't really close, we still have some minutes, we just ran out of questions ;-)
[19:50] <seb128>  
 QUESTION to you actively solicit user input for these types of questions?
[19:51] <seb128> having users opinion is always something useful ;-)
[19:51] <seb128> the distribution is for users
[19:51] <seb128> but better to have constructive comments
[19:51] <seb128> one way users comment about those specification is usually by adding comments on the wiki pages
[19:52] <snewland> but do you ACTIVELY seek it or just hope it happens?
[19:52] <seb128> you can also write to the list if you have a specific concern
[19:52] <seb128> the process is open, we mail about specifications, and let know that comments are welcome
[19:52] <seb128> we do go pinging people to have their opinion though
[19:53] <seb128> *don't*
[19:53] <seb128> do you think we could do things better in this perspective?
[19:53] <seb128> *comments are welcome* ;-)
[19:53] <seb128>  
 QUESTION: Along the same lines, do you guys do any usability studies?
[19:53] <seb128>  
[19:54] <seb128> as said the team was pretty small until now and we didn't really have ressources for that
[19:54] <seb128> now we have people working on usability in the team
[19:54] <daishujin> so there are plans for this the?
[19:55] <daishujin> s/the/then/
[19:55] <seb128> yes
[19:55] <seb128> in the limit of what we can do with the ressources we have
[19:55] <hltpyldr> Sorry to be a late arrival.  When do these sessions occur on #ubuntu-classroom?  Are they geared towards packaging?  Will these sessions continue through the week, or for today only?  I am new to #ubuntu-classroom.  Thanks!
[19:55] <seb128> hltpyldr: you have those informations in the topic I think
[19:56] <seb128> ok
[19:56] <hltpyldr> thank you.
[19:56] <seb128> the session slot is over
[19:57] <seb128> thanks everybody
[19:57] <seb128> next on the schedule is "SRU/Security Updates"
[19:57] <DktrKranz> here we are :)
[19:58] <emgent> :D
[19:58] <DktrKranz> Hello everybody, you brave souls interested in post-release madness!
[19:58] <DktrKranz> I am Luca Falavigna, a volunteer MOTU and SRU enthusiast.
[19:59] <DktrKranz> as seb128 just said, now we speak about SRU and Security Updates
[19:59] <DktrKranz> Now I'll introduce briefly what SRUs are and leave room for some questions before talking about the process behind Ubuntu updates.
[19:59] <DktrKranz> After that, William Grant (aka Fujitsu) will talk about security updates.
[19:59]  * Fujitsu waves.
[20:00] <DktrKranz> SRU is the acronym for Stable Release Updates.
[20:00] <DktrKranz> These updates are meant to fix non security-related bugs affecting supported Ubuntu releases (currently they are Dapper, Edgy, Feisty and Gutsy).
[20:00] <DktrKranz> Common examples include packages which fail to build from source, have unmet dependencies or crasher bugs, but has no direct security impact (such as
[20:00] <DktrKranz> privilege escalation or buffer overflows).
[20:01] <DktrKranz> Since stable releases are used by a much wider audience than development ones, additional care should be involved in the process, but it is quite simple anyway :)
[20:02] <DktrKranz> Starting point is https://wiki.ubuntu.com/StableReleaseUpdates, where you will find every informations related to SRUs.
[20:02] <DktrKranz> Please everybody have a look at it :)
[20:02] <DktrKranz> Not every bit is useful for common users/developers, basically just the first half is ("Why", "When" and "How" up to point No. 2).
[20:04] <DktrKranz> If you haven't questions, let's move to the playground, then
[20:05] <DktrKranz> When a bug is SRU-worthy? It is described in "When" section in https://wiki.ubuntu.com/StableReleaseUpdates.
[20:05] <DktrKranz> If your favourite app crashes or it is uninstallable, a SRU will be granted :)
[20:06] <DktrKranz> There are many other cases, and they are listed in the above page. Have a good look at it.
[20:07] <DktrKranz> ~motu-sru team is responsible to approve a SRU candidates for Universe packages, ~ubuntu-sru does the same for main packages.
[20:08] <DktrKranz> If you want a bug to be reviewed, just subscribe the right team and provide the informations required in "How", "Propose" section.
[20:08] <DktrKranz> The most important ones you need to provide are:
[20:09] <DktrKranz> 1) A good TEST CASE, placed into the bug description field, stating how to reproduce the bug (step by step) and the expected behaviour.
[20:09] <DktrKranz> 2) Explain if (and how) the problem has been fixed into the development version (Hardy, at the moment), this way we avoid regressions.
[20:10] <DktrKranz> Usually, we don't upload SRU candidates if development version has not been fixed
[20:11] <DktrKranz> 3) Attach a candidate debdiff for review. It must contain code to fix the given bug *only*, no additional (or cosmetic) changes are allowed unless approved in another SRU request.
[20:12] <DktrKranz> When preparing debdiffs, the most difficult part of the process is writing the changelog entry. I've seen several SRU candidates rejected due to inaccuracies in changelog, so additional care is a must here :)
[20:13] <DktrKranz> A good changelog entry must have these requisites:
[20:13] <DktrKranz> 1) Point to the corresponding Launchpad bug (LP: #xxxxxx). *Always* remember to double-check it to be correct.
[20:14] <DktrKranz> 2) Target must always be "$release-proposed". "$release" or "$release-updates" are not allowed. For instance, if you want to prepare a SRU for Gutsy, target must be gutsy-proposed. You can use "dch -D $release-proposed" command to set it automatically.
[20:15] <DktrKranz> 3) Version must be set in order to avoid conflicts with past, current or future versions of the package.
[20:15] <DktrKranz> Versioning scheme is a bit different from the one you usually see in development releases, it is not complex but has several variants to avoid conflicts (as mentioned above).
[20:16] <DktrKranz> A couple of examples now:
[20:16] <DktrKranz> foo_0.1-1ubuntu1 would become foo_0.1-1ubuntu1.1 (we add ".1" to the existing version)
[20:17] <DktrKranz> bar_0.2-1 would become bar_0.2-1ubuntu0.1 (ubuntu0.1 is used to avoid conflicts with a hypotetical bar_0.2-1ubuntu1 in a newer release).
[20:18] <DktrKranz> If you have doubts about which version to use, you can ask ~motu-sru or ~ubuntu-sru team members for an advice, they will be happy to answer :)
[20:18] <DktrKranz> Ok, let's stop here, feel free to ask if you have questions.
[20:21] <DktrKranz> It seems not, so let's move on.
[20:22] <DktrKranz> If you are not developers, you can help to check if a SRU candidate is good.
[20:22] <DktrKranz> http://people.ubuntu.com/~ubuntu-archive/pending-sru.html is a wonderful place to start. It lists SRU candidates still lying in -proposed and which require verification from ~sru-verification team.
[20:22] <DktrKranz> Again, please everybody have a look at it.
[20:23] <DktrKranz> As users, you can pick up one of the package listed there and try to test if it works for you.
[20:24] <DktrKranz> Just follow instruction given in TEST CASE (that's why a good TEST CASE is required: it speeds up verification phase) and attach your results in the corresponding bug report.
[20:24] <DktrKranz> Your reports will improve overall quality of the SRU process, so a huge thank you for your precious comments :)
[20:25] <DktrKranz> If you have questions, please fire them.
[20:26] <DktrKranz> After that, Fujitsu will discuss about security updates.
[20:27] <emgent> :)
 DktrKranz: Looking at feisty on that page. All updates appear to be language packs. How do we test them? The launchpad page doesn't list the bugs fixed in those updates or details of changes made.
[20:28] <DktrKranz> You are right, langpacks have been recently uploaded
[20:28] <DktrKranz> I think they do not receive special verification, since it is a procedure put in place by our archive-admins
[20:29] <DktrKranz> They are regularly scheduled for translation updates
 QUESTION: What are the changes we should look for if we try these translation updates on our machines? Where are these listed?
[20:31] <DktrKranz> Changes should be related to translation itself
[20:31] <DktrKranz> Typos, untraslated strings, and so on. Log is kept in Rosetta.
[20:33] <InsClusoe> ok.. I was looking for the word 'Rosetta' then.. :-)
[20:33] <DktrKranz> Rosetta is Launchpad translation platform
[20:34] <DktrKranz> https://translations.launchpad.net/
[20:35] <DktrKranz> I'm not comfortable with Rosetta enough to detail how it works, it could be material for an interesting #ubuntu-classroom session :)
[20:37] <InsClusoe> DktrKranz: Thanks...
[20:37] <DktrKranz> Fujitsu, audience is yours!
[20:37]  * Fujitsu appears.
[20:37] <Fujitsu> Well...
[20:38] <Fujitsu> Security updates are pushed out to fix important security issues in supported Ubuntu releases.
[20:38] <Fujitsu> The preparation is very similar to SRUs, in that the changes must be absolutely minimal, and very well tested.
[20:39] <Fujitsu> Unfortunately, the nature of security issues often means we need the update pushed out ASAP, so testing often can't be done as much as we'd like.
[20:40] <Fujitsu> It's a messy job, but someone needs to do it, and we need as many hands on it as we can get.
[20:41] <Fujitsu> The wiki page describing the procedure is at https://wiki.ubuntu.com/SecurityUpdateProcedures.
[20:42] <Fujitsu> There are a couple of differences from SRUs, the main one being that there is no waiting period in -proposed (the packages don't go into -proposed at all), so no verification team.
[20:42] <Fujitsu> A member of the Canonical security team reviews the patch, and publishes it immediately if it's deemed suitable.
[20:43] <Fujitsu> This is another difference from the SRU procedure. Only the Canonical security team can upload to -security, so updates often block on them.
[20:44] <Fujitsu> Of course, before we can fix issues, we need to identify and prioritise them.
[20:45] <Fujitsu> We have the ubuntu-cve tracker for this, which reads the published list of CVEs, and allows us to mark which packages and Ubuntu releases are affected by each issue, if any.
[20:45] <Fujitsu> It's quite a task to keep it up to date, unfortunately.
[20:45] <Fujitsu> (it can be found at https://launchpad.net/ubuntu-cve)
[20:46] <InsClusoe> Fujitsu: Broken link^?
[20:46] <Fujitsu> Argh, true. ubuntu-cve-tracker, sorry.
[20:46] <InsClusoe> np.. :-)
[20:48] <Fujitsu> Versioning in security updates can be very hard to get right, as we normally use an identical scheme to that used in SRUs.
[20:49] <Fujitsu> This means that unless very careful checking is done, SRUs can be accidentally reverted in security updates, or vice-versa.
[20:50] <Fujitsu> Any questions?
[20:52] <Fujitsu> < daishujin> QUESTION: Why use the same versioning scheme?
[20:53] <Fujitsu> We need to maintain compatibility between the two versioning schemes so we can have SRUs upgrading over security updates (once the security update is integrated), and potentially vice-versa.
[20:53] <Fujitsu> If we chose a radically different scheme, this would be much harder, and you'd end up with horrible hybrids in many packages by the end of a release's support cycle.
[20:54] <Fujitsu> < daishujin> QUESTION: How often is this a problem?
[20:54] <Fujitsu> Not very frequently, I don't believe, but I haven't got any numbers.
[20:55] <Fujitsu> It's normally fairly easily resolvable, though it may require coordination with SRU teams to get an updated SRU out quickly.
[20:57] <DktrKranz> pending-sru has "Superseded by -security" section which notes that.
[20:58] <Fujitsu> Ah yes, forgot about that.
[20:59] <Fujitsu> Well, that'd be the end, I guess... Any last-30-seconds questions?
[21:05] <jsauer> Thanks, DktrKranz and Fujitsu
[21:05] <DktrKranz> anytime :)
[21:06] <DktrKranz> This is all for today. Hope to meet you here tomorrow!
[21:06]  * InsClusoe thanks DktrKranz and Fujitsu for their time and effort.
[21:07] <jsauer> rarely hugging after this session ;)
[21:07] <eddyMul> jsauer: not true
[21:07]  * eddyMul hugs jsauer
[21:07] <eddyMul> :)
[21:07] <jsauer> nice, ;)
[21:08] <daishujin> see ya tomorrow guys
[21:08] <eddyMul> wishing there's a /we IRC command. Then we can do "/we group hug"   :)
[21:09] <InsClusoe> :-)
[22:06] <joseee1985> test
[22:16] <regel> test2