=== _Turf is now known as Turf [01:35] bashohII> おはよう〜 [01:35] Hello [01:36] にほんじんですか？ [01:36] はい [01:36] おぉ〜 [01:37] 関東からですか？ [01:37] はい [01:37] 神奈川です [01:37] ＠＿＠ [01:38] 神奈川オールスターですか？ [01:38] SLAM DUNKから [01:38] 湘南ボーイです。 [01:38] www [01:39] 爆走族＠＠？ [01:39] ゴールド免許のらいだ～ですｗ [01:40] そうね〜www [01:40] Alucard > 日本人ですか？ [01:40] bashohII> ホンコンじんです [01:40] ４６４９ね [01:43] 你的日语很好 [01:43] bashohII>謝謝您 [01:44] 我已经留学了在中国 [01:44] bashohII> おぉ〜 [01:44] "我已经在中国留学了" これでいいよ〜：P [01:45] 以后也请多多关照 [01:45] 谢谢您 [01:45] bashohII> 在中國的生活怎樣? [01:45] 很好 [01:46] bashohII> これから４６４９ [01:46] 我在沈阳 [01:46] ｋｋ [01:46] 沈陽不錯的 [01:48] bashohII> 有吃過了什麼不錯的東西呢? [01:50] 写简体字可以吗？ [01:50] 現在はできない〜XD [01:51] ｋｋ [01:51] 看不懂嗎? [01:51] 還是看不到? [01:51] 看不懂 [01:52] おぉ〜すまん [01:52] 有的汉字不能读 [01:53] 显示不到吗? [01:53] あはっは〜忘了可以使用firefox的extension [01:54] 可能表示 [01:58] 但繁体字读得很难 [01:59] 哈哈~只是简体字简化程度太高了~ [02:00] 学的时候太乐 [02:00] 我还学口语 [02:01] 国语吗(國語嗎)? [02:01] 听的时候太难 [02:02] 普通话 [02:03] 哈哈~也是呢~国语中有很多字词跟日语近似(哈哈~也是呢~國語中有很多字詞跟日語近似) [02:04] 对 [02:05] 但，在中国的时候忘了日语ｗｗｗ [02:05] 也有点字词的意思跟日语一样呢~(也有點字詞的意思跟日語一樣呢~) [02:05] www [02:08] 现在我有在日本国的中国人的朋友 [02:08] @@ [02:10] 跟一起聊天儿的时候，不要汉字ｗｗｗ [02:10] bashohII> 有来过香港吗(有來過香港嗎)? [02:11] bashohII> 哈哈~ [02:12] 以后，我想去香港 [02:12] 好~^^~ [02:12] 我已经去澳门 [02:13] 但，我不能广东语 [02:13] 呵呵~说普通话也行的喔~(呵呵~說普通話也行的喔~) [02:16] 以后也请多多关照^^ [02:16] 猪排面包也有吃过吗(豬排麵包也有吃過嗎)? [02:17] 没有经验 [02:18] 好吃吗？ [02:18] もちろんだよ〜：P [02:19] 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] こんど、中国に行ったら食べるよ。 [02:19] ｋｋ [02:20] 明天有课可以上了(明天有課可以上了) [02:20] 中国人有句说话"民以食为天"(中國人有句說話"民以食為天") [02:22] 南方的料理是很好 [02:23] 我，喜欢周杰伦ｗｗｗ [02:24] 北方的面也很好的喔(北方的麵也很好的喔) [02:24] 味不同 [02:24] 但，好吃 [02:25] 我喜欢(我喜歡)L'ARC~en~Ciel www [02:26] 我周杰伦，孙燕姿的歌常常听 [02:26] d21 UTC 1600 = d22 GMT+8 0000/d22 GMT+9 0100 [02:27] 后晚才有课,我先离开了(後晚才有課,我先離開了) [02:27] それじゃ〜 [02:28] 再见 === awalton__ is now known as edud_eoqqq === edud_eoqqq is now known as awalton__ === chuyen is now known as lyn4 === lyn4 is now known as chuyen [10:35] .names [10:37] bah [10:37] beat me === dholbach_ is now known as dholbach [14:56] #ubuntu-classroom-chat [14:56] hahah..oops === shujin is now known as daishujin [15:49] bug #192887 [15:50] nxvl_work: Wrong window probably [15:50] slytherin: nop, testing ubotu for my talk [15:51] nxvl_work: Remove the # [15:51] there's just ubuntulog in here [15:51] so no dice [15:51] bug 192887 [15:51] dholbach: it doesn't put the links to the bugs inhere? [15:52] odd, ubotu is here [15:52] oh... it is [15:52] sorry [15:52] does it need a ! [15:52] !bug 192887 [15:53] ubotu: wakeup [15:53] Sorry, I don't know anything about wakeup - try searching on http://ubotu.ubuntu-nl.org/factoids.cgi [15:53] maybe best to ask Seveas in some other channel [15:53] lol [15:53] 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] sistpoty|work: hehe [15:54] dholbach: doesn't mind i will paste the link by myself [15:55] nxvl_work: if you type manually: http://launchpad.net/bugs/ will be the shortest [15:55] dholbach: pinged him [15:55] dholbach: yep, i know [15:55] rock on [15:55] dholbach: thanks [15:59] WELCOME EVERYBODY TO DAY THREE OF UBUNTU DEVELOPER WEEK! [16:00] 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] Hurray! [16:00] hey :) [16:00] please ask questions in #ubuntu-classroom-chat, prefixed with QUESTION: [16:00] everybody excited? [16:00] ready to go? [16:00] * InsClusoe wags his tail furiously.. [16:00] hehehe :-) [16:01] https://wiki.ubuntu.com/UbuntuDeveloperWeek has the schedule of today and we'll start off with "MOTU Processes" [16:01] \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] Wooah [16:01] I gave a session with the same title yesterday and will cover the same topics because I think they're important [16:02] please don't hesitate to ask all questions related to MOTU, Ubuntu Development and other stuff you're wondering about [16:02] dholbach: i will handle the questons again [16:02] nxvl_work: you ROCK [16:02] so there's been talk about MOTU for the whole week already - I hope you all know what MOTU is about :) [16:03] MOTU is the first stepping stone into Ubuntu Development and the team who will help you get started [16:03] as member of the MOTU team you can upload packages to universe and multiverse [16:03] the process to join the team is pretty straight-forward: [16:04] - 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] - 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] and that's all there is to it [16:05] 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] 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] also you get to know a lot of people who can help you out in the Ubuntu community [16:07] the sponsorship process is explained at https://wiki.ubuntu.com/SponsorshipProcess and means in a nutshell: [16:07] - you attach your patch on a bug report [16:07] - 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] does that make sense so far? [16:08] any questions about what it's like to go through the process or anything that's unclear? [16:08] QUESTION: What's the difference between a sponsor and the REVU site? [16:09] v0lksman: good point [16:09] REVU is a page we set up quite a while ago to help us with reviewing NEW packages [16:09] NEW packages generally mean software that has never been in Ubuntu, so fresh new software :) [16:09] http://revu.tauware.de/ [16:10] https://wiki.ubuntu.com/MOTU/Packages/REVU explains how to upload software there [16:10] NEW packages are a bit different as they require much closer review, the review of a 'diff' is just not enough [16:10] gotcha...thanks [16:10] QUESTION: How is ensured that patches don't break something else inadvertently? [16:10] dholbach, http://revu.ubuntuwire.com [16:11] 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] InsClusoe: excellent question [16:11] there are a lot of things you can test: [16:11] - does it still build with the patch applied? [16:11] - is the patch integrated upstream or in debian already? [16:11] - checking the resulting binary packages: are there removed files? [16:12] - checking library packages: are there symbols which were removed from the library [16:12] - etc etc etc [16:13] 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 :) [16:14] QUESTION: How is ensured that patches don't break something else inadvertently? [16:14] 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] https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews has a good overview but is probably not complete :) [16:15] 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] Yup.. Makes sense.. Thanks. [16:15] I personally trust people more who point out that they're unsure - it's a sign of good collaboration [16:16] 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] slytherin: the process was changed back to .diff.gz [16:16] some developers found using and reviewing an interdiff to be a bit cumbersome [16:17] Makes sense. Thanks. :-) [16:17] 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] excusez-moi :) [16:18] any more questions on how to get your packages / patches included? what is expected of a MOTU or anything else? [16:18] dholbach: mi list is empty [16:19] my* [16:19] 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] every Friday at 13:00 UTC (minus the coming Friday) we have a MOTU Q&A session in this very channel [16:19] 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] also we do Packaging 101 session once a month [16:20] all of these happen in #ubuntu-classroom [16:20] other things that might be beneficial for you [16:20] - #ubuntu-motu of course :) [16:20] - ubuntu-motu-mentors@lists.ubuntu.com [16:20] don't hesitate to ask - there's always *somebody* awake :) [16:21] 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] hi there [16:22] I talked a bit about Feature Freeze earlier [16:22] FF is the time when specs that are targetted for the current release need to be in a good shape already [16:22] and for us who do package maintenance it means: stabilisation [16:22] 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] some days before the release day we enter Hard Freeze where every single change will be reviewed [16:23] https://wiki.ubuntu.com/HardyReleaseSchedule for reference [16:23] does that make sense so far? [16:24] ok, it seems so :) [16:24] another important topic is the Sync Request Process [16:24] there's always some bit of confusion about what a sync actually is [16:25] a sync means: copy the source package from debian as-is, build it in ubuntu [16:25] this implies that all changes in the current Ubuntu package are overwritten [16:25] so if you decide to ask for a sync, you need to make 100% sure it'S OK to do that [16:26] 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] you include the changelog of the debian package to indicate what has happened in the meantime [16:27] 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] they will ACK the report if it's OK, then get the ubuntu-archive team to do it :) [16:28] https://wiki.ubuntu.com/SyncRequestProcess also explains about a tool called requestsync which makes your life even easier [16:28] the same checks that InsClusoe and I talked about earlier apply to sync too [16:28] so if the synced debian package does not build on ubuntu we have a problem and need to fix it, etc etc [16:29] being in sync is a very good thing, but we need to be careful [16:29] what does it mean to be in sync? [16:30] It means we are using the latest version from upstream. [16:30] 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] in this time we will sync the newest version of the debian package automatically [16:31] 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] even better if the debian version is in sync with the version of the upstream authors :) [16:32] also: if we're not in sync we need to merge our changes manually in that green timeline of the release schedule [16:32] and that's a lot of work [16:33] 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] if we pass on our patches, we can make sure we get in sync quicker again, which we all benefit from [16:33] any questions? :) [16:33] dholbach: empty list again [16:34] nxvl_work: I just wanted to leave some time for people to ask questions :) [16:34] https://wiki.ubuntu.com/UbuntuDevelopment/Merging is a pretty good page of how to do merging [16:34] 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 [16:35] 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] 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] InsClusoe: no, as soon as a package contains "ubuntu" in the version string it is not synced [16:36] or hang on - did I understand your question correctly? [16:36] if there are no debian changes, there's nothing to sync [16:37] we can still try to pass on our ubuntu changes to the debian maintainer though [16:37] that's always advisable [16:37] James Westby and nxvl_work might have talked about a tool called submittodebian which makes the process of sending patches virtually painless [16:37] it makes use of https://wiki.ubuntu.com/Bugs/Debian/Usertagging internally [16:38] 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] 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] a few things I always highlight are: [16:40] - https://wiki.ubuntu.com/UbuntuDevelopment (for general process questions - like How does the archive work? When can I request a sync? etc) [16:40] - https://wiki.ubuntu.com/PackagingGuide (which helps with packaging, it has tutorials and everything) [16:40] - and https://wiki.ubuntu.com/MOTU (which lists team meetings, team organisation and so on) [16:41] https://wiki.ubuntu.com/MOTU/GettingStarted is the general first address :) [16:41] Who of you could imagine helping out in the MOTU team any time soon? :-) [16:41] o/ [16:42] that's all? :-) [16:42] I [16:42] * InsClusoe says yes if [soon=now]. [16:42] I'd like to try [16:42] :) [16:42] ROCK and ROLL - that's the spirit :-) [16:42] Who knows, I still have many things to learn. [16:43] What's your general impression of Ubutnu Development? Daunting? Crazy? [16:43] Impressive [16:43] HUGGY [16:43] :D [16:43] :-) [16:43] Heh :) [16:43] Iulian: impressive how? [16:44] these talks have certainly made me appreciate my desktop alot more! [16:44] dholbach: In many areas. [16:44] amazing what all of you do [16:44] I mean, I like how the team is working, helping each others... [16:44] It's really cool. [16:45] What is amazing is that you can help improve your own user experience. :-0 [16:45] Yes, indeed. [16:45] :-) [16:45] slytherin: exactly [16:45] 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] but that with some patience, some detective skills and motivation you can be part of the whole thing too :) [16:46] 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] InsClusoe: automatic testing as in how? testing of usability? [16:47] by the way: Thursday 17:00 UTC: Writing Scripts For Automated Desktop Testing (Lars Wirzenius) [16:47] Companies usually have robots for UI testing and things like that. [16:48] Lars has been putting a lot of effort into figuring out the problem of UI testing [16:48] but we benefit of course of a lot of other developers working with us [16:48] 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] some software (unfortunately not all) comes with HUGE test suites [16:49] if you look at the code of bzr for example - it's just amazing [16:50] And then there are beta testers. :-D [16:50] of course :) [16:50] QUESTION: Do the packages have associate test suites to ensure quality? [16:50] Shiv: we run regular installability test of packages and regular lintian checks too [16:51] lintian and linda are tools to check how policy compliant packages are [16:51] when it comes to test suites regarding the software itself we mostly depend on the test suites that upstream authors have written [16:51] a large degree of software written just for ubuntu has test suites too (like apport, jockey, etc) [16:52] and as far as I know the security team writes tests for the fixes they upload too [16:52] so if there should be a security regression it should be caught [16:52] QUESTION: How do you test installation and functionality of a base package (say glibc) [16:52] < Shiv> QUESTION: How do you test installation and functionality of a base package (say glibc) [16:53] :) [16:53] Shiv: piuparts is a tool that Lars Wirzenius has written which test installation of packages in a chroot (a fresh minimal environment) [16:53] libc6 is tested like all other packages too [16:53] another huge part of what we test is upgrades [16:54] we have machines doing nothing else but testing upgrades from gutsy to hardy, from dapper to hardy and so on [16:54] 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] Shiv: absolutely, which is why at least main is built with a new toolchain once it is put in place [16:55] https://wiki.ubuntu.com/HardyReleaseSchedule indicates when those tests are run [16:55] any more questions about Ubuntu Development? :) [16:56] what I like about the questions from you guys today is: you absolutely want to do it right - that's great [16:56] < Shiv> QUESTION: Is toolchain uploading done by MOTUs or core-dev [16:56] Shiv: doko is your man - he's in charge of the toolchain and an awesome guy [16:57] holas [16:57] he's employed by Canonical, a core-dev and works in the Debian Toolchain team too [16:58] more questions? :) [16:58] if not, you have two more minutes until the next session :) [16:58] thanks everybody for coming to the session! [16:58] no problem ;) [16:59] * mruiz hugs dholbach [16:59] dholbach: No, thank you! [16:59] :-)))) [16:59] * dholbach hugs Iulian [16:59] Hehe [16:59] oh.... I completely forgot something! Packaging Jams! [16:59] watch out for Packaging Jams in your area :) [17:00] ok it's 17:00 UTC [17:00] and thumper is already here [17:00] I am [17:00] dholbach: get into it now? [17:00] 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] = Hosting Code With Launchpad = [17:01] I hope you all enjoy the session and ask your questions in #ubuntu-classroom-chat [17:01] thumper: the stage is yours :) [17:01] dholbach: thanks [17:01] This is my first time working with dholbach and ubuntu open week [17:01] so be gentle [17:01] Just so I feel like I'm not just talking to myself the whole time [17:02] who is around for this one? [17:02] 0/ [17:02] 1/ [17:02] o/ [17:02] +1 [17:02] I am [17:02] cool [17:02] +1 [17:02] +1 [17:03] As dholbach said, my name is Tim and I am the team lead for the launchpad-bazaar integration [17:03] Our job as a team is to make using Launchpad with Bazaar better than the sum of the parts [17:03] Launchpad by itself is really nifty [17:03] is teh sessoin alreday running? [17:03] Bazaar by itself rocks [17:03] KEB1: yep [17:03] our job is to make using Launchpad and Bazaar together really blow your socks off [17:03] As some of you may suspect, part of this was prepared in advance :) [17:04] == Bazaar == [17:04] A very quick intro [17:04] +1 [17:04] Bazaar is a distributed version control system found at http://bazaar-vcs.org [17:04] Bazaar is installed on all ubuntu machines by default, and is the command 'bzr' [17:04] You don't need a central repository to manage your code [17:04] and that's all I'm going to say about it right now [17:05] == Launchpad == [17:05] Trying to describe what Launchpad is in just a few words is really hard [17:05] QUESTION: Sounds lame, but nevertheless - is bazaar by ubuntu and for what purpose ? [17:05] Bazaar is a community project [17:05] but several lead developers a canonical employees [17:07] Bazaar was sponsored by canonical because at the time there were no DVCS available that provided the functionality that was looked for [17:07] QUESTION: (continue) so what role does bzr play for ubuntu, or is it a standalong product ? [17:07] bzr is a standalone product [17:07] but it is also a tool for collaborative software development [17:08] more will become apparent as I go on [17:08] Launchpad aims to make it easier to collaborate in open source software development [17:08] Launchpad is a bug tracker, feature planner, translation manager, handles questions and answers, and a source code repository [17:08] or as kiko has mentioned in a blog post, a source code supermarket [17:08] What we are here to talk about today is working with code and launchpad together [17:09] (using bzr as a package management tool is a whole different session, sorry Shiv) [17:09] As far as Launchpad is concerned, code is stuff in Bazaar branches [17:09] Yes, you can put other stuff in branches too, but we think of it as code [17:10] 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] Bazaar is a relative new-comer in the version control stakes, and as such many projects use other revision control systems [17:10] Launchpad can import CVS and Subversion branches into bazaar branches and make these available through Launchpad [17:11] These are considered "imported" branches, and are owned by the vcs-imports user (https://code.launchpad.net/~vcs-imports) [17:11] 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] 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. [17:12] QUESTION: given all that Launchpad is, is it intended to be like SourceForge, Novell Forge, GNU Savannah, etc.? [17:12] Yes, and then some [17:12] So I can go `bzr branch lp:gnuhello` to get a copy of gnuhello (you can too). [17:13] 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] This is how launchpad confirms that it is you [17:13] * thumper pours more coffee [17:14] QUESTION: Why another tool (bzr) instead of adapting distributed versioning tool like hg ? [17:14] bzr and hg both have a similar basis and both started development at around the same time [17:14] bzr had a different set of ideals than hg [17:14] and we believe the future is bzr (but we are biased) [17:15] 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] I'm sure you can agree that is somewhat unwieldy [17:15] Bazaar gets shipped with a launchpad plugin which allows some nifty additions [17:15] You can tell bzr about your launchpad id by using `bzr launchpad-login` and your launchpad id [17:16] so mine would be `bzr launchpad-login thumper` [17:16] Then you can push directly to launchpad using `bzr push lp:~thumper/gnuhello/my-branch` which is somewhat shorter [17:16]