| === x314 is now known as a1g_ | ||
| joselsolano | se acabó la clase? | 04:09 |
|---|---|---|
| abdullah | can any one help me | 04:36 |
| nhandler | abdullah: Try #ubuntu for support | 04:40 |
| abdullah | ok | 04:41 |
| efm | joselsolano la próxima clase es a 16.00 UTC | 04:46 |
| === MichiSoft is now known as mthalmei | ||
| === mthalmei is now known as MichiSoft | ||
| ankurwidguitar | What's going on? | 07:12 |
| === dholbach_ is now known as dholbach | ||
| === abhi_ is now known as wikz | ||
| === Nicke_ is now known as Nicke | ||
| qwebirc72360 | a | 15:09 |
| === txwikinger2 is now known as txwikinger_work | ||
| X3MBoy | Good morning | 15:45 |
| devin122 | hi | 15:57 |
| devin122 | I didnt think I could make it today because its the first day of school. Luckily there was a chemical spill and school is canceled today and tomorrow | 16:19 |
| === frandieguez_ is now known as frandieguez | ||
| dholbach | Ubuntu Developer Week will start in 25 minutes | 16:35 |
| nixternal | t-minus 21 minutes | 16:39 |
| highvoltage | 220 nicks- nice! | 16:42 |
| dholbach | WELCOME EVERYBODY TO ANOTHER FANTASTIC DAY OF UBUNTU DEVELOPER WEEK! | 16:58 |
| mruiz | yay! | 16:58 |
| dholbach | First up is ara, who will talk about "Letting Mago do your Desktop testing for you"! | 16:58 |
| Quintasan | :D | 16:59 |
| frandieguez_ | :D! | 16:59 |
| dholbach | as always please keep the chat in #ubuntu-classroom-chat and ask your questions there too | 16:59 |
| dholbach | make sure you prefix them with QUESTION: | 16:59 |
| dholbach | also... if you're not comfortable with English and need to ask questions in your language, try one of these channels: | 16:59 |
| dholbach | Catalan: #ubuntu-cat | 16:59 |
| dholbach | Danish: #ubuntu-nordic-dev | 16:59 |
| dholbach | Finnish: #ubuntu-fi-devel | 16:59 |
| dholbach | German: #ubuntu-classroom-chat-de | 16:59 |
| dholbach | Spanish: #ubuntu-classroom-chat-es | 16:59 |
| dholbach | French: #u-classroom | 16:59 |
| dholbach | Enjoy the sessions and take the offer to get involved seriously! :-) | 17:00 |
| dholbach | ara: the floor is yours | 17:00 |
| ara | Hi! and welcome everybody! | 17:00 |
| ara | My name is Ara and I am part of the Ubuntu QA Team | 17:01 |
| ara | I am a software tester and I love testing. I always try to convince devs about testing being something fun :-) | 17:01 |
| ara | As part of my duties in the QA team I have started the Mago project but, what's Mago? | 17:02 |
| ara | I like to call Mago a desktop testing "initiative", rather than a framework. In fact, it is heavily based on LDTP, a desktop testing framework, written in C. | 17:03 |
| ara | With automated desktop testing we name all the tests that runs directly against the user interface (UI), just like a normal user would do: | 17:03 |
| ara | a script will run and you will start to see buttons clicking, menus poping up and down and things happening, automagically | 17:03 |
| ara | Mago tries to add consistency to the way we write, run and report results of this kind of scripts. | 17:04 |
| ara | The aim of this session is to present you this "initiative" and the way we do things in Mago. | 17:04 |
| ara | As stated at https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions, this session required (at least it was very very recommended) to follow http://mago.ubuntu.com/Documentation/GettingStarted beforehand | 17:04 |
| ara | who did follow it? Please, answer in the -chat channel | 17:05 |
| ara | or who didn't? :D | 17:05 |
| ara | Okeeey, don't worry, you can still attend and follow the session if you haven't done your homework. | 17:06 |
| ara | If you haven't followed the getting started guide, please, do the following: | 17:06 |
| ara | $ sudo apt-get install python-ldtp bzr | 17:06 |
| ara | $ bzr branch lp:mago | 17:06 |
| ara | That will install the LDTP packages and the BZR package to be able to get the mago source code | 17:07 |
| ara | If you don't understand something or you think I am going too fast, please, please, please, stop me at anytime (asking in the -chat room) | 17:07 |
| ara | I will try to follow the -chat channel and answer your questions as we go by | 17:08 |
| ara | So, let's dive in. | 17:08 |
| ara | With Mago, one of the things that we are building is a library with "testable" applications | 17:08 |
| ara | If the application you want to test is already in the mago library, writing tests for it is easier. We will start from there, and if we have time then we can start on how to add new applications to the library. | 17:09 |
| ara | First, some testing terminology: | 17:09 |
| ara | A test suite is a collection of test cases; with a test case being an scenario you want to test in your application. | 17:10 |
| ara | We also need to be able to determine whether a test is successful or not in order to report pass or fail. | 17:10 |
| ara | The "knowledge" we have that let us do that is an "oracle" | 17:11 |
| ara | <frandieguez> QUESTION: Mago is like Rspec or TestUnit ara? | 17:11 |
| ara | No, those are unit test frameworks. Mago is for testing the UI directly | 17:11 |
| ara | You don't need to have or to know the code of the application you're about to test | 17:12 |
| ara | In Mago a test suite consists of 2 files: a PYTHON file and a XML file. | 17:12 |
| ara | The .py file contains the code of the test. The things you want to do with the application. The .xml file is the description and arguments of the test suite. This file makes the .py file reusable in different test cases. Let's see how. | 17:13 |
| ara | In your created mago folder (branching the code), open the gedit folder. We keep test suites ordered by application, to allow running test suites for only one of the applications. | 17:14 |
| ara | are you guys in the gedit folder? | 17:14 |
| ara | Under the gedit folder you have gedit_chains.xml and a gedit_chains.py. They both have the same name, but this is not necessary. | 17:15 |
| ara | Open the Python file with your preferred text editor. | 17:15 |
| ara | A good question | 17:15 |
| ara | <efm> does it matter if the app is gnome or kde or something else? | 17:16 |
| ara | right now, desktop testing is based in accessibility information, and kde is very poor | 17:16 |
| ara | right now you need to be running Gnome in order to test the application | 17:17 |
| ara | that's going to change in a future, when at-spi (the communication layer for accessibility) gets ported to DBUS | 17:17 |
| ara | So, going back to the python file | 17:17 |
| ara | The python file is only a simple python class inheriting from GeditTestSuite, which also inherits from TestSuite. All Mago test suites are classes that inherit, directly or inderectly from TestSuite. | 17:18 |
| ara | The main part: | 17:19 |
| ara | if __name__ == "__main__": | 17:19 |
| ara | gedit_chains_test = GEditChain() | 17:19 |
| ara | gedit_chains_test.run() | 17:19 |
| ara | 17:19 | |
| ara | is not necessary, because Mago will run the tests for you, but you can add it to your code for testing purposes. | 17:19 |
| ara | <^arky^> QUESTION: Can mago be used to discover a11y problems in some apps, like missing description or invalid relationships | 17:19 |
| ara | <^arky^> well, it is the other way round, if an application has poor a11y information, it is going to be difficult to test (or impossible) | 17:20 |
| ara | but there are better ways to test if an application has good a11y information, like using Accerciser | 17:20 |
| ara | So, we have a class, GEditChain, which contains a method. A test suite can contain as many methods as wanted. | 17:21 |
| ara | The only test method, "testChain", opens the application, writes on the first tab the string passed as the "chain" argument; saves it and compares the saved file with an oracle file | 17:21 |
| ara | (again oracle, in testing, means the "right" thing a test has to do. Something we know before hand that it is right, so we can check if our test is correct), | 17:22 |
| ara | and then closes the application. | 17:22 |
| ara | As you can see in the code, there is not such a thing as "open" or "close" the application. This is done by the test suite for you. Mago leverage those sort of things, so you can concentrate on your test case. | 17:22 |
| ara | We will get back to that afterwards | 17:23 |
| ara | Now open the XML file with your preferred text editor. As you can see, it is a simple XML file. | 17:23 |
| ara | The root node, called "suite" allows setting a name for your suite. In this case, "gedit chains". The first child node, class, determines the python class of that test suite. In our case the class is the one we saw before. | 17:24 |
| ara | After the class node, we have a node call description. This is a text description of the suite and it will be included in the reports for your convenience. | 17:24 |
| ara | If you want your reports to be self explanatory, you have to include a nice description here :-) | 17:25 |
| ara | After that, there are as many "case" nodes as test cases included in the test suite. In our case we have two cases: "Unicode Tests" and "ASCII Tests". This is one of the advantages of separate the description and data, from the actual script. We can easily reuse the method for several test cases. | 17:25 |
| ara | Each case has a "method", testChain in the example, a description, which will also be included in the report, and a set of arguments. These arguments need to match the arguments in the method. | 17:26 |
| ara | So, let's try to run these tests using mago | 17:27 |
| ara | OK? | 17:27 |
| ara | if you are running any gedit session, please, close it if you don't want to lose your work :-) | 17:27 |
| ara | Go back to your mago folder and run: | 17:27 |
| ara | $ PYTHONPATH=. ./bin/mago -f gedit_chains | 17:27 |
| ara | That will run all the test cases in a test suite file name called gedit_chains. | 17:28 |
| ara | Once finished, you can check the test logs under ~/.mago/gedit | 17:28 |
| ara | Under that folder, Mago have created two log files: the .log file is an XML, in case you want to parse for something else | 17:29 |
| ara | the .html is a nice HTML report, with screenshots if something went wrong | 17:30 |
| ara | OK, there are a couple of questions in the -chat channel about being a bit slow :-) | 17:30 |
| ara | Mago is based on LDTP, which uses c-spi, a slow, slow library. This is going to change, because LDTP2 is being finished now, based in pyspi, and much faster | 17:31 |
| ara | OK, let's continue by adding a test case for the same method. | 17:34 |
| ara | Open again the XML file and let's edit it. We will add it after the last one. | 17:34 |
| ara | Add the node at http://paste.ubuntu.com/264357/ | 17:35 |
| ara | before, the </suite> one, of course | 17:35 |
| ara | You can see the objective of the test case: open the application, write a text "Happy Ubuntu Developer Week!", save it, and compare it to the oracle. | 17:36 |
| ara | We have to write the oracle file beforehand, so open a text editor, create a file with the text "Happy Ubuntu Developer Week!" (without no new lines) and save it as "udw.txt" in the gedit/data folder. | 17:36 |
| ara | while you do this, I'll answer another question | 17:36 |
| ara | <tedg> QUESTION: Is it possible to run unattended on a head-less server? Like without X? | 17:36 |
| ara | tedg, I am afraid you can't. A full GNOME session is needed | 17:37 |
| ara | tedg, not only X, but also a gnome session :) | 17:37 |
| ara | Done? The udw.txt file, I mean | 17:38 |
| ara | So lets's run again the test, always from the mago root folder: | 17:38 |
| ara | $ PYTHONPATH=. ./bin/mago -f gedit_chains | 17:38 |
| ara | This time, a new test case is also run for you, which will compare the new string to the newly created file. | 17:38 |
| ara | QUESTION: ara, how you can execute just one test case? | 17:39 |
| ara | there is an option in mago to do that | 17:40 |
| ara | run $PYTHONPATH=. ./bin/mago --help to check it | 17:40 |
| ara | OK, let's take it to the next level. | 17:40 |
| ara | Let's think that we want to do the opposite test case, opening a file, reading its contents and compare to the string we know it contains. | 17:41 |
| ara | Let's create, under the gedit folder, a new file gedit_open.py with the following code: | 17:41 |
| ara | http://paste.ubuntu.com/264358/ | 17:41 |
| ara | Also, let's create an XML file to run this (gedit_open.xml) | 17:42 |
| ara | http://paste.ubuntu.com/264362/ | 17:42 |
| ara | In this case, the oracle is the string that we know the file contains. | 17:42 |
| ara | Let's try to run this: | 17:43 |
| ara | PYTHONPATH=. ./bin/mago -f gedit_open | 17:43 |
| ara | The application opened, mago gave an error, and exited the application. That's expected, though. | 17:44 |
| ara | The GEdit class does not contain a openfile method. We need to use LDTP functions to add new methods to the GEdit class. As we said at the beggining, one of the aims of Mago is reuse. Right now GEdit does not include a openfile method, but once added, anyone can benefit from this addtion and use the method easly in their test scripts. | 17:44 |
| ara | The GEdit class is under the mago library, application, gnome.py | 17:45 |
| ara | Lets open it: | 17:45 |
| ara | $ <editor> mago/application/gnome.py | 17:45 |
| ara | Search for "class GEdit" and let's start editing. | 17:45 |
| ara | Don't worry about LDTP syntax, that's another story. In this session we want to learn about the internals of Mago and how to contribute to it. LDTP has its own documentation and tutorials at http://ldtp.freedesktop.org/wiki/Docs | 17:46 |
| ara | Going back to Mago. Mago library contains a set of resuable methods for testing applications. We want to avoid having ldtp functions in our scripts, and leave that in the library. If anything changes in the application, or we decide to change the framework, the scripts will remain the same. | 17:46 |
| ara | Let's add these two methods to the library: | 17:47 |
| ara | In the GEdit class, add the two methods at http://paste.ubuntu.com/264361/ | 17:47 |
| ara | we are adding a method to open a file in Gedit, and another to get the contents of the main buffer | 17:48 |
| ara | All strings, as per Mago coding guidelines, should be set as constants of the class. Check the rest of the methods for an example. For the sake of simplicity of this tutorial, we have kept those as strings in the code. | 17:48 |
| ara | So you can start thinking about how LDTP recognizes the objects in an application | 17:48 |
| ara | OK, let's save the file and let's try to run it one more time now: | 17:49 |
| ara | PYTHONPATH=. ./bin/mago -f gedit_open | 17:49 |
| ara | How did it work this time? | 17:50 |
| ara | I am afraid we won't have time to cover other topics, like adding a new application to the mago library, but before we finish the session I would like to talk you briefly about how the magic of opening the applications and closing them works. | 17:53 |
| ara | As a told you, the GEdit test suite that we created, inherits from GEditTestSuite, which inherits itself from SingleApplicationTestSuite. | 17:54 |
| ara | Let's see what a TestSuite class and subclasses need to implement: | 17:54 |
| ara | $ <editor> mago/test_suite/main.py | 17:54 |
| ara | Every TestSuite class and subclasses need to reimplement, if needed, the setup, the teardown and the cleanup methods. | 17:54 |
| ara | The setup method is run before running any of the test cases, the clean up after every test case, and teardown, after the whole suite is run. | 17:55 |
| ara | Let's take a look to the GEditTestSuite class: | 17:55 |
| ara | $ <editor> mago/test_suite/gnome.py | 17:55 |
| ara | What we do on the setup is opening the application. That's obvious. We close the application on the teardown method. | 17:56 |
| ara | The most complicated one in this case, is the cleanup method, run between test cases. | 17:56 |
| ara | In this one we close the current gedit tab, ignore a "Save file" dialog if it appears, and create a new document; leaving gedit again, clean and ready for the next test case. | 17:57 |
| ara | If you get errors about the setup, cleanup or teardown methods, it is here where you have to start debugging | 17:57 |
| ara | I am running out of time to try to help solving the errors you got, you can catch me anytime at ara AT ubuntu DOT com | 17:58 |
| ara | We can finish here leaving you with some documentation in case you want to go deeper: | 17:58 |
| ara | http://mago.ubuntu.com | 17:59 |
| ara | It has all the information you need: mailing list, IRC channel, API doc, etc. | 17:59 |
| ara | I really recommend joining the mailing list: you can add there your errors when writing test cases, and the community is always happy to help :) | 17:59 |
| ara | Thanks all for attending and happy testing!! | 18:00 |
| ara | next session by tedg, seb128, djsiegel | 18:01 |
| ara | "Paper cutting 101" | 18:01 |
| djsiegel | Hello, everyone! I hope you are enjoying UDW and learning a lot. Now it's time for Paper Cutting 101. | 18:01 |
| djsiegel | I will begin by giving a little bit of background information about the hundredpapercuts project, and then point everyone to some useful information about the progress of the project so far. | 18:02 |
| djsiegel | Then, if seb128 or any other paper cutters are up to it, they can jump in and go into more detail about how paper cuts get fixed. | 18:02 |
| djsiegel | Else, we can go straight to questions. | 18:02 |
| djsiegel | So, for Karmic, the Ayatana Project together with the Canonical Design Team is focusing on fixing some of the “paper cuts” affecting user experience within Ubuntu. | 18:03 |
| djsiegel | The ayatana project convenes in #ayatana, so if you stop by there, you'll likely be able to jump right into a papercut discussion. | 18:03 |
| djsiegel | Briefly put, a paper cut is a trivially fixable usability bug that the average user would encounter on his/her first day of using a brand new installation of Ubuntu Desktop Edition (and Kubuntu too!). You can find a more detailed definition at: https://wiki.ubuntu.com/PaperCut | 18:03 |
| djsiegel | Here is an excellent example of a paper cut that has been fixed for karmic: https://bugs.edge.launchpad.net/hundredpapercuts/+bug/147230 | 18:04 |
| djsiegel | The bug is the behavior of compiz viewport switching plugin and how it responds to scrolling. | 18:04 |
| djsiegel | By default, if you scroll with your cursor of your desktop (or other sensitive areas) in Jaunty, your workspaces just start whizzing by at a dizzying pace. | 18:05 |
| djsiegel | Clearly, this negatively affects user experience in the default ubuntu install. | 18:06 |
| djsiegel | I once saw a friend new to Ubuntu activate this by mistake while using her trackpad. She literally had to turn away from the computer because it made her dizzy. | 18:06 |
| djsiegel | So, the fix for this was trivial -- change the default value of the switch-on scroll feature to false instead of true. | 18:07 |
| djsiegel | Now, if you look at that bug report, you'll see that it was fixed in round 2. | 18:08 |
| djsiegel | Our goal is to fix 100 paper cuts for Karmic, and to help us tackle the problem, the 100 paper cuts planned for Karmic were split into 10 milestones or "rounds" as we have been calling them. | 18:09 |
| djsiegel | This is the tenth week of the project, so we are in the middle of the tenth and final milestone. | 18:09 |
| djsiegel | You can see an overview of the ten milestones and the progress made so far here: https://edge.launchpad.net/hundredpapercuts/karmic | 18:09 |
| djsiegel | Now, the milestones are not hard deadlines, so don't worry that none of them are complete. | 18:10 |
| djsiegel | Well, worry a little bit, but not too much ;) | 18:10 |
| djsiegel | Here are the 43 paper cuts that are marked Fixed Committed/Released: http://tr.im/xNSQ | 18:11 |
| djsiegel | At first glace, we appear to be a little less than halfway to our goal of 100 paper cuts. | 18:11 |
| djsiegel | But, there are also 15 paper cuts currently marked In Progress: http://tr.im/xNSY | 18:12 |
| djsiegel | And 50 (plus a few spare paper cuts for good measure) that are not yet fixed: http://tr.im/xNS9 | 18:12 |
| djsiegel | So, this is the important link ^ | 18:12 |
| djsiegel | Most of these 50 remaining paper cuts that are neither marked In Progress nor Fixed are actually pretty far along. | 18:13 |
| djsiegel | Many of them have preliminary patches, good progress upstream, and merge proposals. | 18:13 |
| djsiegel | So, I would say that 80 out of 100 paper cuts are fixed or have a peer reviewed fix available and are awaiting a merge upstream or into Ubuntu. | 18:14 |
| djsiegel | So, big thank you to everyone in here who has helped! | 18:14 |
| djsiegel | If any of you attended the packaging for small bugs sessions earlier in the week, or Ara's Mago session, you are in a great position to help with paper cuts if these kind of usability problems interest you. | 18:15 |
| djsiegel | the packaging *or* small bugs sessions | 18:15 |
| djsiegel | I'm sure there are many of you with a new set of skills who are eager to cut your Ubuntu development teeth, and the list of remaining paper cuts is the *perfect* place to do this (http://tr.im/xNS9) | 18:16 |
| djsiegel | So, that is information about the project, a comprehensive status update, and an advertisement for the project to solicit some new developers. | 18:17 |
| djsiegel | Are there any questions so far? | 18:17 |
| djsiegel | c_korn asks, "so I have to know the solution of the bug already to decide whether it is a papercut?" | 18:19 |
| djsiegel | No, but that information can help you rule out bugs that are not paper cuts. | 18:20 |
| djsiegel | When reporting a paper cut against the project, you should check the candidate bug against the working paper cut defintion here: https://wiki.ubuntu.com/PaperCut | 18:21 |
| djsiegel | The best paper cuts are ones whose solutions are immediately apparent. | 18:21 |
| djsiegel | If you do not know the solution, please, report the issue. People more familiar with the affected software will help confirm it (or not). | 18:22 |
| djsiegel | frandieguez asks, "did you search for new interface improvements on other OS?" | 18:22 |
| djsiegel | The hundred paper cuts project is focused on fixing small problems, not on making improvements in general. | 18:22 |
| djsiegel | So we did not explicitly evaluate other OSes to discover issues in Ubuntu. | 18:23 |
| djsiegel | frandieguez follows up, asking if we looked to other OSes to solve some of the paper cuts. | 18:24 |
| djsiegel | frandieguez, do you have a specific example in mind? | 18:24 |
| djsiegel | In the example paper cut I gave, it's obvious that we did not need to look to other systems to decide that prominent features that make users nauseous are bugs. | 18:25 |
| djsiegel | And the solution in that case, to disable viewport switching on scroll, was just apparent. | 18:25 |
| djsiegel | frandieguez, right, paper cuts is about fixing small bugs, and does not deal with new features *at all* | 18:26 |
| djsiegel | From the definition, " new feature is not a paper cut; a paper cut is a problem with an existing piece of functionality, not a new piece of functionality. If a bug involves adding something to an interface (e.g. a new button), it's probably a new feature and not a paper cut." | 18:26 |
| djsiegel | Is there anyone in attendance interested in fixing a paper cut for Karmic? | 18:28 |
| djsiegel | I encourage you to join #ayatana on irc.ubuntu.com | 18:28 |
| djsiegel | also, pick one of the 50 remaining paper cuts and claim it | 18:28 |
| djsiegel | Check on its status upstream. If it needs a patch, create one. | 18:29 |
| djsiegel | Update its status if it is in progress or fixed | 18:29 |
| djsiegel | Like I said, it seems that at least 80 of these are fixed or need a small nudge | 18:29 |
| djsiegel | if you can be that nudge for a couple paper cuts, it will have a huge impact on user experience in Karmic | 18:29 |
| djsiegel | tedg asks, "How do I claim a paper cut | 18:30 |
| djsiegel | Well, if you are truly committed to fixing it, you can assign it to yourself (I believe). | 18:30 |
| djsiegel | Do not assign it to yourself if you aren't going to work on it immediately, otherwise people will assume you are working on it so the bug may end up being ignored. | 18:31 |
| djsiegel | After assigning it to yourself, read the launchpad bug report and any upstream reports. | 18:31 |
| djsiegel | Then ask yourself, what does this paper cut need before it can be considered fixed? | 18:31 |
| djsiegel | Make a list, then start addressing those work items. | 18:32 |
| djsiegel | plumstead21 asks, "From looking through some of the outstanding paper cuts it seems that many have stalled because of a lack of consensus on the way forward. What happens to them if consensus can't be reached?" | 18:32 |
| djsiegel | One "problem" on the paper cuts as that people will discuss them ad nauseum. | 18:33 |
| djsiegel | So they may appear to be stuck due to lack of "consensus" | 18:33 |
| djsiegel | when in fact, people are just having a prolonged discussion | 18:33 |
| djsiegel | If there are bugs that do look stuck because they don't have a clear direction, you should bring them to the attention of the "papercutters", a team created to pay attention to paper cuts. | 18:34 |
| djsiegel | We hang out in #ayatana | 18:34 |
| djsiegel | dlightle, "is there a standard procedure someone goes through when resolving a papercut when multiple solutions may exist? for example, in your workspace switching, disabling the scroll versus doing so with a modifier key (such as CTRL)" | 18:34 |
| djsiegel | (good questions, guys!) | 18:34 |
| djsiegel | So, here is a common way for a paper cut to stall: the bug is reported, a simple solution is proposed, someone begins working on a fix, then a new person joins the discussion and says "what if we create a new keyboard shortcut?" | 18:35 |
| djsiegel | then a bunch of other people chime in with "+1" | 18:35 |
| djsiegel | and the existence of the alternate suggestion confuses whoever is working on the bug because they lose confidence in the first solution | 18:36 |
| djsiegel | the bottom line is, there will almost always be more than one way to fix a paper cut | 18:36 |
| djsiegel | and people will always jump in the discussion and propose an alternative approach | 18:36 |
| djsiegel | in the case of paper cuts, it's often best to take the simplest solution | 18:37 |
| djsiegel | remember, the goal is to improve user experience for Karmic in subtle ways, not to find the perfect solutions to these problems | 18:37 |
| djsiegel | often times, paper cuts don't get fixed because endless discussion of minutia | 18:37 |
| djsiegel | but if we can view user experience in ubuntu as a spectrum | 18:38 |
| djsiegel | with out goal being to make forward progress | 18:38 |
| djsiegel | with our goal* | 18:38 |
| djsiegel | then we can accomplish more than viewing bugs as binary -- either fixed or not | 18:38 |
| djsiegel | bugs are records of usability problems affecting people, in this case | 18:39 |
| djsiegel | people are different -- some are experts, some are new to ubuntu | 18:39 |
| djsiegel | the goal is to make measurable, incremental improvement on 100 issues for karmic | 18:39 |
| djsiegel | so if you see a paper cut with a long, drawn out discussion, let it play out, but remember that at some point we should pick a good solution and commit to it for Karmic | 18:40 |
| djsiegel | if people are passionate about alternate solutions, let them craft those solutions and get them in the 100 paper cuts for Karmic+1 | 18:40 |
| djsiegel | AntoineLeclair asks, "I'm totally new to packaging, fixing bugs in Ubuntu and projects that aren't mine in general. Where do I ask for help if I found how to fix a bug/papercut?" | 18:41 |
| djsiegel | Well, attending the UDW sessions is a great start. | 18:41 |
| djsiegel | seb128, can you help answer this? | 18:41 |
| seb128 | #ubuntu-bugs, #ubuntu-motu, #ubuntu-desktop on IRC | 18:41 |
| djsiegel | There you have it :) | 18:42 |
| seb128 | or just add a comment on the bug | 18:42 |
| seb128 | that works too | 18:42 |
| djsiegel | Paper cuts are the perfect bugs for new contributors to start with. | 18:42 |
| djsiegel | Many of them require a very small diff, and the rest is packaging and testing and PPAs. | 18:43 |
| djsiegel | Each week, I blogged about the paper cuts fixed, you may find these updates fun to read if you're a usability geek: http://davidsiegel.org/?s=progress+report&searchsubmit=Find | 18:48 |
| djsiegel | And many people inside and outside the community are discussion the project. Here's over 1,300 blogs about it: http://tr.im/xO1Q | 18:48 |
| djsiegel | Any final paper cuts questions? | 18:52 |
| djsiegel | dlightle asks, "Is the papercut concept and/or the 100 papercuts new starting in karmic?" | 18:53 |
| djsiegel | The concept is not new, but it's a new effort for ubuntu. | 18:54 |
| djsiegel | We had a paper cut effort for GNOME Do (http://davidsiegel.org/paper-cut/) and it resulted in one of the best releases to date. | 18:54 |
| djsiegel | Well, thank you all for attending this session. And feel free to try your hand at fixing some of the remaining cuts! http://tr.im/xNS9 | 18:55 |
| jcastro | mok0: go ahead and begin! | 19:04 |
| mok0 | Thanks jcastro! | 19:04 |
| mok0 | OK, so this class is "Learning from mistakes - REVU reviewing best practices" | 19:05 |
| mok0 | Can we have a count of hands, please? | 19:05 |
| mok0 | Please go to #ubuntu-classroom-chat | 19:09 |
| mok0 | there | 19:20 |
| mok0 | OK, so we'll carry on here, sorry for the confusion | 19:20 |
| AntoineLeclair | are you at http://revu.ubuntuwire.com/p/php5 ? | 19:20 |
| frandieguez_ | yes | 19:20 |
| c_korn | yes | 19:20 |
| AntoineLeclair | I was asking to mok0, hehe | 19:20 |
| mok0 | So, let's combine this tutorial with the useful and let uploaders benefit by getting their packages reviewed. Therefore, we will leave our comments once we have reviewed the package(s). | 19:21 |
| mok0 | I'm open to suggestions :-) | 19:21 |
| mok0 | It should be a NEW package, i.e. one that hasn't been reviewed before | 19:21 |
| c_korn | celtx | 19:22 |
| mok0 | OK, I found that too... | 19:23 |
| frandieguez_ | yes celtx | 19:23 |
| mok0 | The first thing I generally do before spending time on a package, is to check if it's already been uploaded to Debian, or if there's been an ITP bug filed. That indicates that someone else might be working on the package, in which case there might be a conflict of interest and/or a duplicate effort == waste of someones time. | 19:23 |
| mok0 | So let's look here: http://ftp-master.debian.org/new.html and http://www.de.debian.org/devel/wnpp/being_packaged and just do a search for the package name in the browser. | 19:23 |
| mok0 | What's the verdict? | 19:24 |
| frandieguez_ | isn't there | 19:24 |
| c_korn | nothing found | 19:24 |
| mok0 | :) | 19:25 |
| ScottTesterman | not found | 19:25 |
| mok0 | The next thing I do is to du a cursory check if this software can be distributed at all. Otherwise, there's no need spending time on it. We absolutely need a file -- normally called COPYING -- that grants Ubuntu permission to distribute the software. So let's browse down REVU's html pages into the directory and see if this permission is present. | 19:25 |
| mok0 | Alright, so this code is derived from mozilla it seems | 19:26 |
| frandieguez_ | yes | 19:26 |
| frandieguez_ | http://revu.ubuntuwire.com/revu1-incoming/celtx-0908260521/celtx-2.0.1/mozilla/ | 19:26 |
| ScottTesterman | It's under the CePL | 19:27 |
| mok0 | There's a file called LICENSE | 19:27 |
| mok0 | ScottTesterman: GPL? | 19:27 |
| mok0 | I see Mozilla Public License in there | 19:27 |
| frandieguez_ | MPL! | 19:27 |
| ScottTesterman | Under debian/ there's a copyright file. | 19:28 |
| ScottTesterman | It's says CePL. | 19:28 |
| ScottTesterman | The Celtix Public License. | 19:28 |
| mok0 | ScottTesterman: Ah, you're way ahead of me :-) | 19:28 |
| ScottTesterman | Woops, sorry! | 19:28 |
| mok0 | But let's look at debian/copyright, then | 19:29 |
| mok0 | Well, this is a complicated license situation | 19:30 |
| frandieguez_ | of course... | 19:30 |
| ScottTesterman | It looks like it's fine to use as long as Ubuntu a) changes the name of the product, and b) rips out all the Celtx logos and names from the product. | 19:31 |
| mok0 | It is necessary to spend time reading all this stuff to figure out if the copyright file is OK | 19:31 |
| mok0 | ScottTesterman: Right, so one job for the reviewing is to see that this is done | 19:32 |
| mok0 | My next step is generally to download the package. I find the link to the relevant .dsc file, right click -> copy the link. Then I move into a terminal, and type "dget -ux " + right-click -> paste. | 19:32 |
| mok0 | Yuc, it's huge | 19:33 |
| mok0 | :-) | 19:33 |
| mok0 | So... have you guys got a pbuilder or something like that? | 19:34 |
| frandieguez_ | yes | 19:34 |
| dinxter_ | yep | 19:34 |
| frandieguez_ | from previous lectures | 19:34 |
| ScottTesterman | yes | 19:34 |
| AntoineLeclair | same here | 19:34 |
| mok0 | Cool, so let's see if it builds | 19:35 |
| c_korn | yes | 19:35 |
| mok0 | ... If the build fails, the review is usually quite short :-P | 19:35 |
| mok0 | As you probably know, a source package is mainly composed of the pristine tarball and a diff.gz file containing the work of the packager. While it is possible for the diff.gz file to patch everything in the source tree, the current paradigm is that nothing outside the debian/ directory must be touched. | 19:37 |
| mok0 | So, while this is building, let's check to see that nothing else is in the .diff.gz file: | 19:37 |
| mok0 | lsdiff -z <package>.diff.gz | 19:37 |
| c_korn | fail | 19:38 |
| mok0 | c_korn: you mean the two files in $topdir? | 19:38 |
| c_korn | and the files in the mozilla directory | 19:38 |
| c_korn | config.log e.g. | 19:39 |
| mok0 | c_korn: oh yes didn't see those at first | 19:39 |
| mok0 | tsk tsk tsk | 19:39 |
| mok0 | I need a volunteer to write the review... ;-) | 19:39 |
| mok0 | I generally do it in a text file and copy/paste that later into REVU | 19:40 |
| mok0 | Another thing is that celtx.desktop is duplicated, it's also in debian/ | 19:40 |
| c_korn | well, I am logged in... | 19:40 |
| mok0 | c_korn: thanks | 19:41 |
| mok0 | So, how do you like celtx.1 ? | 19:41 |
| c_korn | should propably in debian/ too ? | 19:41 |
| c_korn | +be | 19:41 |
| mok0 | c_korn: yes | 19:41 |
| mok0 | I am talking about the content of it | 19:42 |
| mok0 | ? | 19:42 |
| mok0 | Pretty useless if you ask me. | 19:42 |
| c_korn | oh, yes. that too :) | 19:42 |
| mok0 | I generally refer people to the Linux Man page Howto: http://tldp.org/HOWTO/Man-Page | 19:43 |
| mok0 | Citation: "The DESCRIPTION section ...eloquently explains why your sequence of 0s and 1s is worth anything at all. Here's where you write down all your knowledge. This is the Hall Of Fame. Win other programmers' and users' admiration by making this section the source of reliable and detailed information. Explain what the arguments are for, the file format, what algorithms do the dirty jobs." | 19:43 |
| mok0 | The man page is for people wanting a bit more information than is given in the package description | 19:44 |
| mok0 | Next we do a cursory check of the files in debian/. We need at least five files to be present there: control, changelog, copyright, config and rules. Otherwise, the package won't build! | 19:45 |
| c_korn | config ? | 19:45 |
| mok0 | We are reviewing for karmic+1 at this point, and StandarsdVersion is 3.8.3 | 19:46 |
| mok0 | compat | 19:46 |
| mok0 | sorry | 19:46 |
| c_korn | conok | 19:46 |
| c_korn | -con | 19:46 |
| c_korn | everything there | 19:46 |
| mok0 | Yes | 19:46 |
| mok0 | control looks good | 19:47 |
| mok0 | except for Standards-Version: 3.8.3 | 19:47 |
| mok0 | What about changelog? | 19:47 |
| c_korn | hm, shouldn't the revision be 0ubuntu1 or whatever ? | 19:48 |
| mok0 | YES! | 19:48 |
| frandieguez_ | c_korn i think the same | 19:49 |
| c_korn | good :) | 19:49 |
| mok0 | And all changelog entries should be collapsed to 1 | 19:49 |
| frandieguez_ | and there is a lot of no usefull change lines | 19:49 |
| frandieguez_ | xD | 19:49 |
| mok0 | And this is important: | 19:50 |
| mok0 | The changelog should document EVERYTHING the packager has done that makes the package different from upstreams tarball | 19:50 |
| mok0 | In this case, he has written a manpage | 19:50 |
| frandieguez_ | mok0 the pattern of file_changed: explication will be great for all the changes | 19:51 |
| mok0 | Another thing you would normally document in changelog is patches needed to get the thing to compile or customized for Ubuntu | 19:51 |
| frandieguez_ | * file_changed: explication | 19:52 |
| mok0 | frandieguez, what do you mean? | 19:52 |
| frandieguez_ | the explications of changes on the source, this is better with the lines formated | 19:52 |
| frandieguez_ | * file_changed: explication | 19:53 |
| mok0 | frandieguez, ah, yes | 19:53 |
| mok0 | So, what about debian/dirs ?? | 19:53 |
| frandieguez_ | pufff, is the default file | 19:53 |
| c_korn | looks like the sample | 19:54 |
| mok0 | yes, it should go | 19:54 |
| c_korn | usr/sbin usually isn't touched | 19:54 |
| mok0 | exactly | 19:54 |
| mok0 | dirs is only for creating empty dirs that the app needs | 19:54 |
| mok0 | for example for plugins or something | 19:54 |
| mok0 | If you look at prerm, it looks like the program needs something called /usr/lib/celtx/updates | 19:55 |
| mok0 | I wonder if that dir is created or not... | 19:55 |
| mok0 | It's not | 19:56 |
| c_korn | already built the package ? | 19:57 |
| mok0 | So, that directory actually should be in dirs instead of what's there now | 19:57 |
| mok0 | c_korn: yes I have a fast machine :-) | 19:57 |
| frandieguez_ | yes | 19:57 |
| mok0 | ... and /usr/sbin is an empty dir in the .deb :-( | 19:58 |
| c_korn | ok :) | 19:58 |
| mok0 | The the de-facto requirement is to have a debian/watch file also. I require it when advocating :-) ... the exception being when upstream's sources are only available from a VCS. | 19:58 |
| mok0 | Let's see if this watch file works... uscan --report-status | 19:58 |
| c_korn | Newest version on remote site is 201, local version is 2.0.1 | 19:59 |
| frandieguez_ | works | 19:59 |
| c_korn | => Package is up to date | 19:59 |
| mok0 | I'm puzzled about the mangling | 20:00 |
| mok0 | (mangled local version number 201) | 20:00 |
| mok0 | Why does he do that? | 20:00 |
| mok0 | Oh | 20:01 |
| ScottTesterman | Shouldn't the watch file return the newest version available for download? | 20:01 |
| mok0 | ScottTesterman: yes | 20:01 |
| ScottTesterman | OK, then the watch doesn't work. Newest version on remote site is 2.0.2. | 20:02 |
| mok0 | But the name of the tarball is celtx-201-src.tar.gz | 20:02 |
| ScottTesterman | ah, I see | 20:03 |
| mok0 | so the watch file needs to remove the '.' from the ubuntu version to be able to compare | 20:03 |
| * jcastro points at the clock | 20:03 | |
| mok0 | Uhuh | 20:03 |
| c_korn | oh, time is running short | 20:04 |
| mok0 | It is indeed... is there another class now? | 20:04 |
| jcastro | yep | 20:04 |
| c_korn | mok0: here is what I got: http://pastebin.com/d130cb1da should I post it ? | 20:04 |
| mok0 | Well, thanks for coming guys | 20:04 |
| jcastro | mok0: perhaps moving to another channel? | 20:04 |
| frandieguez_ | thanks for the great tips | 20:04 |
| mok0 | Looks good | 20:04 |
| ScottTesterman | Thanks mok0! | 20:04 |
| jcastro | or move the discussion to a list? | 20:04 |
| frandieguez_ | yes | 20:04 |
| jcastro | thanks mok0! | 20:04 |
| c_korn | thanks mok0 | 20:05 |
| jcastro | rockstar: you're up! | 20:05 |
| rockstar | Welcome to my session on Advanced Usage of Launchpad and Bazaar. | 20:05 |
| rockstar | My name is Paul Hummer and I work on the Launchpad Code team. | 20:05 |
| rockstar | To give you a good background on the format of this session, I need to share with you a pet peeve of mine. | 20:05 |
| rockstar | I have made a few attempts to become a MOTU, but each time I look at the documentation, I'm presented with LOTS of choices. This makes me feel like I'm reading one of those "Choose Your Own Adventure" games. | 20:05 |
| rockstar | Having the choice is great, and LP and Bazaar workflows can be VERY dynamic. However, today, I'm going to show you how _I_ do my work, answer any questions you might have, and hopefully prime you to be able to develop your own optimized workflow. | 20:05 |
| rockstar | s/games/books | 20:06 |
| mok0 | heh | 20:06 |
| rockstar | So, first things first: Configuring Bazaar | 20:06 |
| rockstar | I'm assuming here that you're relatively familiar with the basics or Bazaar, and the basics of Launchpad. | 20:07 |
| rockstar | You'll want to have your GPG and ssh keys set up, etc. | 20:08 |
| rockstar | I'm also assuming that you have `bzr whoami` configured with an email address that LP knows about. | 20:08 |
| rockstar | If it's wrong, those revisions will never be able to be fixed. You'll have to create new revisions if you want the karma. (We get this question asked a lot) | 20:09 |
| rockstar | Now, I like to keep my branch repositories and my working area separate, so when I set up to work on a new project, my process is something similar to this (in the context of a project called bzr-launchpadplus) | 20:09 |
| rockstar | mkdir ~/Projects/repos/bzr-launchpadplus | 20:09 |
| rockstar | bzr init-repo ~/Projects/repos/bzr-launchpadplus --no-trees | 20:09 |
| rockstar | mkdir ~/Projects/bzr-launchpadplus | 20:09 |
| mok0 | rockstar: shall we repeat this? | 20:10 |
| rockstar | Also, I'll stick in here that if you're not using bzr 2.0rc, you REALLY missing out. The default formats are much better than earlier versions. | 20:10 |
| rockstar | mok0, no, you don't have to, or you can follow along with another project. | 20:10 |
| rockstar | Okay, now I have a basic shell to work off of. I put the repository where all my branches will live inside of ~/Projects/repos/launchpadplus, and the corresponding workspace at ~/Projects/bzr-launchpadplus | 20:11 |
| rockstar | No questions so far? | 20:11 |
| rockstar | Now I need to teach Bazaar about this layout, so it knows to put branches in one place and trees in another. | 20:11 |
| rockstar | I do this with the following lines in ~/.bazaar/locations.conf: | 20:12 |
| rockstar | [~/Projects] | 20:12 |
| rockstar | cbranch_target = /home/rockstar/Projects/repos | 20:12 |
| rockstar | cbranch_target:policy = appendpath | 20:12 |
| rockstar | mok0, you can find bzr 2.0 rc1 in the bzr team PPA | 20:12 |
| rockstar | As LarstiQ pointed out (and I was getting on my way to pointing out), you'll need bzrtools. | 20:13 |
| rockstar | Frankly, having bzr without bzrtools is just silly. It provides a lot of convenience. | 20:13 |
| rockstar | The lines above tell Bazaar that when I call `bzr cbranch` in my ~/Projects/bzr-launchpadplus it knows that it needs to put a branch in the corresponding repos folder, and then create a checkout in ~/Projects/bzr-launchpadplus/<name-of-folder-provided> | 20:14 |
| rockstar | (I should add that I have cbranch aliased to cbranch --lightweight in my ~/.bazaar/bazaar.conf) | 20:14 |
| rockstar | As a sidenote, your locations.conf should probably contain something like this: | 20:15 |
| rockstar | [~/Projects/repos] | 20:15 |
| rockstar | push_location = lp:~<username> | 20:15 |
| rockstar | push_location:policy = appendpath | 20:15 |
| rockstar | public_branch = lp:~<username> | 20:15 |
| rockstar | public_branch:policy = appendpath | 20:15 |
| rockstar | This means that you can just `bzr push` and not have to worry about where it's going (provided you named your repository folder the same as the lp-project). | 20:15 |
| rockstar | This seems like a lot of boilerplate, but remember this is "advanced" stuff. I've spent almost two years of everyday use tweaking this. | 20:16 |
| rockstar | Alright, so now let's get the bzr-launchpadplus working tree into our working area. We do this with: | 20:17 |
| rockstar | cd ~/Projects/bzr-launchpadplus | 20:17 |
| rockstar | bzr cbranch lp:bzr-launchpadplus | 20:17 |
| rockstar | And now I have a working tree at ~/Projects/bzr-launchpadplus/bzr-launchpadplus and the corresponding branch at ~/Projects/repos/bzr-launchpadplus/bzr-launchpadplus | 20:18 |
| rockstar | Alright, now let's get to hacking: | 20:18 |
| rockstar | So bzr-launchpadplus is a curiousity created by Jono Lange to get more glue stuffs between Launchpad and Bazaar. I merged my bzr-autoreview plugin into it, and will be adding some more features to it soon. | 20:18 |
| rockstar | So let's create a branch from bzr-launchpadplus "trunk" and start hacking on something new. | 20:18 |
| rockstar | cd ~/Projects/bzr-launchpadplus | 20:19 |
| rockstar | bzr cbranch bzr-launchpadplus add-more-mojo | 20:19 |
| rockstar | cd add-more-mojo | 20:19 |
| rockstar | Now we have a branch that I've named "add-more-mojo" | 20:19 |
| rockstar | QUESTION: rockstar, you have all your projects in one repo? | 20:20 |
| rockstar | ANSWER: No, I have a repo for each project. Bazaar 2.0 has the format issue worked out, but not everyone has upgraded, so rich-roots don't play well with others. | 20:21 |
| rockstar | So, for instance, my launchpad repo is at ~/Projects/repos/launchpad and my entertainer repo is at ~/Projects/repos/entertainer | 20:21 |
| rockstar | Alright, back to our hacking scenario. | 20:22 |
| rockstar | If hacking takes more than a few hours, it's common courtesy to push up changes at a regular interval to let others know what's going on. If it doesn't, you might not even need to push at all (more on that coming). | 20:22 |
| rockstar | Okay, so we have some commits, we've been working for only two hours, and we're ready to get this code landed. | 20:22 |
| rockstar | QUESTION: as far as i know, for each separate branch in bzr user should make separate folder. Does bazaar have some type of branches, when they keep in the same folder as the whole project (like in git, for example)? | 20:22 |
| rockstar | ANSWER: TECHNICALLY, in my setup, it's possible to mimic the behavior of git/hg. In fact, bzr-pipelines works that way. | 20:23 |
| rockstar | However, it also complicates the issue, i.e. git pull and git push don't work the same way. | 20:24 |
| rockstar | Okay, so in our scenario, we're ready to submit for review. | 20:24 |
| rockstar | Let's add one line to ~/.bazaar/bazaar.conf | 20:25 |
| rockstar | submit_to = merge@code.launchpad.net | 20:25 |
| rockstar | This tells Bazaar that when you want to send a new patch, this is the default email to send it to (you can override this on a case-by-case basis). | 20:25 |
| rockstar | Now, with my mojo branch as the current working directory, I can do `bzr send` and my mail client should open and prepopulate a message to merge@code.launchpad.net and add what Bazaar calls a "bundle" as an attachment. A bundle basically has all the revision data for the revisions that would be merged with this branch. | 20:25 |
| rockstar | Now, describe your change in the message and make sure the subject is correct. I usually use `bzr send -m "<Subject line here>"` because I always forget otherwise. | 20:26 |
| rockstar | If you'd like to request a specific reviewer, you can use the email interface to do so. If you've used this interface for bugs, you'll be familiar with this. In a blank line, add a single space, and then "reviewer <lp-username" | 20:26 |
| rockstar | For instance, if you wanted me to review your branch, you could do: | 20:27 |
| rockstar | reviewer rockstar | 20:27 |
| rockstar | Now, whether or not you've requested a reviewer, you need to sign this email with your GPG key. This confirms to LP that it really is you that is proposing the merge. | 20:27 |
| rockstar | Send your email. | 20:27 |
| rockstar | There were some versions of bzr that were a little funky about figuring out your mail client. In that case, you'll want to specify it in ~/.bazaar/bazaar.cony | 20:28 |
| rockstar | Er, ~/.bazaar/bazaar.conf | 20:28 |
| rockstar | QUESTION: I don't get all this mail stuff. Why don't you just use LPs interface? Much easier IMHO | 20:28 |
| rockstar | Well, because I actually don't find the LP interface to be easier. It's getting there (that's what I currently do every day), but sending off emails is easy. I can do it all from my editor. | 20:29 |
| rockstar | Also, MANY (more than I would have thought) open source projects do their reviews via email. | 20:30 |
| rockstar | QUESTION: do you need to manually gpg sign the email or would enabling gpg signing of commits via "create_signatures = always" in bazaar.conf be sufficient? | 20:30 |
| rockstar | ANSWER: You do indeed need to sign the email. When you sign your revisions, it's a verification on the revision, not an the message that you're writing to go along with your merge proposal. | 20:31 |
| rockstar | There are a few things to note about the email you just sent. | 20:31 |
| rockstar | Did you forget to push to Launchpad before you sent this proposal? Don't worry! Launchpad will create the branch for you! | 20:32 |
| rockstar | Did you push, but then make some more changes and forget to push those? Launchpad will also update the branch for you. | 20:32 |
| rockstar | Now, let's switch over to the reviewer for a second. | 20:32 |
| rockstar | You'll get an email with the patch attached to it. Look it over, make your suggestions, etc. | 20:32 |
| rockstar | Maybe you're fine with this branch. You want to vote approve, and, if you're the only one who needs to approve, mark the proposal as Approved. | 20:33 |
| rockstar | You can do this by email with the following commands: | 20:33 |
| rockstar | review approve | 20:33 |
| rockstar | merge approved | 20:33 |
| rockstar | These commands are documented at https://help.launchpad.net/Code/Review | 20:33 |
| rockstar | Also, this email needs to be GPG signed as well. | 20:33 |
| rockstar | QUESTION: So, "merge@code.lp.net" does the same as a merge request? | 20:34 |
| rockstar | ANSWER: Yes, the email to that address is processed like a merge request. | 20:34 |
| rockstar | Okay, so let's move on to some more really fun stuff. | 20:35 |
| rockstar | Since Launchpad now knows about my mojo branch (whether I pushed it, or LP made one based on my email), I can do `bzr lp-open` and it'll open the branch page in a browser for me. | 20:35 |
| rockstar | When this feature was implemented in Bazaar, I thought, "That's silly." but I use it ALL THE TIME. Seriously, it's amazing. | 20:35 |
| rockstar | Once your code is reviewed, you need to get it landed. | 20:36 |
| rockstar | This means you can set up something like PQM (be prepared to spend a few days on it), merge it manually (which sucks if you have a busy project), or, use Tarmac. | 20:36 |
| rockstar | Tarmac is my project, is very young, but gets the job done. | 20:37 |
| rockstar | Tarmac is a script that will go out to Launchpad, check for approved merge proposals against a project's development focus, and merge them. | 20:38 |
| rockstar | It also has support for running tests on the merge, and not merging if the tests fail. It has a plugin system that ships with plugins for notifying CIA and modifying commit messages to a given template. | 20:39 |
| rockstar | I'd like to create one that will build a source package and send it to a PPA on post-commit. If you'd like to help out with that (I'm not great at packaging), find me afterwards. | 20:39 |
| rockstar | One plugin that has recently been developed by Aaron Bentley that I think is invaluable in bzr-pipes. It allows me to lay a "pipeline" of branches that build one on top of another. | 20:40 |
| rockstar | The benefit of this is that you can break your work up into smaller chunks and get them reviewed and landed that way. | 20:40 |
| rockstar | There is nothing I hate more than a 2500 line diff I need to review. Break it up into 5 500 line diffs and I'll be a little happier. | 20:40 |
| rockstar | bzr-pipelines only works with this separated work area and repository set up that I have. Let's say that, while the previous "mojo" branch is being reviewed, I'd like to still work on something that required code in the mojo branch. | 20:42 |
| rockstar | All I'd need to do is `bzr add-pipe mojo-phase-deux` and it creates a new pipe, and changes me into it. | 20:43 |
| rockstar | This goes back to what ia was asking about earlier. The implementation of pipes basically creates a branch in the ~/Projects/repos/bzr-launchpadplus folder, and then makes my working tree match the branch. So I haven't changed dirs, but I've changed branches. | 20:44 |
| rockstar | I can see the whole pipeline by doing `bzr show-pipeline` | 20:44 |
| rockstar | Now I hack on this new branch, and commit a few times. | 20:44 |
| rockstar | QUESTION: I get this: bzr: ERROR: Can't find cbranch_target in locations.conf | 20:45 |
| rockstar | ANSWER: Earlier in the session, I posted my config far cbranch_target that I put in locations.conf | 20:45 |
| rockstar | s/far/for | 20:45 |
| rockstar | <rockstar> [~/Projects] | 20:46 |
| rockstar | <rockstar> cbranch_target = /home/rockstar/Projects/repos | 20:46 |
| rockstar | <rockstar> cbranch_target:policy = appendpath | 20:46 |
| rockstar | Alright, so I've been doing work in this second pipe. | 20:47 |
| rockstar | But wait, the reviewer wants changes for my first mojo branch. Not to worry. I can switch back to that pipeline with `bzr switch-pipe add-more-mojo` | 20:47 |
| rockstar | Then I make the changes and commit and push. | 20:47 |
| rockstar | Then I need to pump the changes up the pipeline with `bzr pump` and all branches (or "pipes") get those changes. | 20:48 |
| rockstar | Get it? You "pump" changes up the "pipeline"? abentley is so clever. | 20:48 |
| rockstar | :) | 20:48 |
| rockstar | A word to the wise: Make sure you don't have too many pipes in progress. Think of them as plates spinning on small sticks, and you aren't a circus clown. It won't be too long before you have a mess on your hands; I tried plate spinning as a child and ended up grounded for a very long time. YMMV. | 20:50 |
| rockstar | If you're going to use bzr-pipelines in your regular workflow (and I suggest you do), here are some aliases I use with pipes that you might want to add to your [ALIASES] section of ~/.bazaar/bazaar.conf | 20:51 |
| rockstar | next = switch-pipe :next | 20:51 |
| rockstar | prev = switch-pipe :prev | 20:51 |
| rockstar | send-pipe = send -r branch::prev.. | 20:51 |
| rockstar | diff-pipe = diff -r branch::prev | 20:51 |
| rockstar | pipes = show-pipeline | 20:51 |
| rockstar | Now, instead of `bzr send` for pipes, I can use `bzr send-pipe` and it will generate the diff only for the changes specific to this pipe. | 20:51 |
| rockstar | The same for diff-pipe. | 20:51 |
| rockstar | (The LP Code team is currently strategizing on how to handle branches based on other branches that haven't landed yet. No one wants to review code that's already been reviewed) | 20:52 |
| rockstar | I didn't want to type out "show-pipeline" so I shortened it to "pipes". | 20:52 |
| rockstar | Also, I never remember the names of my pipes, so I just use `bzr prev` and `bzr next` to navigate the pipeline. | 20:53 |
| rockstar | ...and in closing, I'd like to share some of the aliases that I use in my workflow regularly. | 20:54 |
| rockstar | [ALIASES] | 20:54 |
| rockstar | cbranch = cbranch --lightweight | 20:54 |
| rockstar | ci = commit --strict | 20:54 |
| rockstar | sdiff = cdiff -r submit: | 20:54 |
| rockstar | unpushed = missing --mine-only :push | 20:54 |
| rockstar | st = status --short | 20:54 |
| rockstar | As mentioned before, cbranch --lightweight creates lightweight checkouts. | 20:55 |
| rockstar | `bzr ci` will not commit unless I've dealt with all the unknown files. How many times have you forgotten to add a file to the branch, and then someone else can't run your branch because it's missing? | 20:55 |
| rockstar | --strict on commit fixes that. | 20:55 |
| rockstar | `bzr sdiff` generates a color diff of the changes against my submit branch. cdiff is part of bzrtools. If you don't want color (or are piping to less or something), use regular diff. | 20:57 |
| rockstar | `bzr unpushed` will show me all the revisions I haven't pushed yet. I don't use it often, but I always forget the syntax when I need it, so I just aliased it. | 20:57 |
| rockstar | And `bzr st` is just because I'm too lazy to type out 'status' :) | 20:58 |
| rockstar | Any other questions? | 20:58 |
| rockstar | QUESTION: do you have a quick ref url? for the bzr commands? | 20:59 |
| rockstar | ANSWER: `bzr help commands` should give you all your commands, and `bzr help commit` will show you the various options for commit. | 21:00 |
| rockstar | Alright, I think that's all I've got before Castro comes. Thanks everyone! | 21:01 |
| jcastro | sbeattie: you're up next! | 21:03 |
| sbeattie | Thanks, rockstar and jcastro! | 21:04 |
| sbeattie | Hi, I'm Steve Beattie, on the Ubuntu QA team, here to talk about the regression testing we do. | 21:04 |
| sbeattie | We essentially do regression testing in 3 different situations, when doing a security update, verifying a post-release regular update to a package, and during the milestones for development releases | 21:05 |
| sbeattie | We have a few different tools we use for testing within Ubuntu | 21:06 |
| sbeattie | There's checkbox: https://wiki.ubuntu.com/Testing/Automation/Checkbox | 21:06 |
| sbeattie | You may know this as the "System Testing" menu item under System -> Administration menu | 21:06 |
| sbeattie | In addition to helping to do hardware testing, it's meant to be sort of a meta-testframework, in that it can encapsualte other frameworks. | 21:07 |
| sbeattie | There's Mago, which Ara Pulido talked about earlier today. | 21:07 |
| sbeattie | It's meant to be an automated desktop testing framwork, and is a joint initiative that we're pushing with Gnome. | 21:08 |
| sbeattie | And finally, there's the qa-regression-testing tree. | 21:08 |
| sbeattie | It's located at https://code.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master aka lp:qa-regression-testing | 21:08 |
| sbeattie | (warning, the tree is over 500MB!) | 21:09 |
| sbeattie | It initially started out as a project by the Ubuntu Security team, to help them test out their security updates. | 21:09 |
| sbeattie | But the QA team has also adopted it for some of our testing as well. | 21:10 |
| sbeattie | The qa-regression-testing tree is what I'm going to talk about. | 21:10 |
| sbeattie | As I said, the bzr tree itself is about 500MB, but I've made a very small subset (80k) available at http://people.canonical.com/~sbeattie/udw-qa-r-t.tar.gz | 21:11 |
| sbeattie | With this, we try to cover functional tests, exercising program(s) in the package we're interested in, to ensure they function propoerly, or verifying that default configs are sensible, and that we haven't lost critical ones over time. | 21:12 |
| sbeattie | Sometimes these tests are destructive; we attempt to make them not be, but there's no guarantees. | 21:12 |
| sbeattie | So it's best to run them in a non-essential environment, either a virtual machine or a chroot. | 21:13 |
| sbeattie | If we look over the tree at http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/files | 21:13 |
| sbeattie | there's a few different toplevel directories | 21:13 |
| sbeattie | build_testing/ covers notes and scripts related to invoking (typically) build tests from the upstream package itself | 21:14 |
| sbeattie | results/ are saved results from running such upstream tests, to use as a comparison baseline. | 21:14 |
| sbeattie | notes_testing/ is a collection of notes about testing various packages. | 21:15 |
| sbeattie | install/ is a post OS install sanity check script, along with saved results | 21:15 |
| sbeattie | scripts/ contains the actual set of testcases, organized by package, along with helper libraries and test programs | 21:15 |
| sbeattie | and data/ which is saved data that can also be used in one of the scripts/ testcases | 21:16 |
| sbeattie | scripts/ is where we'll focus our attention. | 21:16 |
| sbeattie | We'll start with a trivial example. | 21:17 |
| sbeattie | As I said, the scripts are organized by packages; each package that we've worked on so far will have a script name test-PACKAGE.py | 21:17 |
| sbeattie | If we look in scripts/ we'll see there's no test-coreutils.py script; that seems like an oversight, so we'll add a very simple one. | 21:18 |
| sbeattie | Again if you pull down http://people.canonical.com/~sbeattie/udw-qa-r-t.tar.gz, there's a subset of the bzr tree, along with toplevel directories named 1, 2, and 3 | 21:19 |
| sbeattie | in directory 1/ there's a test-coreutils.py | 21:19 |
| sbeattie | You can also see it at http://pastebin.com/f5d7510be | 21:20 |
| sbeattie | So our scripts our all extensions of python-unit (so you'll want that installed) | 21:20 |
| sbeattie | Yes, we're using a unit test framework, despite doing a bunch of functional tests; essentially we're using python as a smart scripting language | 21:21 |
| sbeattie | (See http://docs.python.org/library/unittest.html for documentation on python-unit) | 21:21 |
| sbeattie | Our first test that I've written will test if /bin/true actually runs and returns 0 as expected. | 21:22 |
| sbeattie | So some important points as we look at it. | 21:22 |
| sbeattie | class CoreutilsTest is a subclass of testlib.TestlibCase | 21:22 |
| sbeattie | testlib is a module we've added which both extends unittest.TestCase and provides additional utility functions that make it easier to do common tasks. | 21:23 |
| sbeattie | the testcase itself is the test_true() method CoreutilsTest class | 21:23 |
| sbeattie | python-unit's unitest will run all methods on our class that begin with the name "test" | 21:24 |
| sbeattie | testlib.cmd(['/bin/true']) is where /bin/true gets executed, testlib.cmd is an improved version of the various system(),popens() providied by python | 21:25 |
| sbeattie | we then throw an assert if the result from running /bin/true does not equal what we expect | 21:25 |
| sbeattie | asserts are the way one causes a testcase to fail in python-unit, other types of exceptions will cause py-unit to consider the test as an error | 21:26 |
| sbeattie | py-unit provides a wide variety of assert test functions. | 21:26 |
| sbeattie | So, to run the test, we cd into 1 and do ./test-coreutils.py | 21:27 |
| sbeattie | The output from running should look like http://paste.ubuntu.com/264590/ | 21:27 |
| sbeattie | Note that the output string (in verbose mode, which our script turned on) is the docstring from the test_true() methid. | 21:28 |
| sbeattie | So what does a failed test look like? | 21:28 |
| sbeattie | To see, we'll change our expected result to be 1 instead of 0 | 21:28 |
| sbeattie | this is the version in the 2/ directory, also visible at http://pastebin.com/f9c5be05 | 21:29 |
| sbeattie | Again, we run ./test-coreutils.py, and should see output like http://paste.ubuntu.com/264591/ | 21:29 |
| sbeattie | Okay, we did /bin/true, let's add another testcase, one for /bin/false. | 21:30 |
| sbeattie | That's what our example in 3/test-coreutils.py does, we've added a second method, test_false() | 21:30 |
| sbeattie | (also at http://pastebin.com/m5e8cc2d0 _ | 21:30 |
| sbeattie | and if we ran it, we should see output like http://paste.ubuntu.com/264593/ | 21:31 |
| sbeattie | Looking at our results, we notice it ran the false test first; pyunit runs the test methods in alphabetic order. | 21:32 |
| sbeattie | order generally shouldn't matter, but sometimes test authors will prefix testcase methods with number to sort them in a more logical ordering from a human's perspective. | 21:32 |
| sbeattie | So that's a very simple example, but real tests are likely to be much more complicated. | 21:33 |
| sbeattie | We might need to do some configuration setup, create datafiles, etc. before running our tests. | 21:33 |
| sbeattie | Both unittest and our testlib provide help for writing more complex tests. | 21:34 |
| sbeattie | As a simple example, let's look at http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head:/scripts/test-apt.py | 21:34 |
| sbeattie | in 33-49, we have two methods, setUp() and tearDown(). | 21:35 |
| sbeattie | (lines 33.49, that is) | 21:35 |
| sbeattie | These will get automatically invoked the python-unit before and after each testcase (i.e. each test*() method). | 21:35 |
| sbeattie | These will get automatically invoked *by* python-unit before and after each testcase (i.e. each test*() method). | 21:36 |
| sbeattie | These functions give us a point where we can change our environment to match what we want to test, or to setup a non-default config in an alternate location, so we aren't destructive to the default system settings. | 21:38 |
| sbeattie | There are other ways of modifying configs in (hopefully) safe ways. | 21:39 |
| sbeattie | testlib provides these: | 21:39 |
| sbeattie | config_replace() lets you replace or append the contents of a config file | 21:39 |
| sbeattie | config_comment(), config_set(), config_patch() modify configs in certain ways | 21:39 |
| sbeattie | and then config_restore() restores whatever configs were modified to their original saved state. | 21:39 |
| sbeattie | An example where this is used is in the test-dash.py script | 21:40 |
| sbeattie | http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head:/scripts/test-dash.py | 21:40 |
| sbeattie | In section __main__, lines 69 onward. | 21:40 |
| sbeattie | Basically, 3 different shell config files are modified and then restored. | 21:41 |
| sbeattie | Another thing to notice in this example is line 77, it contains test_user = testlib.TestUser() | 21:42 |
| sbeattie | The testlib.TestUser class creates a new (randomly-named) user on the system. | 21:42 |
| sbeattie | Obviously, requires script to be run as root (as does modifying global configs) | 21:42 |
| sbeattie | The dstructor for the TestUser class does the cleanup work of removing the user. | 21:43 |
| sbeattie | This lets you add a user to test out various privilege changes. | 21:43 |
| sbeattie | as well as not mess with the state of the user that you're trying to run the tests from. | 21:44 |
| sbeattie | Config munging and system state changing can be quite complex. | 21:44 |
| sbeattie | The test-openldap.py script is a nice complex example: http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head:/scripts/test-openldap.py | 21:45 |
| sbeattie | I won't go through it, but at a highlevel, there's a variety of Server* classes that extend the ServerCommon class. | 21:46 |
| sbeattie | The setup for each of these classes creates an openldap config to test a specific aspect or feature of openldap: different backends, different auth methods (SASL), different types of connections (TLS) | 21:47 |
| sbeattie | Sometimes, tests are dependent on specific versions of Ubuntu | 21:47 |
| sbeattie | testlib provides a way to do tests conditionally based on different version by testing the value of "self.lsb_release['Release']" | 21:48 |
| sbeattie | e.g. "self.lsb_release['Release'] < 8.10" will only be true for Hardy Heron (8.04) or older | 21:48 |
| sbeattie | This is used quite extensively in the test-kernel-security.py script | 21:48 |
| sbeattie | http://bazaar.launchpad.net/~ubuntu-bugcontrol/qa-regression-testing/master/annotate/head:/scripts/test-kernel-security.py | 21:48 |
| sbeattie | (e.g. lines 511-533) | 21:49 |
| sbeattie | This is done because various kernel config names have changed over time, didn't exist in older releases, or different features weren't enabled. | 21:49 |
| sbeattie | And sometimes, sadly, because there was a bug in an older release, that we're not likely to fix, for whatever reason. | 21:50 |
| sbeattie | When a config or something else in a test changes it's identity conditionally based on version, it's useful to change the reported (verbose) docstring via self.announce() | 21:51 |
| sbeattie | Tests aren't limited to python code, sometimes we need to do things in other languages to exercise something specific. | 21:52 |
| sbeattie | For example, triggering some kernel issues may require writing a C program. | 21:52 |
| sbeattie | scripts/SOURCEPACKAGE can contain a tree of helper programs if needed. | 21:53 |
| sbeattie | Also, we'd annotate the existence of this directory via adding "# QRT-Depends: PACKAGE" as meta-info | 21:53 |
| sbeattie | We do this, because as I mentioned the full bzr tree is very large, and it's a pain for us to copy around the full tree when we're typically only interested in testing one package (when doing an update) | 21:54 |
| sbeattie | scripts/make-test-tarball will collect up just the relevant bits into a tarball, making a much smaller blobl to copy around. | 21:55 |
| sbeattie | e.g. ./make-test-tarball test-kernel-security.py | 21:55 |
| sbeattie | Also, other helper testlibs are available, all named testlib_*.py in the scripts/ directory. | 21:55 |
| sbeattie | Anyway, that's a brief overview of what have available in that tree. | 21:56 |
| sbeattie | So how can you help and what work do we want to do going forward? | 21:56 |
| sbeattie | More testcases! | 21:56 |
| sbeattie | Mor testscripts for packages we don't have tests for! | 21:57 |
| sbeattie | Extending our coverage would be great. | 21:57 |
| sbeattie | Tests do need to be somewhat scriptable, mechanisable | 21:58 |
| sbeattie | Tests of GUI apps are probably better off being directed at the Mago project. | 21:58 |
| sbeattie | Be careful to ensure you're testing what you think you're testing | 21:58 |
| sbeattie | It's not a lot of fun debugging a test failure that turns out to be a bug in the test itself | 21:59 |
| sbeattie | We also need to do the work of encapsulating/integration with checkbox. | 21:59 |
| sbeattie | Feel free to ask questions in #ubuntu-testing (where the QA team hangs out) or in #ubuntu-hardened (where the sceurity team hides itself) | 22:00 |
| sbeattie | That's all I've got, thanks! | 22:00 |
| sbeattie | I believe we're done for the day; jcastro, do you have any wrapup to say? | 22:05 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!