[01:56] anyone in Cali? [01:57] SpinachHead: might want to try #ubuntu-california [01:58] just trying to figure out what 1600 UTC time is here. I am stuck at work on a win computer and can't use terminal [01:58] @now [01:58] Current time in Etc/UTC: January 27 2010, 01:58:56 [01:59] 8? [01:59] i tihkn [01:59] okay, so the classes haven't started? [01:59] They started Monday.. [01:59] Each day for 5 hours [02:00] For the US, todays classes are already over [02:00] okay... I wanted the Ubuntu One class guess I missed [02:00] that was like 7 hours ago [02:01] SpinachHead, https://wiki.ubuntu.com/UbuntuDeveloperWeek see logs here [02:01] thanks [02:01] nigel_nb: Thanks [02:01] np :) [02:04] Is there a "wish list" or some other way to request a certain type of class? [02:05] ardchoille: what are you looking for? [02:05] For instance, I'd like to learn how to write apps in python-gtk and use glade to design the ui and have the glade file usable in the app. I've tried online tutorials but can never understand them [02:06] It's be nice to have a class that starts with "this is a glade file and this is how you call the file componenets in a pygtk app: or something similar [02:06] Just anidea for a class [02:06] ardchoille: have you checked out the past classes to see if anything similar has been taught? [02:06] that would help in finding someone who could teach it [02:06] I don't recall anything like that but I should check [02:07] Is there a list of past classes? [02:07] in the topic there is a link to the Classroom page... [02:07] from the classroom page there is an archive area [02:08] ardchoille, you can check MOTU school first https://wiki.ubuntu.com/MOTU/School and previous dev week session https://wiki.ubuntu.com/UbuntuDeveloperWeek/Previous [02:11] The problem is that all of the "getting started with ubuntu development" classes I find always deal with packaging an app and that's it. I never see a "how to write an app in pygtk" type of thing. While packaging is a great skill to have, it's also good to know how to write an app [02:11] but thats not what ubuntu development is... [02:12] that'd be upstream development [02:12] Ah, ok, I misunderstood the meaning of ubuntu development" [02:12] many ubuntu developers dont know how to program beyond maybe a simple bash script to run at the end of package installation [02:13] I did not know that [02:13] you might be more interested in ... i think its called gnomelove [02:14] i think thats the name of their wannabe-gnome-dev mentoring stuff [02:14] kde has "junior jobs" which are simple bugs for newcomers, but i dont know of any mentoring for "hi i want to learn qt" [02:14] and then there's kernelnewbies for people who want to learn to hack the kernel [02:15] maco: Thank you for the information [02:15] np [02:17] I always thought the packagers were programming guru's too [02:18] i know one guy who does no programming and another that knew cobol 25 years ago but didnt learn a modern language til after becoming an ubuntu dev [02:30] maco: Thank you! [02:30] maco: http://live.gnome.org/GnomeLove is an excellent starting point for what I want to do :) [02:30] great! [02:32] Hmm.. I wonder if I get good at this, I might be able to teach a class in here at some point in the future [02:32] ardchoille: sounds good to me [02:33] i need to learn where kde keeps equivalent docs. been a kde user for a year, and i still only know how to do gnome programming [03:24] someone speek portuguese? [03:25] hggdh: i think if hes around [03:35] I am here [03:35] do you speak portuguese? [03:36] cjohnston: yes, I do [03:36] linuxman: why you need Portuguese? [03:36] yes speek [03:36] vc so falam ingles [03:37] linuxman: PVT [03:37] linuxman: a liŋua oficial por cá é o ɪŋles [03:58] no hacking i are noobs [04:00] -.- [04:00] :( [04:18] hi? === jamalta is now known as jamalta-afk === Yos_ is now known as Yos === nixternal_ is now known as nixternal === SmrtySsa is now known as SmartSsa === jarlen_ is now known as jarlen [13:20] http://fc08.deviantart.net/fs71/f/2010/027/7/1/eeedebian_wmii_by_bittin.png me likes <3 === jamalta-afk is now known as jamalta === breiner is now known as breinera === cjohnston is now known as FFEMTcJ === FFEMTcJ is now known as cjohnston [15:59] WELCOME EVERYBODY TO ANOTHER FINE DAY OF UBUNTU DEVELOPER WEEK! [15:59] If you are a bit confused, have a look at - it will explain, why you are here: https://wiki.ubuntu.com/UbuntuDeveloperWeek [16:00] On an organisational note: if you have questions, please ask in #ubuntu-classroom-chat and prefix them with QUESTION: so they stand out. [16:00] Also, if you have questions but are afraid to ask in English head to one of the channels mentioned at the bottom of https://wiki.ubuntu.com/UbuntuDeveloperWeek [16:00] First up is the fantastic John Arbash Meinel - he'll talk about "Writing good test-cases"! [16:00] jam: the floor is yours! [16:01] greetings all! [16:01] I'm happy to see so many names on the channel.... hopefully you all aren't just lurking [16:01] waiting for the next speaker :) [16:01] I'm going to be pretty loose with the discussion [16:01] so feel free to ask questions [16:02] cjohnston has graciously offered to help me keep track [16:02] o/ [16:02] So what is a 'good' test case [16:02] L [16:02] ? [16:03] Generally speaking, a test case is meant to verify that something is happening correctly. [16:04] Or looking at it differently, when something *isn't* happening correctly, the test case should fail. [16:04] However, there are still a lot of subtle aspects. [16:04] I would say that the desirable features of a test case break down into [16:04] 1) Sensitivity (the likelyhood that the test case will break when something goes wrong) [16:05] 2) Specificity (the likelyhood that the test case will break and what you are testing has not gone wrong) [16:05] 3) Performance [16:05] It is easy to focus on say 1, but to have a *good* test, all 3 are important [16:06] It is great to have a huge test suite that covers every possible aspect of your code, and all permutations [16:06] but if it takes 3 weeks to run, it is often not very useful for development [16:06] Likewise, a test with low specificity will be breaking all the time [16:06] and won't really help you isolate the problem [16:07] You can argue that 4) coverage is a property, but I would argue that it is a desirable property of the whole test suite, and not a great property of a single test [16:10] Personally, I think there are a range of 'good' tests, generally dependent on what aspect you are focusing on [16:10] I personally think that having lots of focused tests is better than having a single 'test' that is testing lots of aspects [16:11] but integration tests are still useful an needed [16:11] and [16:12] So how about we put together an example [16:13] I'll use python, since that is my preferred language [16:13] and it has a decent unittest suite [16:13] QUESTION: Even after weeks of testing by most experience testers, very robust apps breakdown all of a sudden, what might be the reasons behind it? [16:14] ANSWER: I think that complexity is generally a major factor causing 'bugs' in software. [16:15] It is often considered inherent in any sufficiently developed program. [16:15] < Omar871> QUESTION: according to what I learned in college, a 'good' test is that one that makes that system break/crash, to show where the problem is, how true could that be? [16:15] Generally, this means there will be some sort of permutation of objects which has not been tested [16:15] directly [16:16] A goal of development is to manage complexity (generally by defining apis, separation of concerns, etc) [16:16] good software can then have good tests that test a subset, without *having* to manage the permutation problem [16:16] (but generally, abstractions can 'leak', and ... boom) [16:17] ANSWER : I think I understand you to mean the "inverse" [16:17] which is that a good test is one that provokes a problem in the system [16:18] I think that for a regression style test, it is certainly important that the test would trigger the bug that you are trying to fix [16:18] However, once a bug is fixed, you would certainly expect it to not provoke the problem anymore [16:19] So it is certainly important that a test exposes a weakness [16:19] I guess put another way... [16:19] If I had a bug, and wrote a test case, and it *didn't* trigger the bug, that test doesn't have a lot of worth (for fixing that bug) [16:20] (Which often accidentally happens if you fix the bug before writing the test) [16:22] n3rd: We were just discussing in our group about "coding creates bugs... are we reducing the number of bugs faster than we are creating them?" [16:24] n3rd also brings up a decent point [16:24] users often find bugs that developers don't think of [16:24] often because they use software in ways that weren't anticipated [16:25] often this goes back to the permutation issue [16:25] it isn't possible to test every possible permutation [16:25] (well, rarely possible) [16:26] < n3rd> jam, so the users are passive tester? [16:26] A file with just 20 bytes has 8^20 = ~10^48 permutations [16:27] Well, I would say that users are often pretty *active* testers [16:27] however, they don't make good automated test suites [16:27] I suppose that would be my: [16:27] 4) Reproducible [16:28] (the chance that running the same thing now will give you the same thing it gave you before) [16:28] It is somewhat related to specificity [16:28] As an unreproducible test has low specificity [16:28] (it breaks for reasons that you aren't trying to test) [16:29] I guess I should also mention... if a user used every intermediate version of my program, they'd run into a lot more bugs [16:29] As a developer I fix a huge amount of things before it gets released [16:29] it is just that often the set of *remaining* bugs [16:30] are ones that I had not anticipated very well [16:34] Anyway, I think it is useful to remember what the strengths of a given style of testing are. [16:34] You can have automated tests (unit and integration tests), manual (interactive) testing, foisting off the software on your users [16:34] etc [16:34] I do think that testing at each level is useful [16:35] and trying to test things at a the wrong level introduces more pain than benefit [16:35] Having an absolutely bulletproof piece of software that doesn't do what your users want isn't particularly beneficial [16:36] So having user testing in your feedback loop is certainly a good thing [16:36] However, giving them a buggy PoS is also not going to make them very happy [16:36] I'm certainly a fan of multi-tier testing, including automated testing [16:36] having a small fast test suite that is likely to expose bugs is nice on 'must pass before making it to trunk' [16:37] having a slower but more thorough "must pass before releasing to users" [16:37] and for some systems adding a "must be tested by a human interaction" can be inserted in there as well [16:38] If the first one takes much more than 5 minutes, it often causes grief when trying to get development done [16:38] but the second can take a day, and still not slow down your release cycle [16:44] < Omar871> QUESTION: Could the efficiency and effectivenes of the testing process depend on the licensing type of the software we are making? [16:45] ANSWER: I don't think it would change dramatically [16:46] If the license is open, it does allow users to do introspective testing which would just not be possible otherwise [16:46] however, few users can really develop your software anyway, so it certainly shouldn't be relied upon as a source of improving correctness [16:46] even if your users are very intelligent they almost always [16:46] 1) don't know your code [16:46] 2) don't have time to be doing your work for you :) [16:47] I think Linus gets a bit of a boost, because there are lots of developers on the project, not just users [16:48] Certainly a "lot of eyeballs" requires eyeballs that can see the code [16:49] and with enough, you can have a person to specialize for any given subset, which also helps in defect localization (hence 'shallow') [16:50] < hggdh> QUESTION: are there any considerations for *usability* testing (this is one thing that users would certainly be able to perform)? [16:51] ANSWER: I think that usability testing is certainly important [16:51] (10:35:23 AM) jam: Having an absolutely bulletproof piece of software that doesn't do what your users want isn't particularly beneficial [16:51] There is an argument whether this specifically falls under the standard category of 'testing' [16:52] (market research is certainly important to developing software, but it isn't "testing" :) [16:56] < strycore89> QUESTION : how is testing of graphical applications done ? (For example PyGTK apps) [16:56] IME, you can test PyGTK (and PyQt) without actually showing dialogs [16:57] both of them support updating widgets by programattically setting values [16:57] and then triggering events [16:57] In that case, they can be tested in the same fashion as any other unit testing [16:57] however, it doesn't test the visual representation [16:57] which is a valid level to test [16:58] There are also gui testing suites that can be used [16:59] I forget the exact name of one (suikili?) [16:59] Which uses screenshots [16:59] and some work for marking the regions you care about [17:01] http://groups.csail.mit.edu/uid/sikuli/ [17:02] alrightie! [17:02] thanks jam for giving this great talk! [17:02] * dholbach hugs jam [17:02] next up are henninge and adiroiban, the dynamic duo that'll explain "Launchpad Translations under the hood" to you! [17:03] Hi everybody, thanks for coming! [17:03] Today we want to help you understand the inner workings of the Launchpad Translations application (Rosetta) and take you for a walk through the source code. We hope that this will enable you to scratch your own itches you have about Rosetta and to contribute to its source. [17:05] So the intendend audience is [17:05] * Developers wanting to contribute to Launchpad Translations but are not yet familiar with the internal structure of the application. [17:05] * Interested maintainers of translations in Launchpad and translators that want to have a better understanding of how and why Launchpad Translations does what it does. [17:05] We hope that by the end of the session you have a good overview of [17:05] # how translation data is stored in LP translation (db schema) [17:05] # how the source code is organized [17:05] # what to expect when diving into the source code [17:05] # where to start when trying to hack on Launchpad Translations. [17:06] It is not the goal of this session to introduce you to Launchpad development in general. That will be covered in a different session by Karl Fogel. [17:06] We encourage you to visit that on Friday. [17:06] Thursday, sorry [17:07] Anyway, we are happy to take questions. We will keep the session open towards the end to see what questions come up and what your interests are. [17:08] We will be taking questions in intervalls, so cjohnston will nicely hold them until we ask for them. Thanks. [17:08] Go, adiroiban ;-) [17:08] Hi [17:08] I will continue with Gettext Basics [17:08] You need to understand how gettext is used to internationalize computer software. You should be familiar gettext documenation but we will give you a short run-through of those parts that are important for Rosetta. [17:09] = PO files = [17:09] Gettext stores translations in so-called portable object files, abreviated as PO files. They contain data sets of msgid and msgstr, the former containing the English original string, the later containing the translations of that string. They may be prepended by special comments that convey information about the string that is being translated, like in which source file it was found. Here is an example: [17:09] #: src/coding.c:123 [17:09] msgid "Thank you" [17:09] msgstr "Merci" [17:10] Gettext states that msgid could be anything to indentify the string in the source code and not necessarily the English original string. Using the full English original string as the msgid, though, has proven to be the most convenient way to work on translations and is _the only form_ that is fully supported by Rosetta. [17:10] The first msgid in a PO file is empty and its msgstr contains meta information about the file. The minimum information here is the MIME Content-type of the file but usually a lot of other information is included, too. [17:11] Here it is [17:11] mmsgid "" [17:11] msgstr "" [17:11] "Project-Id-Version: PACKAGE VERSION\n" [17:11] "Report-Msgid-Bugs-To: \n" [17:11] "POT-Creation-Date: 2009-01-26 12:28+0000\n" [17:11] "PO-Revision-Date: 2009-01-26 12:28+0000\n" [17:11] "Last-Translator: Foo Bar \n" [17:11] "Language-Team: French \n" [17:11] "MIME-Version: 1.0\n" [17:11] "Content-Type: text/plain; charset=UTF-8\n" [17:11] "Content-Transfer-Encoding: 8bit\n" [17:11] The standard naming convention for PO files is to use the language code, so in this case fr.po. [17:11] = Translation templates = [17:12] Questions so far? [17:12] henninge / adiroiban you aren't using slides are you? [17:13] no [17:13] < Navaneeth> QUESTION: Is gettext portable to other OS? [17:13] no slides [17:13] sorry [17:13] the content is on the wiki [17:14] Navaneeth: The PO format is machine independent. [17:15] Gettext is available on many operating systems [17:15] I don't think you need to worry for gettext portability [17:15] I will continue with PO Templates [17:15] When translatable strings are extracted from source code using xgettext or intltool, they are put into a file which is commonly referred to as the translation template. Its format is identical to that of a PO file but all the msgstr lines do not contain any translations. These files are intended to be used for creating new PO files, so they also contain the header information but with most fields left with empty or generic values. [17:16] Since a PO template is not really a separate file format it does not find much mention in the gettext documentation. Also, because its content can be generated from source any time (like during a build), most projects don't include it in their repository. Only PO files contain valuable information for a project, the translations themselves, and are therefore included in the source code repository. [17:17] The standard naming convention for PO templates is to use the translation domain with the extension .pot, for example myproject.pot. [17:18] How translations are done in the simple gettext context: [17:18] 1) To start a translation into a new language for a project, the following steps are necessary: [17:19] * Either the project maintainer or the translator creates a template from source code. [17:19] * The translator fills out the template with the translations for each msgid. [17:19] * The translator saves the file in the source tree as languagecode.po (lsee above), ususally in a directory called po. [17:19] * The translator or somebody with commit rights commits the file to the repository. [17:19] * Whenever the package is built, the translations are processed so that they are available at run-time (out of scope here). [17:20] 2) To change translations, the steps are simpler: [17:20] Sorry. Launchpad Workflow :) [17:20] When using Launchpad to translate a project, the steps are slightly different because the PO files are kept in Launchpad for the translators to work with. From Launchpad they are mirrored into the source tree to be used at build time. [17:21] * The project maintainer uploads the PO template file to Launchpad. [17:21] * Translators go to Launchpad to translate the English strings that now appear in the web interface. [17:21] * The project maintainer downloads all PO files whenever they want to, usually to prepare a release of the software. [17:21] * Nowadays the upload and download should happen automatically from and to Bazaar branches in Launchpad so that the maintainer always has a mirror of the latest translations in the branch, while changes to the PO template are automatically propagated to Launchpad. The next step will be automatic generation of PO templates from the source code in a Bazaar branch. [17:21] Questions? [17:22] cjohnston: Questions? ;) [17:22] I don't see any [17:22] cool [17:22] one just came [17:22] < Navaneeth> QUESTION: PO files need to deployed along with the application? [17:23] cjohnston: actually, they are converted to a binary format first "MO". [17:23] You will deploy the MO files (machine object) [17:23] Navaneeth: ^ [17:23] ;) [17:24] Next, we'll go into how this structure is mapped into the Launchpad database. [17:24] jtv drew up this amazing diagram: [17:24] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions/LaunchpadTranslationsUnderTheHood?action=AttachFile&do=get&target=TranslationsSchema.png [17:25] < Omar871> QUESTION: What's a PO file? [17:25] Omar871: the actual translations are stored in PO files. It contains English strings and their translation. [17:25] s [17:26] That's what translators work with when translating. [17:26] Back to database schema. [17:26] You can see the main tables used for Launchpad Translations in the digram. PO templates are mapped into the database using four tables. [17:27] POMsgID is a look-up table for all the English strings that are being translated. [17:27] So it gives each string a numeric ID. [17:27] POTMsgSet holds all the data related to an original English string as found in a PO template, one database entry per msgid entry in the file. It refers to the actual English strings only by their IDs in POMsgID. This represent one paragraph/entry from a PO template (msgid, msgid_plural, context, comments). [17:28] POTemplate holds the meta data related to a PO template as it has been imported, most notably the original path name, the translation domain, the original header and a flag if this template is active or not. [17:28] TranslationTemplateItem is a linking table because of the n:m realtionship between POTMsgSet and POTemplate which message sharing introduces. Not only does a PO template file contain multiple msgid entries, the same msgid may also appear in multiple PO template files, if the same template is used accross different series of a a project. [17:28] Questions? [17:28] cjohnston: ^ [17:29] < n3rd> QUESTION: Can we not give auto suggestions/transitions like Rosy with the DB and PO ? [17:29] n3rd: I don't know Rosy but we do have "external suggestions" in Rosetta. [17:30] That is one of the key features of it, actually. [17:30] If a string has already been translated in a different package or project, it's will be suggested to the translator. [17:31] next question [17:31] < bullgard45> QUESTION: How do you take care of that the same English phrase needs to be translated differently depending on the program at hand? [17:31] Just add a new translation [17:31] bullgard45: that's why they are just presented as "suggestions". It still takes a reviewer to acutally accept it as a translation to use. [17:32] bullgard45: a program will use a certain PO file [17:33] and you can have the same string in 2 PO files [17:33] and for each PO file to have different translations [17:33] in database terms: [17:34] You can have multiple TranslationMessage entry related to one POTMsgSet entry. I will come to that in a minute. [17:34] next question? [17:34] < n3rd> QUESTION:Would it not result in overhead when there are many revisions for the same sentence, and finally refined to perfect translation? [17:35] n3rd: it does ;-) [17:35] n3rd: we have a lot of entries in the POTranslation table. [17:36] but since we consider all those refining steps as contributions we keep them for reference's sake. [17:36] next questions? [17:36] < n3rd> QUESTION : So the alternative is ? [17:37] n3rd: none I am aware of atm... [17:37] We have been cleaning out translations of discontinued Ubuntu series. [17:38] Also, for most cases there are not that many iterations, especially if the translations are imported from upstream. [17:38] more questions? [17:38] < Emilien> Question: in a project that is oenly translated, if I modify an already translated string, does it overwrite the old translation, or is it stored as a new entry? [17:38] Emilien: new entry. [17:39] A new TranslationMessage and POTranslation entry is created. [17:39] Let me add my explanations for the remaining four tables that all deal with this: [17:39] POTranslation is a simple look-up table and holds the actual translated strings [17:39] TranslationMessage holds all the information about a translation to a specific language, like when it was done and by whom, if it was translated in Launchpad or imported from elsewhere, if it is currently used or just a suggestion, etc. For each POTMsgSet there may be multiple entries in this table, even for the same language, because any translation ever made is stored in the database, even if only the latest is actually used. [17:39] The actual translation strings are referred to by their id in POTranslation. [17:40] Language is the set of all languages known in Launchpad. This table is not specific to Launchpad Translations as it is used in other parts of Launchpad, too. [17:40] POFile represents the set of translations into a certain language for a POTemplate. If it was created by importing a PO file, it also holds some information about that file. It is not linked directly to any translation but this relationship can be derived through the Language table. [17:40] Questions? [17:40] < bullgard45> QUESTION: I have seen a lot of po files in the WWW. How are they related to Launchpad? [17:41] bullgard45: Can you be more specific about WWW, please? [17:42] as in: I did not understand the question ... [17:42] another question ? [17:42] That's it for nwo [17:42] now [17:42] adiroiban, take us into the code, please. [17:43] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/files/head:/lib/lp/translations/ [17:43] OK. we should see the Launchpad Translation folder structure [17:44] I will not describe them in alphabetic order [17:44] == Model == [17:44] * _interfaces_ contains the Zope interface definitions and schema for the objects used by the application. You will find interfaces for each of the database tables described earlier. For example, potemplate.py contains IPOTemplate. [17:44] * _doc_ contains function tests for code from model. Written as doctests. [17:44] * _model_ contains objects mapping to relational database using storm. [17:44] * _tests_ contains unit tests for code from model. [17:45] Next we have the folder containing the view layer [17:45] == View == [17:45] * _browser_ contains classes dealing with presentation logic and user interaction. [17:45] * _browser/tests_ contains unit tests for code from browser. [17:45] * _emailtemplates_ contains templates for various emails issued by Rosetta. [17:46] * _help_ contains documentation and help pages integrated with Rosetta. [17:46] * _stories_ constains functional tests for code from browser. Written as doctests. [17:46] * _templates_ contains Zope Page Templates use by the objects from browser. [17:46] * _windmill_ contains tests for javascript code using Windmill Python API. [17:46] * _lib/canonical/launchpad/javascript/translations/_ contains YUI 3 javascript code. [17:46] and finaly some utilities [17:46] == Utilities == [17:46] * _scripts_ contains various helping scripts used in cronjobs or doing other utility and integration jobs. [17:46] * _scripts/tests_ contains tests for code from scripts. [17:46] * _utilities_ contains utility classes used in model and browser code, mostly data conversion related. [17:47] Hope you have noticed that almoust all code has the coresponding tests [17:48] Questions? [17:48] 12:43 < bullgard45> hennige: I have seen many .po files having English text of GNOME programs and their German translations. I could make good use of some of them. I do not have a particular URL at hand just now but I can provide one in a moment. [17:48] 12:43 < bullgard45> hennige: I have seen many .po files having English text of GNOME programs and their German translations. I could make good use of some of them. I do not have a particular URL at hand just now but I can provide one in a moment. [17:49] cjohnston: you can find those files officially on the Damned LIes website of gnome. [17:49] http://l10n.gnome.org/ [17:50] http://l10n.gnome.org/teams/de [17:50] They are all imported into Launchpad to be included in the Ubuntu language packs. [17:50] We only edit them in Launchpad Translations if we need to differ from standard Gnome. [17:51] More questions? [17:51] < Emilien> QUESTION: (but maybe keep it for later, as it's not relevant right now): When there is only one series, and one translation template, why couldn't we get the template page as the default [17:51] translations page. Example: with project BaShare, you have 3 translation pages: root https://translations.launchpad.net/bashare , series [17:51] https://translations.launchpad.net/bashare/trunk/+translations and template https://translations.launchpad.n [17:51] < Emilien> et/bashare/trunk/+pots/bashare . The last page is IMHO the most useful, as it contains links to untranslated, need review or changed strings. This could be the default page when there is [17:51] only one series and one template... What is your opinion about that (and sorry for long question) [17:52] Emilien: that sounds like a good idea as long as it is clear to viewer what is going on. [17:53] Emilien: You can describe that in a bug, discuss it with us and even go about and fix it ... ;-) [17:53] More questions? [17:53] < bullgard45> QUESTION: hennige: An example for a po file that I just have found in the WWW, is http://www.mail-archive.com/xfce4-commits@xfce.org/msg08020.html [17:54] That is actually a diff of PO file ... ;) [17:55] This should be imported into Launchpad if they'd want to use it for translations. https://edge.launchpad.net/xfce [17:55] But AFAIR they decided against using Launchpad for translations. [17:56] Another question? [17:56] < Emilien> Question: I like how all the parts have their own tests. Are they automatically executed in some way? [17:56] Ah, the great Launchpad test suite, Emilien! [17:57] Run "make check" to run the whole test suite. Takes a few hours. [17:57] Each branch that is submitted to the LP tree needs to have had this run. [17:58] Then we have the buildbot that continously runs the test suite on the trunk with every new commit. [17:58] One more question? [17:58] < bullgard45> QUESTION: I understood that you considered the translations provided by Launchpad as proposals or a help for a human translator. This somewhat contradicts the attitude of a German [17:58] translator team to admit or restrict would-be human helpers. (But I cannot provide the document that proves such a censorship.) I do understand that a high standard of qualtiy [17:58] translations must be maintained. [17:59] bullgard45: I think what you are referring to is this: [18:00] Anybody can submit suggestions in Launchpad but only those on the translation team are reviewers and can actually accept them to be used. [18:00] This requeires some deal of organization to keep the translations consistent. [18:01] But actually, bullgard45, I don't see a question in there ... ;-) [18:01] But, we have run out of time. [18:01] Thanks henninge and adiroiban ! [18:01] Thank you all for coming. Come and talk to us on #launchpad any time. Thanks. [18:02] Next up is smoser [18:02] Thanks! [18:02] Hello all [18:02] Ok, lets get started. [18:02] This is my first time doing one of these, so I ask for forgiveness in advance [18:02] I'm Scott Moser (https://launchpad.net/~smoser). [18:02] For the past few months I've been working on maintaining and improving Ubuntu's presense on Amazon's Cloud Offering, known as "EC2" [18:02] In this session, I hope to explain : [18:03] * A little bit about what EC2 is (at least from my point of view) [18:03] * What you need to do to use it [18:03] * What you can do with it [18:03] * Some warnings about issues you might find [18:03] * Some miscellaneous things I'd like to mention [18:03] and then, have some time for questions [18:03] * Questions [18:04] first off, I guess I'd like to kind of see a show of hands on who is interested in this session [18:04] if you are, simply a 'o/' or 'i am' .... [18:05] well, seeing none , we'll just go on [18:05]