| === johnsgruber is now known as jsg1234567 | ||
| === jsg1234567 is now known as a123456789012345 | ||
| === a123456789012345 is now known as jsjgruber | ||
| === _LibertyZero is now known as LibertyZero | ||
| === max is now known as Guest23210 | ||
| === zyga is now known as zyga-afk | ||
| === zkriesse_ is now known as Guest31717 | ||
| === shadeslayer_ is now known as shadeslayer | ||
| === jpds_ is now known as jpds | ||
| dholbach | HELLO MY FRIENDS! | 15:51 |
|---|---|---|
| dholbach | Welcome to the last day of Ubuntu Developer Week! | 15:51 |
| dholbach | I'm as sad as you all are, but I guess that's just how things go :) | 15:51 |
| dholbach | Today is another action-packed day, which will kick off with Sam "smspillaz" Spilsbury and a great presentation about fixing bugs in compiz | 15:52 |
| dholbach | By now most of you know the organisational stuff already | 15:52 |
| dholbach | - Make sure you're in #ubuntu-classroom-chat as well, so you can ask questions there and please prefix them with QUESTION: | 15:53 |
| dholbach | ie: QUESTION: Is it hard to survive in the DX team as a vegetarian? | 15:53 |
| smspillaz | yes | 15:53 |
| smspillaz | :) | 15:53 |
| dholbach | smspillaz, you have my sympathy | 15:53 |
| dholbach | - And also: Check out https://wiki.ubuntu.com/UbuntuDeveloperWeek for logs of all the past sessions | 15:53 |
| smspillaz | don't worry, you can always order a salad and find steak in it :) | 15:53 |
| smspillaz | (at least, only in dallas) | 15:54 |
| dholbach | I know the "bonus meat" - it's always just "for the taste" :) | 15:54 |
| smspillaz | :p | 15:54 |
| dholbach | alrightie... you still all have 6 minutes, so take it easy and enjoy the last day of UDW! | 15:54 |
| smspillaz | 6 minutes to track down and fix this bug that I'm workign on mwahahahaha | 15:54 |
| dholbach | smspillaz, the stage is yours! | 16:00 |
| smspillaz | lovely, we're ready to start | 16:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Fixing bugs in compiz - Instructors: smspillaz | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 16:01 |
| smspillaz | hey everyone, you may have heard of me before, you may have seen my funky hair or youthful appearance :) I'm Sam Spilsbury, the current maintainer of compiz, the compositing window manager behind unity | 16:01 |
| smspillaz | last UDW I gave a session on how to write plugins for this wonderful window manager | 16:01 |
| smspillaz | today I'm going to give you a session on how it works and how you can fix the little odd corner cases within it | 16:02 |
| smspillaz | so agenda: | 16:02 |
| smspillaz | 1. What is compiz and how does it work | 16:02 |
| smspillaz | 2. Gimmeh teh code | 16:02 |
| smspillaz | 3. Where is everything in the code? | 16:02 |
| smspillaz | 4. How can I get fixes to you | 16:02 |
| smspillaz | fantastic, okay, item one, what is compiz and how does it work | 16:03 |
| smspillaz | so you've probably all heard of compiz as the bit of magic on the system that provides all of the bling, best known for things like wobbly windows, spinnan cubez ;-) etc | 16:03 |
| smspillaz | or drawing fire on the screen | 16:03 |
| smspillaz | however, compiz is also responsible for a lot of other stuff too | 16:04 |
| smspillaz | for example, even when your screen is idling and you've just got some windows up | 16:04 |
| smspillaz | compiz is drawing the entire contents of those windows to the screen | 16:04 |
| smspillaz | or when you grab a titlebar to move a window, compiz is handling the grab of the titlebar, the moving of the window and the placement of the window | 16:05 |
| smspillaz | it also handles resizing windows, focus stealing prevention, tiling windows | 16:05 |
| smspillaz | drawing the window borders on windows | 16:05 |
| smspillaz | basically, if it ends up on your screen, compiz is probably doing some work somewhere | 16:05 |
| smspillaz | so, because of that, we call compiz a "compositing window manager" because it "composites" windows on screen as well as determining how they behave | 16:06 |
| smspillaz | and because of that, there's a lot of scope for things to go /wrong/ too | 16:06 |
| smspillaz | (especially in the land of X11 window managers) | 16:06 |
| smspillaz | for example, if a window is placed off screen, that's a compiz bug | 16:06 |
| smspillaz | or if movement makes the window jump a little, compiz bug | 16:07 |
| smspillaz | or if windows jump around when maximized and the resolution is too low for that window | 16:07 |
| smspillaz | compiz bug | 16:07 |
| smspillaz | so the kind of bugs that you do get in compiz aren't all complicated graphical ones where the effects don't work | 16:07 |
| smspillaz | it can even be small window management related things | 16:07 |
| smspillaz | so there's lots of scope for bugs to fix | 16:08 |
| smspillaz | and luckily, these window management ones are not too tricky to fix | 16:08 |
| smspillaz | so as for how it works | 16:08 |
| smspillaz | so basically compiz' main job is to communicate with the X Server (or X11) on your system to find out the contents of windows and what properties and hints the application has set on them, and then combine them with user input in order to implement a set of rules for how windows behave on screen | 16:09 |
| smspillaz | usually problems happen in one of three places | 16:09 |
| smspillaz | first, in communication with the X server | 16:10 |
| smspillaz | second, the process of turning that communication and user input produces something which is not correct | 16:10 |
| smspillaz | or third, actual graphical problems | 16:10 |
| smspillaz | 3) is a realm that is rather complicated and that we won't look into | 16:10 |
| smspillaz | 1) is also quite complicated, but for new contributors, it can be worked out fairly quickly (though you should ping marnanel or me if you plan to work in this area) | 16:11 |
| smspillaz | and 2) is where the easy wins lie | 16:11 |
| smspillaz | so now you ask, how do I find the bugs in compiz | 16:12 |
| smspillaz | basically, they're all on launchpad | 16:12 |
| smspillaz | right now, all of the bugs are filed against the compiz package on launchpad | 16:12 |
| smspillaz | however, a few days ago, I mirrored all of our components (incl. plugins, settings, everything) to launchpad too in separate launchpad projects | 16:13 |
| smspillaz | so now as we're sorting through the bug queue, I'll be assigning bugs against that larger package to the smaller components, eg, core, plugins, settings | 16:13 |
| smspillaz | lets have a look now at the bugs filed against the compiz package on ubuntu | 16:13 |
| smspillaz | https://bugs.launchpad.net/ubuntu/+source/compiz | 16:14 |
| smspillaz | here's the algorithm I use to sort "that looks nasty" from "easy win" | 16:14 |
| smspillaz | anything regarding visual glitches? (corruption, blank windows) | 16:15 |
| smspillaz | that's probably something quite nasty | 16:15 |
| smspillaz | something like "compiz does this when it should do this" | 16:15 |
| smspillaz | eg "places transient dialogs behind currently focused window" | 16:16 |
| smspillaz | that's an easy win | 16:16 |
| smspillaz | the next thing to determine if its easy is to find out if there's a reproducible test case | 16:16 |
| smspillaz | usually the reporter would have said something about that | 16:16 |
| smspillaz | if it's not reproducible easily, then its not going to be easy to fix | 16:16 |
| smspillaz | because often fixing the bugs requires a very close tracing of what's going on | 16:17 |
| smspillaz | usually I find that if a bug can't generally be reproduced then I ask the bug reporter to show an application which is triggering the problem or a screencast of what's going on | 16:17 |
| smspillaz | reproduction is 90% of the way to fixing it | 16:18 |
| smspillaz | anything about compiz crashing with SIGSEGV can contingently be easy wins | 16:18 |
| smspillaz | have a look at the stacktrace that apport gives you | 16:18 |
| smspillaz | if it's full of things like "??" then it's not useful | 16:19 |
| smspillaz | if it has references to "nux::" in it, then it is probably a bug in untiy or nux and not in compiz (though this should be mostly resolved by apports heuristics) | 16:19 |
| smspillaz | however, if it's got references to things like "PluginScreen::doBlahBlahBlah" then you're good | 16:20 |
| smspillaz | especially if the stacktrace ends within compiz itself | 16:20 |
| smspillaz | ok, now you're probably asking me "where do I get all of this stuff! I want to get my hands dirty hackign on this!" | 16:20 |
| smspillaz | well, compiz is hosted upstream at git://git.compiz.org and also mirrored in launchpad at lp:compiz-core | 16:21 |
| smspillaz | if you're used to working with launchpad, then I'd suggest using launchpad as it has some rather powerful features | 16:21 |
| smspillaz | usually we try to keep the ABI/API of upstream compiz in sync with what downstream ubuntu is shipping | 16:21 |
| smspillaz | that way, if you build core, you also don't have to rebuild plugins | 16:21 |
| smspillaz | however, in the rare circumstance that this is the case, you'll need to rebuild some of the other standard components | 16:22 |
| smspillaz | so, that being lp:compiz-core lp:compiz-plugins-main lp:libcompizconfig lp:compizconfig-python lp:ccsm | 16:22 |
| smspillaz | for each of those, it's as easy as doing something like mkdir build; cd build; cmake ..; make && make install | 16:23 |
| smspillaz | (compiz uses the cmake buildsystem) | 16:23 |
| smspillaz | if there's a break in the API/ABI you'll also need to rebuild unity | 16:24 |
| smspillaz | (that's lp:unity) | 16:24 |
| smspillaz | (same instructions_) | 16:24 |
| smspillaz | a small protip: since the window manager is a fairly core part of your system, its nice to have a working one if you're hacking on compiz and have happened to break things | 16:24 |
| smspillaz | so you can install cmake-curses-gui and run ccmake .. and change the CMAKE_INSTALL_PREFIX to something that is not in the system $PATH | 16:25 |
| smspillaz | for example, I keep mine in ~/Applications/Compiz | 16:25 |
| smspillaz | (so you need to adjust your PKG_CONFIG_PATH LD_LIBRARY_PATH LD_RUN_PATH XDG_DATA_DIRS PATH and PYTHONPATH to reflect that change) | 16:26 |
| smspillaz | in order that I don't get carpal tunnel syndrome, I usually just keep a script in my ~/.bashrc with a function to export those variables correctly | 16:26 |
| smspillaz | so now that you've got the source code, where is everything | 16:27 |
| smspillaz | well, if we have a look into http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.5/files | 16:27 |
| smspillaz | you'll see there is quite a lot there | 16:27 |
| smspillaz | (and this is just for core, but that's where all the bugs lie anyways) | 16:27 |
| smspillaz | so first of all, you can ignore cmake/ po/ xslt/ metadata/ images/ legacy/ (I should really remove that) | 16:28 |
| smspillaz | those are all either there for building compiz or default settings | 16:28 |
| smspillaz | gtk/ is where the GTK-Window-Decorator lives and kde/ is where the KDE4-Window-Decorator lives | 16:29 |
| smspillaz | basically in compiz, window borders, titlebars, menus etc are handled in a bit of a special way | 16:29 |
| smspillaz | there's a process called a "decorator" which runs outside of compiz and actually draws the contents of the window borders | 16:29 |
| smspillaz | (there's a good reason for this, and that is that it is not a good idea to mix toolkits and window managers) | 16:30 |
| smspillaz | so part of the titlebars are handled by compiz and part of them are handled by the decorators | 16:30 |
| smspillaz | basically, what the decorators do is talk with compiz' decor plugin over X11 window properties using the protocol defined in libdecoration | 16:31 |
| smspillaz | they specify the geometry of the backing input window for the decorations as well as a pixmap which is the contents of that decoration | 16:32 |
| smspillaz | (they work independently to figure out the contents of every single window decoration) | 16:32 |
| smspillaz | they also handle all the input events on the backing input window for the decoration and tell compiz when to start moving and resizing windows | 16:32 |
| smspillaz | so that's the decorators in a nutshell | 16:33 |
| smspillaz | as for plugins/ | 16:33 |
| smspillaz | surprisingly, a lot of stuff in compiz is handled by plugins | 16:33 |
| smspillaz | for example, moving a window by dragging it's titlebar or alt-drag is handled in a plugin | 16:33 |
| smspillaz | or resizing a window in the same way also in a plugin | 16:33 |
| smspillaz | the alt-tab switcher is in a plugin | 16:34 |
| smspillaz | even rendering using OpenGL is in a plugin | 16:34 |
| smspillaz | the compiz end of window titlebars and frames are also in a plugin | 16:34 |
| smspillaz | the way those plugins work is fairly simple, they take some user interaction and modify the state of the window system based on it | 16:35 |
| smspillaz | but the real magic of compiz happens within core | 16:35 |
| smspillaz | which is that subdirectory named /src | 16:35 |
| smspillaz | core is both a lovely and scary place | 16:35 |
| smspillaz | lovely because you can see all the hard-set policy of compiz | 16:35 |
| smspillaz | scary because this is where communication with X11 happens and a lot of it isn't pretty | 16:36 |
| smspillaz | most of core is separated out into separate files so you can see what's going on | 16:36 |
| smspillaz | action.cpp is the file which handles the dispatching "compiz events" (eg ctrl-alt-left to move desktops) on X11 input events | 16:37 |
| smspillaz | event.cpp is where we handle X11 events and change state based on policy | 16:37 |
| smspillaz | most of that happens in this gigantic function here | 16:38 |
| smspillaz | http://bazaar.launchpad.net/~compiz-team/compiz-core/0.9.5/view/head:/src/event.cpp#L984 | 16:38 |
| smspillaz | I'll run through them breifly | 16:38 |
| smspillaz | basically, we have to dispatch "actions" on key and button events (also also enter/leave events for edge windows) | 16:38 |
| smspillaz | there are also a number events that we only get because we're the window manager | 16:39 |
| smspillaz | so SelectionRequest and SelectionClear are basically two special events which exist when another window manager or compositing manager wishes to take over from us | 16:39 |
| smspillaz | sections are explained here | 16:40 |
| smspillaz | http://tronche.com/gui/x/xlib/events/client-communication/selection.html | 16:40 |
| smspillaz | they aren't really of all that much concern to compiz | 16:40 |
| smspillaz | the next is ConfigureRequest (will come back to ConfigureNotify in a second) | 16:41 |
| smspillaz | basically, in X11, we can set an event mask which stops all other application from being able to resize windows except us | 16:41 |
| smspillaz | (that being the magical SubstructureRedirectMask) | 16:41 |
| smspillaz | we do this on what's called the root window | 16:41 |
| smspillaz | which is the topmostlevel window in the window heirarchy | 16:42 |
| smspillaz | all windows are children of the root window | 16:42 |
| smspillaz | by selecting SubstructureRedirectMask on the root window, we are telling X11 that no client which is a direct child of this window should be able to resize itself | 16:42 |
| smspillaz | or move itself | 16:42 |
| smspillaz | or change its stack position | 16:42 |
| smspillaz | when that happens, compiz gets a ConfigureRequest event | 16:43 |
| smspillaz | at which point, compiz decided whether to allow the window to move, resize, or restack itself | 16:43 |
| smspillaz | (in most cases, it will just go straight through, however we may need to adjust the request a little so that windows don't go above, eg, panels) | 16:43 |
| smspillaz | by calling XConfigureWindow on the window, we override the substructureredirectmask and change the size,position,stacking of the window ourselves, usually what the application wanted | 16:44 |
| smspillaz | MapRequest is another important event | 16:44 |
| smspillaz | it happens when a window attempts to display itself | 16:45 |
| smspillaz | (using XMapWindow) | 16:45 |
| smspillaz | in that case, we need to set its initial position and also some properties on the window | 16:45 |
| smspillaz | then there are the "Notifies" | 16:45 |
| smspillaz | so ConfigureNotify happens whenever the size,position,stacking of a window *actually* changes | 16:46 |
| smspillaz | this is usually in response to us changing the size,position,stacking of the window ourselves, but watch out, because some windows are "override redirect" and will be able to change their positions anyways regardless of our SubstructureRedirectMask | 16:47 |
| smspillaz | there is also FocusIn and FocusOut which we use to handle focus stealing prevention | 16:47 |
| smspillaz | so once compiz processes these events, where do they actually go? | 16:47 |
| smspillaz | well, for any request that tries to *change* the size,position,stacking of a window, that's all handled in a function called CompWindow::moveResize | 16:48 |
| smspillaz | for any request that tries to create a new window, that's all in ::processMap | 16:49 |
| smspillaz | once a window *is* resized, restacked or moved, that's handled in CompWindow PrivateWindow::configure | 16:49 |
| smspillaz | err | 16:49 |
| smspillaz | PrivateWindow::configure | 16:49 |
| smspillaz | or PrivateWindow::configureFrame if it is a normal toplevel window | 16:49 |
| smspillaz | (eg reparented) | 16:49 |
| smspillaz | in response to a window being mapped, we've got CompWindow::map and CompWindow::unmap for UnmapNotfy | 16:50 |
| smspillaz | CreateNotify creates a new CompWindow | 16:50 |
| smspillaz | now finally there is this big block called PropertyNotify | 16:50 |
| smspillaz | in there are handlers for a whole bunch of changes to window properties known as "atoms" | 16:50 |
| ClassBot | There are 10 minutes remaining in the current session. | 16:51 |
| smspillaz | basically, applications set hints on windows for how they're supposed to operate | 16:51 |
| smspillaz | that's all specified in a standared known as the Inter Client Communications Conventions Manual and the Extended Window Manager Hints | 16:51 |
| smspillaz | here: http://tronche.com/gui/x/icccm/ and here: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html | 16:52 |
| smspillaz | protip: unless you want your brain to explode, I would NOT read those all at once | 16:52 |
| smspillaz | rather, if you hit a bit of the code which deals with a particular property, go look in those manuals | 16:52 |
| smspillaz | since those explain what that property does | 16:52 |
| smspillaz | for example, when a window changes state we get a property notify for _NET_WM_STATE (Atoms::winState) | 16:53 |
| smspillaz | the relevant section in the manual specifies what each state is supposed to mean | 16:53 |
| smspillaz | that's pretty much how compiz operates as a window manager | 16:53 |
| smspillaz | the logic controlling how each request and event handler is supposed to work is all implemented in window.cpp and screen.cpp | 16:53 |
| smspillaz | screen.cpp is the "toplevel" object handling the window management context | 16:54 |
| smspillaz | and window.cpp is for each window | 16:54 |
| smspillaz | ok, now how to make your stuff rock | 16:54 |
| smspillaz | once you've tracked down the bug, and fixed it in the implementation section or the communication section you can create a launchpad branch merge proposal | 16:54 |
| smspillaz | not that compiz is an upstream project as such you do not need to sign the contributor agreement for it | 16:55 |
| smspillaz | *note | 16:55 |
| smspillaz | merge propose your branch to lp:compiz-core | 16:55 |
| smspillaz | or if you're working on a plugin outside of core lp:compiz-$whatever-plugin | 16:55 |
| ClassBot | There are 5 minutes remaining in the current session. | 16:55 |
| smspillaz | (don't merge propose to lp:compiz-plugins-main or lp:compiz-plugins-extra) | 16:55 |
| smspillaz | once that's done, the launcher team and the other compiz maintainers will look over it | 16:56 |
| smspillaz | and approve and merge it if its good | 16:56 |
| smspillaz | happy bug fixing! | 16:56 |
| smspillaz | Now is the time to hit me with questions | 16:56 |
| smspillaz | (and not pet bugs) | 16:56 |
| smspillaz | !q | 16:56 |
| smspillaz | ok, we had a question and ClassBot isn't picking it up | 16:57 |
| smspillaz | QUESTION: (App writing) What's the best way to resize a ui file defined gtk window before showing it (getting dimensions from preferences before display), so Compiz will put in in a good place. Seems like the window size defined in the ui file is the only one compiz looks at. | 16:57 |
| smspillaz | so this is more of an app developers question | 16:57 |
| smspillaz | but basically, compiz places windows in the "least used space possible" | 16:57 |
| smspillaz | so if you want to get a good position, you should make the size of the application in the ui file the actual size that you plan to use | 16:58 |
| smspillaz | you can also modify the win_gravity hint | 16:59 |
| smspillaz | that will make a window more likely to be placed in a certain area of the screen by default | 16:59 |
| smspillaz | have a look at the section called "window geometry" in the Extended Window Manager Hints | 16:59 |
| smspillaz | okay, that's it | 17:00 |
| smspillaz | back to work for me :P) | 17:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Helping develop the Ubuntu Websites - Instructors: mhall119, nigelb | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 17:01 |
| mhall119 | hello everyone, my name is Michael Hall, and I'm one of the community webapp developers | 17:01 |
| mhall119 | you may not know it, but there are several projects that live under the *.ubuntu.com domain that are actually designed, developed and maintained by the Ubuntu community | 17:02 |
| mhall119 | among the biggest are the loco directory at http://loco.ubuntu.com and the UDS scheduler at http://summit.ubuntu.com | 17:03 |
| mhall119 | a larger (but by no means complete) list of these projects can be found under our umbrella project: https://launchpad.net/community-web-projects | 17:04 |
| mhall119 | most of our projects are written in Python and use the Django web framework | 17:05 |
| mhall119 | which makes them pretty easy to get started hacking on | 17:05 |
| mhall119 | the sites themselves are hosted on Canonical's servers, so we regularly interact with their IS team as well | 17:06 |
| mhall119 | any questions about community projects in general? | 17:07 |
| ClassBot | abhinav_singh asked: Are there PHP based web projects? | 17:07 |
| mhall119 | not yet, no, though we do maintain Wordpress and Drupal themes that match the ubuntu.com page | 17:08 |
| mhall119 | not that we have anything against PHP, it just so happens that the projects we've accumulated have all been Python | 17:09 |
| mhall119 | though status.ubuntu.com might be in PHP, cjohnston recently added that one so you can check with him | 17:09 |
| mhall119 | I'm going to single out the loco directory to show you how to get it set up, but the process will be similar across all of our django projects | 17:12 |
| mhall119 | first you need to find the development focus by checking https://launchpad.net/loco-directory | 17:12 |
| mhall119 | in this case, it's lp:loco-directory | 17:13 |
| mhall119 | so you can just run "bzr branch lp:loco-directory" | 17:13 |
| mhall119 | if you plan on making a single contribution, that's easy enough, but if you plan on working on multiple features or bug fixed, I'd highly recommend you follow the guide described here: http://micknelson.wordpress.com/2011/05/19/sharing-your-development-environment-across-branches/ | 17:14 |
| mhall119 | for loco-directory, there are instructions for setting up a python virtualenv here: https://wiki.ubuntu.com/LoCoDirectory/Development#Using_Virtualenv | 17:16 |
| mhall119 | virtualenv is great for python development because you can use python packages specific to your project, without them conflicting with versions used by other projects | 17:16 |
| mhall119 | Django provides a manage.py script that lets you perform various setup and maintenance activities, some of which I'll cover in a minute | 17:17 |
| mhall119 | it also provides a settings.py for configuring your project. | 17:18 |
| mhall119 | since some configuration settings are specific to your environment, you might want to override them by creating a local_settings.py, an example of which is included in the local_settings.py.sample | 17:19 |
| mhall119 | an example of why you would want this is database configuration | 17:19 |
| mhall119 | loco-directory uses postgresql by default, but that's a pretty big requirement for development, so you can tell Django to use an sqlite database, which is much simpler | 17:20 |
| mhall119 | once you have your django project configured, you will usually run "python manage.py syncdb", which will create any database tables Django needs to save your project's data to the database | 17:21 |
| mhall119 | after that, loco-directory provides a couple of commands for populating your database | 17:21 |
| mhall119 | the first is "lpupdate", which will perform a series of calls to Launchpad to retrieve the list of loco teams and their admins | 17:22 |
| mhall119 | this will give you the minimum amount of data that loco-directory needs, you won't have events, meeting or venue data | 17:22 |
| mhall119 | the second option is "import-live-data", which uses the loco-directory's JSON API to populate your local database with a copy of what is in the production site. This will give you everything you need to test out new features or reproduce bugs, but it can take a long time (upwards of an hour) do to the amount of data | 17:24 |
| mhall119 | you can do either of these by calling manage.py again: "python manage.py lpupate" or "python manage.py import-live-data" | 17:24 |
| mhall119 | but, by far the easiest option is to get a relatively up to date copy of someone else's sqlite database, which I happen to have for you here: http://people.ubuntu.com/~mhall119/loco-directory/ | 17:25 |
| mhall119 | once you have that, you can run "python manage.py runserver" to run the loco-directory through Django's built in web server, which is perfect for development and testing | 17:25 |
| mhall119 | any questions so far? | 17:26 |
| mhall119 | I guess not | 17:28 |
| mhall119 | each of our projects generally has a lead developer, who is your best point of contact for getting setup, as well as designing new features of solving bugs | 17:29 |
| mhall119 | for loco-directory, the lead is cjohnston | 17:29 |
| mhall119 | for summit it's nigelb | 17:29 |
| mhall119 | for cloud portal: daker | 17:30 |
| mhall119 | and for hall of fame it's cdbs | 17:30 |
| mhall119 | the leads generally set the targets for new features, and will also prioritize bugs if necessary | 17:31 |
| mhall119 | but you are encouraged to make whatever contributions interest you | 17:31 |
| mhall119 | some projects, like loco-directory, will tag small, easy bugs as "bitesize", and this is a good way for you to get starting making a contribution while you get familiar with the codebase | 17:32 |
| mhall119 | here's the list for loco-directory: https://bugs.launchpad.net/loco-directory/+bugs?field.tag=bitesize | 17:32 |
| mhall119 | once you have your local setup working, the process for contributing is generally the same: | 17:33 |
| mhall119 | 1) find a bug or feature to work on | 17:33 |
| mhall119 | 2) fix/implement it | 17:33 |
| mhall119 | 3) push it to a bzr branch on launchpad using "bzr push lp:~${your username}/${project name}/${branch name} | 17:34 |
| mhall119 | where ${branch name} is a unique name for your branch, typically something like "fixes-12345" where 12345 is the bug number | 17:35 |
| mhall119 | then you find your branch on launchpad and click the "Propose for merging" link and describe what your branch does | 17:36 |
| mhall119 | you should also add a "commit message" on this page, this is what will be added to the bzr log when your branch gets approved and merged | 17:36 |
| mhall119 | from there one of the developers on the project (not always the lead) will review your code, and either ask for changes or approve it | 17:37 |
| mhall119 | once it's approved, it will automatically be merged into the project's main branch | 17:37 |
| mhall119 | all of this is pretty standard for Ubuntu distributed development | 17:37 |
| === zyga-afk is now known as zyga | ||
| mhall119 | any questions? | 17:39 |
| mhall119 | you don't need to know Python to contribute either, there's plenty of work that can be done in the HTML, CSS and Javascript sides too | 17:40 |
| mhall119 | Oh, I forgot to mention, discussion of community web projects is held in the #ubuntu-website channel here on freenode | 17:44 |
| mhall119 | you can find one or more of us there pretty much any time of day, since we have contributors all over the world | 17:44 |
| ClassBot | pleia2 asked: you mentioned that launchpad.net/community-web-projects is not a complete list, is there a more complete list somewhere? | 17:46 |
| mhall119 | good question, unfortunately not | 17:47 |
| mhall119 | there are several sites that are different mixes of canonical and community involvement, like the wiki, planet, etc | 17:47 |
| mhall119 | also some that probably should be on there, but aren't yet, like status.ubuntu.com | 17:47 |
| ClassBot | pleia2 asked: do you know the status on the Ubuntu Team Reports project? (I get asked about such a thing a lot by teams who hate using wiki for reporting) | 17:48 |
| mhall119 | I don't, dholbach might be able to give you more information on that | 17:49 |
| mhall119 | I know it's come up in the past couple of UDSs, but we just haven't had anybody willing to lead the project | 17:49 |
| mhall119 | if there are any aspiring community web contributors who want to take it for a spin, that would be awesome | 17:50 |
| mhall119 | right now our list of projects is outpacing our number of contributors | 17:51 |
| ClassBot | There are 10 minutes remaining in the current session. | 17:51 |
| mhall119 | so there are plenty of places for people to get involved | 17:51 |
| mhall119 | and we are very encouraging to new contributors | 17:51 |
| mhall119 | any other questions before I'm out of time? | 17:52 |
| ClassBot | There are 5 minutes remaining in the current session. | 17:55 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Bug Triage Class - Instructors: hggdh, pedro_ | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 18:01 |
| hggdh | Hello. My name is Carlos de-Avillez. I am one of the administrators for the BugSquad and BugControl teams on Ubuntu. I have been around bugs for pretty much all my professional life -- causing them, or finding them, or fixing them (or all three in sequence, and not necessarily in the this order ;-). | 18:02 |
| hggdh | I started with Ubuntu in 2006, when I was trying to (yet again) find a Linux distribution that I felt more confortable with, and that did not need me to spend a lot of time tweaking the kernel, etc. And guess what... Ubuntu won! :-). I then joined the community, and started being active beginning of 2007. | 18:02 |
| pedro_ | Hola, My name is Pedro Villavicencio and i'm also one of the admins for BugSquad and BugControl teams on Ubuntu, I work as a Defect Analyst for the Desktop Team (so if you have bugs related to that please ping me) | 18:03 |
| hggdh | Now, as usual, questions should be asked on the #ubuntu-classroom-chat channel. If you want to ask a question, write it there, and precede it with 'QUESTION:'. For example: | 18:04 |
| hggdh | QUESTION: what does 'hggdh' mean? | 18:04 |
| hggdh | Let's get into the class now. | 18:04 |
| hggdh | First, who we are (https://wiki.ubuntu.com/BugSquad) | 18:04 |
| hggdh | The BugSquad is the team responsible for *triaging* bugs opened against Ubuntu and its packages. The term 'triage' is pretty much taken from medicine -- determining the priority of treatments based on the severity of a condition (see http://en.wikipedia.org/wiki/Triage). | 18:04 |
| hggdh | Different from medical triage, though, we do not expect human death as a consequence of delayed treatment. | 18:05 |
| hggdh | But we still need to triage: there are many more bugs than triagers; we have to be able to prioritise the bugs; we _should_ be able to address _all_ bugs eventually. | 18:05 |
| hggdh | For us, then, triage is the process of analysing a bug, verifying it indeed seems to be a valid bug, collecting enough data to completely describe it, and marking the bug 'Triaged', and give it an importance. | 18:05 |
| hggdh | Triage ends there -- it is not our responsibility to *solve* the bug: once the issue is identified, and all necessary and sufficient documentation has been added to the bug, triaging *ENDS*, and the bug goes on to a developer/maintainer to be worked on. | 18:06 |
| hggdh | Again: triaging *ends* when a bug status is set to Triaged (see https://wiki.ubuntu.com/Bugs/Status). | 18:06 |
| hggdh | This does not mean we do not solve bugs ourselves. Most of us wear a lot of hats, on (possibly) more than one project. But _triaging_ ends when the bug is set to Triaged. | 18:06 |
| hggdh | Now, another important point is being able to differentiate between bugs (errors in a programme/package) and support issues (how to use a programme/package, how to set up something). We only deal with *bugs*. | 18:07 |
| hggdh | Support requests should be redirected to one of the appropriate fora: https://answers.launchpad.net/, http://askubuntu.com/ , http://ubuntuforums.org/, an appropriate IRC channel, etc. | 18:08 |
| hggdh | With that in mind... | 18:08 |
| hggdh | DO: follow the advices and recommendations from https://wiki.ubuntu.com/BugSquad/KnowledgeBase: they can be used not only for finding more about your own issues, but *ALSO* for triaging somebody else's bugs. | 18:08 |
| hggdh | DO: read https://wiki.ubuntu.com/BugSquad/KnowledgeBase. Really. No kidding | 18:09 |
| hggdh | DO: read the Ubuntu Code of Conduct (http://www.ubuntu.com/community/conduct). A nice exposition of the CoC is also at https://wiki.ubuntu.com/CodeOfConductGuidelines. | 18:10 |
| hggdh | (if you wish to be a member of the BugSquad, we require that you sign it.) | 18:11 |
| hggdh | This -- the CoC -- is perhaps the major difference between Ubuntu and other projects: we try very hard to live by it. *NOT* signing it does not free one from been required to be civil. So... | 18:12 |
| pedro_ | Yes, remember that at the other side of the Computer there's a person , so please be nice | 18:13 |
| pedro_ | There's nothing much that you didn't learned before : | 18:14 |
| pedro_ | DO: be nice. Say 'please', and 'thank you'. It does help, a lot. Follow the Golden Rule (http://en.wikipedia.org/wiki/The_Golden_Rule), *always*. | 18:14 |
| pedro_ | DO: keep in mind that English is the official language on https://bugs.launchpad.net, but _many_ Ubuntu bug reporters are *not* native speakers of English. This means that many times we will get bugs that are badly written in English (or not in English at all). | 18:15 |
| pedro_ | And there's also Triagers who are not native English speakers, ie: myself and hggdh | 18:16 |
| pedro_ | and plenty more, so if you're triaging and not sure if your english is good enough, don't worry there's plenty of people to ask in #ubuntu-bugs about a comment you'd like to add to a bug report | 18:17 |
| pedro_ | try to do your best: | 18:17 |
| pedro_ | DO: Try to understand. Ask for someone else to translate it if you do not speak (er, read) the language (hint: the #ubuntu-translators and #ubuntu-bugs channels will probably have someone able to translate). Be nice -- always. "I cannot understand you" is, most of the times, *not* nice ;-) | 18:17 |
| pedro_ | and if you're unsure about something? | 18:18 |
| pedro_ | DO: ask for help on how to deal with a bug if you are unsure. Nobody knows it all, and we all started ignorant on bug triaging (and, pretty much, on everything else ;-). We have a mailing list (ubuntu-bugsquad@lists.ubuntu.com) : https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad, and we are always at the #ubuntu-bugs channel on freenode | 18:18 |
| pedro_ | You can ask either at the mailing list or at our IRC channel, there's plenty of folks there willing to help in a 24/7 | 18:20 |
| pedro_ | Please note that we do not _triage_ bugs on #ubuntu-bugs, or the ML -- we will answer and help on procedures and requirements. We will, though, point out deficiencies and missing data, and suggest actions. | 18:20 |
| pedro_ | DO: _understand_ the problem. A lot of times we see a bug where a _consequence_ is described, but not the _cause_. | 18:21 |
| pedro_ | The triager should do her/his best to understand which is which, and act accordingly. This may mean changing the bug's package, or rewriting the description, etc. | 18:21 |
| pedro_ | The point here is: if we do not understand what is the problem, then how can we correct it? | 18:22 |
| pedro_ | There are many ways to do that (er, _understand_, not solve); most will require learning | 18:22 |
| pedro_ | most processes & procedures for understanding a problem also have never been really ported/adapted to computing (differential diagnosis -- medicine --, fault trees -- nuclear reactors, rockets --, etc). So... right now, the best way is to learn more. To keep on learning. With time you will be able to _intuitively_ see a consequence. | 18:23 |
| pedro_ | Also, it is important to keep in mind that *correlation is not causation* (see http://en.wikipedia.org/wiki/Correlation_does_not_imply_causation). | 18:23 |
| hggdh | (and, on the correlation <-> causation issue, there is this very good xkcd strip, from today: http://xkcd.com/925/ ) | 18:25 |
| hggdh | so | 18:25 |
| hggdh | DO: Try to ask and find answers for some questions: WHAT did happen? WHY did it happen? WHICH COMPONENTS are involved? HOW did it happen? HOW can it be REPEATED? What has CHANGED (if it worked before)? | 18:26 |
| hggdh | DO: add a comment on every action you take on the bug (changing status, importance, package, etc). Although for you it may be crystal-clear the reasons for taking an action, this may not be true for others (in fact, a lot of times it is not clear, at all...). | 18:27 |
| hggdh | ok. There are only positive 'DO's so far. Enough is enough. | 18:27 |
| hggdh | DO NOT: add comments like "me too", "I also have it", "also a problem here", etc. These comments just pollute the bug, making it more difficult to find out what happened, where we are, and what is the next step. | 18:28 |
| hggdh | yes! Finally something to, ah, not do... | 18:28 |
| hggdh | INSTEAD, just mark it as "affects me too" (and subscribe to it, if you wish to know when the issue is resolved). | 18:29 |
| hggdh | DO: if you are starting on triage, browse the open bugs (there are about 80,000 of them) and look for one you feel _confortable_ with (or less unconfortable ;-). Ideally, you should be able to reproduce it. It does help if you start with bugs on packages you yourself use. | 18:29 |
| hggdh | We collected a set of Easy Tasks at: https://wiki.ubuntu.com/Bugs/EasyTasks/ ; that is a really good start if you don't know where to look at it first. | 18:30 |
| hggdh | And do get on to #ubuntu-bugs, and ask for help there when in doubt. We do not bite... | 18:31 |
| hggdh | Oh, since we are here: | 18:31 |
| hggdh | DO NOT: change a Triaged bug to New/Incomplete/Confirmed -- a triaged bug is OUT OF SCOPE for triaging. It is not our problem anymore (while wearing the triager's hat). | 18:32 |
| pedro_ | And one of my favorites : | 18:33 |
| pedro_ | DO NOT: assign yourself (or any other person) to a bug. Bug assignment is a clear, official, signal that "the assignee is actively working on resolving this issue". Nobody else -- including the developers/maintainers -- will touch this bug anymore. Instead... | 18:34 |
| pedro_ | DO: so... if you are triaging, and have asked a question/requested action from the OP (Original Poster), *subscribe* to the bug. Nothing is worse than a fire-and-forget action. | 18:34 |
| pedro_ | I've seen a few new triagers doing that, so remember that DO / DO NOT, is *really* important | 18:35 |
| pedro_ | Other that is on my list of favorites is : | 18:35 |
| pedro_ | DO NOT: confirm your own bugs. The fact that you see/experience a bug does not necessarily _make_ it a real bug. It may be something on your setup... | 18:35 |
| pedro_ | DO: follow suggested actions. For some packages we have more detailed 'howtos'. These are described under the https://wiki.ubuntu.com/DebuggingProcedures page. It is always a good idea to check them (and update/correct as needed). | 18:36 |
| pedro_ | Now, a lot of the packages we offer on Ubuntu come from different projects -- Debian, Gnome, GNU, etc. We call these projects -- where real development usually takes place -- "upstream". By the same reasoning, we say we are "downstream" from them. | 18:37 |
| pedro_ | The ideal scenario is we have our packages identical to what upstream provide, no local patchs (except, probably, for packaging details). | 18:37 |
| pedro_ | Having local changes increases the delta (the difference between what we provide and what upstream provides), and makes updates/upgrades more costly. So our patches, ideally, should be provided to the upstream project, and discussed there (and hopefully accepted). | 18:38 |
| pedro_ | Bugs affecting upstream projects have to be communicated upstream. This usually means doing a similar triage as we do here for a specific upstream (looking for an identical bug on the upstream project, and opening one if none is found). So: | 18:38 |
| pedro_ | DO: Look upstream, and open a new bug if needed; then *link* this upstream bug to ours (and ours to theirs). If you want to see how that process is done, please check https://wiki.ubuntu.com/Bugs/Watches | 18:39 |
| pedro_ | Many upstreams have different rules on how to open/work with/close a bug. Ergo, | 18:40 |
| === n1xNc0d3 is now known as muneeb | ||
| pedro_ | DO: follow upstream's processes when working upstream (in an old saying, "when you enter a city, abide by its laws and customs"). | 18:41 |
| pedro_ | DO NOT: Forward bugs upstream if you're unsure of the root cause, some bugs could be caused by an Ubuntu patch. | 18:42 |
| pedro_ | If you want to see if a package is patched by Ubuntu or not as a first clue look at http://patches.ubuntu.com/ | 18:42 |
| pedro_ | And.. | 18:42 |
| pedro_ | DO: Forward bugs upstream if you sure that is not caused by an Ubuntu patch. We have a set of instructions on how to do that at : https://wiki.ubuntu.com/Bugs/Upstream/ | 18:42 |
| hggdh | So... we triaged a bug, eventually a developer/maintainer got to it, and fixed it -- or so they say ;-) --.Our job now, is to check if the fix provided indeed: | 18:43 |
| hggdh | (1) *does* fix the bug; | 18:44 |
| hggdh | (2) does *not* introduce a regression (see http://en.wikipedia.org/wiki/Software_regression) | 18:44 |
| === jtaylor_ is now known as jtaylor | ||
| hggdh | For Ubuntu, a bug (on a stable release) is fixed by a SRU -- Stable Release Update, see https://wiki.ubuntu.com/StableReleaseUpdates. SRUs have to be tested and confirmed to follow (1) and (2) above. So... | 18:45 |
| hggdh | DO: test SRUs. This helps on allowing timely updates to the user base. | 18:46 |
| hggdh | Doing SRU Testing in most of the cases is an easy task to do, we always need help to deal with the queue: http://people.canonical.com/~ubuntu-archive/pending-sru.html | 18:46 |
| hggdh | If you're really new to Triage and Ubuntu but you want to help: | 18:47 |
| hggdh | DO: Consider requesting a Mentor, The BugSquad has a great program for that and you can find more info at : https://wiki.ubuntu.com/BugSquad/Mentors, or... | 18:47 |
| hggdh | DO: consider joining #ubuntu-bugs, and asking for help there. We -- the (so called) experienced triagers -- are all there. | 18:48 |
| hggdh | (I personally think going to #ubuntu-bugs to be more productive, since what I do not know (and there is a LOT of it) may be known by somebody else) | 18:49 |
| hggdh | BUT... please remember: | 18:49 |
| hggdh | DO NOT: Start doing triage work by your own, its always better to ask first to the people who know about it. | 18:49 |
| hggdh | and read the documentation we pointed to above ;-) | 18:50 |
| hggdh | #ubuntu-bugs is open 24/7 so if you're unsure please ask there first. We *will* answer, probably in the same hour :-) | 18:50 |
| ClassBot | There are 10 minutes remaining in the current session. | 18:51 |
| hggdh | Finally... (and this is not a DO/DO NOT): | 18:51 |
| hggdh | Please help. We need triagers, and we need triaging. | 18:51 |
| hggdh | thank you. | 18:51 |
| pedro_ | is there any questions? | 18:51 |
| pedro_ | seems not. Thanks all and remember if you have doubts about bugs just ask in #ubuntu-bugs ; we don't bite | 18:54 |
| pedro_ | thanks again! | 18:54 |
| ClassBot | There are 5 minutes remaining in the current session. | 18:55 |
| hggdh | we really do not bite, those more dangerous are kept in a special enclosure, and well-fed ;-) | 18:57 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Lubuntu Development - Instructors: phillw - Slides: http://is.gd/BpvE2K | ||
| ClassBot | Slides for Lubuntu Development: http://phillw.net/Slide_Lubuntu.pdf | 19:01 |
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 19:01 |
| phillw | Hiyas everyone :) | 19:01 |
| phillw | For those not using Learnid, I'll give a minute to grab the 8 slides from http://phillw.net/Slide_Lubuntu.pdf | 19:02 |
| phillw | This presentation is a quick introduction to Lubuntu and the scope for any budding developers in the various areas. | 19:03 |
| phillw | <Slide 2> A brief run down of what Lubuntu is and why Lubuntu is. | 19:05 |
| phillw | <Slide 3> Lubuntu came into being to add the lxde to the familiy that is *ubuntu | 19:06 |
| phillw | With 11.10 it is on track for full adoption | 19:06 |
| phillw | [slide 4] | 19:06 |
| phillw | [SLIDE 4] | 19:07 |
| phillw | As stated, Lubuntu is an easy to use member of the family for those who's computers simply lack the resources to run the other members. | 19:08 |
| phillw | [SLIDE 5] | 19:09 |
| phillw | Even within Lubuntu there are more than one variant, all giving Lubuntu but going about it slightly differently | 19:10 |
| phillw | The community builds are created in response to known issues and requests from the user base. | 19:10 |
| phillw | The starting point for all sections of help is https://help.ubuntu.com/community/Lubuntu/Documentation It pulls together links to both the docs area and to other parts of the project in one handy place. | 19:12 |
| phillw | [SLIDE 6] | 19:13 |
| phillw | The main change in 11.10 will be the adoption by Canonical. As we are still at the alpha stage of testing. To keep up to date head over to the Development area, and follow what is said on the Mailing Lists. | 19:14 |
| phillw | The alpha 2 is running late, as this is the 1st one to follow the official build, things have proven to be a little more complicated for the Developers. | 19:14 |
| phillw | [SLIDE 7] As with every project within the *buntu familiy there are lots of things to do. From Documentation, through art work, bug chasing / triaging / fixing. translation etc. etc. Pick an area (or areas) that interest you and come and jopin in. | 19:16 |
| phillw | There are things to do both on Lubuntu and LXDE itself. | 19:18 |
| phillw | [SLIDE 8] | 19:18 |
| phillw | Apologies that our Head of Development (Julien) cannot be here, I will Attempt to answer or point you in the correct area. Whilst I am quite Familiar with Lubuntu, I am one the Docs team and am not a Developer! | 19:19 |
| phillw | Oh, I've just had an update on the alpha 2 being late.... The problem is not in the build script, but in the state of oneiric repository itself. I'm on it. | 19:24 |
| phillw | Which for those familiar with the Black Arts of building iso's I am sure means something :) | 19:25 |
| phillw | !y | 19:26 |
| ClassBot | coalwater-testin asked: ok i don't understand 1 thing, lubuntu is just ubuntu with the lxde desktop right? so i don't understand how there could be a separate lubuntu development | 19:27 |
| phillw | There are certain things specific to Lubuntu, such as the use of LXTerminal etc. that are looked after seperately. | 19:28 |
| phillw | A fuller list of the LX specific areas can be found at https://wiki.ubuntu.com/Lubuntu/Testing | 19:30 |
| === yofel_ is now known as yofel | ||
| ClassBot | There are 10 minutes remaining in the current session. | 19:50 |
| ClassBot | There are 5 minutes remaining in the current session. | 19:55 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Project Lightning Talks - Instructors: nigelb | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 20:01 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Project Lightning Talks - Instructors: nigelb, tumbleweed, crazedpsyc, mhall119 | ||
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html following the conclusion of the session. | 20:01 |
| nigelb | Hello and welcome to lightning talks! | 20:01 |
| nigelb | Since the last few "weeks", we've been having a session on the last day that's just lightning talks | 20:02 |
| nigelb | Basically, we'll have people talk about a project they're working on | 20:02 |
| nigelb | and you guys can check out and proably help with the project | 20:02 |
| nigelb | First up today is tumbleweed. He's going to talk about Ubuntu dev tools. | 20:03 |
| nigelb | tumbleweed: Stage's all yours :) | 20:03 |
| tumbleweed | Thanks nigelb | 20:03 |
| tumbleweed | evening everyone | 20:03 |
| tumbleweed | for me it's pretty late on a friday evening, but hopefully there are a few people listening :) | 20:04 |
| tumbleweed | so | 20:04 |
| tumbleweed | ubuntu developers (like all developers) like scripting things where possible | 20:04 |
| tumbleweed | there's a whole bunch of really useful scripts in devscripts and ubuntu-dev-tools | 20:04 |
| tumbleweed | I recommend that everyone go and have a look through the list, even if you already have | 20:05 |
| tumbleweed | I keep discovering new things in devscripts, every time I look | 20:05 |
| tumbleweed | /usr/share/doc/devscripts/README.gz has a reasonable list | 20:05 |
| tumbleweed | and apt-cache show ubuntu-dev-tools will show you what's there | 20:05 |
| tumbleweed | I'll just present a couple of highlights | 20:06 |
| tumbleweed | last UDW, bdrung spoke about wrap-and-sort, which is a neat littel tool that sorts lists of dependencies in debian/control | 20:06 |
| tumbleweed | I find it makes packages far more maintainable (and recommend that my debian sponsorees use it in packages they mantain) | 20:06 |
| tumbleweed | If you haven't seen it, look at it | 20:07 |
| tumbleweed | ubuntu-dev-tools also has a couple of other useful bits: | 20:07 |
| tumbleweed | backportpackage makes it really easy to test a backport into your PPA | 20:07 |
| tumbleweed | pull-lp-source and pull-debian source make it really easy to download source packages without having to have deb-src lines for all releases in your /etc/apt/sources.list | 20:08 |
| tumbleweed | "pull-lp-source bash lucid" will get you the bash sourcepackage for lucid | 20:08 |
| tumbleweed | it can also pull old, superseded versions from lp's archives, or debian's snapshot service | 20:09 |
| tumbleweed | ok, that's my 5 minutes, back to nigelb | 20:09 |
| nigelb | Thanks tumbleweed! | 20:09 |
| nigelb | Next up, we have crazedpsyc. He's going to talk about Melia, which from the screenshots I saw was quite interesting | 20:09 |
| crazedpsyc | Thanks | 20:10 |
| crazedpsyc | Hey folks, My name is Michael Smith, and I am a python lover :) | 20:10 |
| crazedpsyc | I've just recently started a project called Melia, written in PyGTK | 20:10 |
| crazedpsyc | Melia is a desktop shell, meaning that it just sits on top of an existing desktop environment like GNOME or XFCE | 20:10 |
| crazedpsyc | If you'd like to take a look at some screenshots, go to http://strenua.github.com/Melia and click 'Take a Peek' | 20:10 |
| crazedpsyc | I'll start out by walking you through some of the features and goals of Melia | 20:11 |
| crazedpsyc | The biggest goal for Melia is to be completely mobile-ready, while remaining versatile enough to use on netbooks, laptops, and even desktops. | 20:11 |
| crazedpsyc | Another big goal is speed. You don't want your tablet or phone to take more than a few seconds to boot and log in, so we really have to work on 'de-bloating' everything. | 20:11 |
| crazedpsyc | The big, long-term goal is to create an entire touch-friendly distribution, where we will use parts of MeeGo | 20:12 |
| crazedpsyc | At the moment, Melia is not very polished. However it does have plenty of features, and there are many more on the way. | 20:12 |
| crazedpsyc | The most important features are mostly interpreted from other desktops including Unity, Gnome Shell, Gnome2 classic, and even a few ideas from KDE. | 20:13 |
| crazedpsyc | A quick summary of the top feaures: | 20:13 |
| crazedpsyc | - Customizability: Melia is completely themable, the launcher can be moved, resized, and much more... and soon Melia will support loading extensions, which can modify the shell in any way. | 20:13 |
| crazedpsyc | - Quicklists: Melia supports dynamic quicklists via its own simple API, and it will soon support Unity's quicklists as well. (soon being tomorrow in this case) | 20:14 |
| crazedpsyc | - Integrated notifications: Small, quiet notifications appear in the center of the panel, where you will soon be able to reply to IMs just like gnome shell. | 20:14 |
| crazedpsyc | - Indicators and systray: Melia currently has its own poweful indicator API, which is almost entirely compatible with Ubuntu's. Melia will also have a system tray similar to gnome shell's | 20:14 |
| crazedpsyc | - Native: Melia is written entirely in Gtk, so everything blends seamlessly | 20:14 |
| crazedpsyc | At this point I am the only developer for Melia, so my time is a bit stretched. I need help! One of the biggest tasks is porting Melia to PyGI (thanks pitti!). | 20:15 |
| crazedpsyc | Time's up already :) back to nigelb | 20:15 |
| nigelb | Thanks crazedpsyc | 20:15 |
| nigelb | crazedpsyc: Do you want to finish answering the questions before I go on to the next talk? | 20:16 |
| crazedpsyc | Only one question right now, but if there are more, I'm free in #melia :) | 20:16 |
| nigelb | cool | 20:17 |
| nigelb | Next up is mhall119! | 20:17 |
| nigelb | He got OMG!Ubuntu'd recently for his work on tomboy-pastebinit | 20:17 |
| nigelb | That's what he'll be talking about :) | 20:17 |
| mhall119 | thanks nigelb | 20:17 |
| mhall119 | so, I like tomboy, kind of a lot, I use it anytime I need to quickly write something down | 20:18 |
| mhall119 | however, it's not really useful for sharing, and a lot of time I'm writing stuff down in tomboy that I'm only writing down so I can share it later | 20:18 |
| mhall119 | what I ended up doing was just select-all, copy, open up paste.ubuntu.com, paste | 20:19 |
| mhall119 | over and over and over again | 20:19 |
| mhall119 | I also use pastebinit, a greate little command line tool written by stgraber | 20:19 |
| mhall119 | you can pipe anything to it, and it'll send it to a pastebin service, and print out the pastebin URL | 20:20 |
| mhall119 | for some reason, it took me a while to put 2 and 2 together | 20:20 |
| mhall119 | but when I did, I took an hour to learn C# and the Tomboy addin API | 20:20 |
| mhall119 | and I wrote an addin that will take the content of a note, pass it through the pastebinit command line tool, take the URL it spits out and open it in your browser | 20:21 |
| mhall119 | the result was tomboy-pastebint: http://mhall119.com/2011/06/pastebinit-for-tomboy-notes/ | 20:21 |
| mhall119 | it's nothing big, it's nothing fancy, but it cuts down a frequent task from 5 steps to 1 | 20:22 |
| mhall119 | there are things that would be nice to add to it, and I'd love to have someone better at C# helping me with it | 20:22 |
| mhall119 | project is here: https://launchpad.net/tomboy-pastebinit | 20:23 |
| mhall119 | instructions are in the source tree | 20:23 |
| mhall119 | any questions? | 20:23 |
| mhall119 | if not, that's my time | 20:25 |
| tumbleweed | hello again | 20:26 |
| tumbleweed | this time I'm talking about something not directly related to Ubuntu devolpment. Something I work on in my spare time is IRC bots | 20:26 |
| tumbleweed | every online community needs bots to help manage their channels | 20:27 |
| tumbleweed | but they can also be fun to play with and useful | 20:27 |
| tumbleweed | we went a bit all out, and tried ot create a bot (in python, of course) that would be really easy to write plugins for | 20:27 |
| tumbleweed | (and also great fun to have in your channel) | 20:27 |
| * tumbleweed has one here tonight | 20:27 | |
| tumbleweed | Ibid_: hi | 20:27 |
| Ibid_ | wussup | 20:27 |
| tumbleweed | I wrote a quite plugin for him while the last talk was happening | 20:28 |
| tumbleweed | http://pastebin.com/YP3JsALS | 20:28 |
| tumbleweed | it seems to work | 20:28 |
| tumbleweed | Ibid_: udw talk | 20:28 |
| Ibid_ | tumbleweed: I suggest: Growing the Ubuntu Server | 20:28 |
| tumbleweed | Ibid_: udw talk | 20:28 |
| Ibid_ | tumbleweed: I suggest: Growing the Ubuntu Community | 20:28 |
| tumbleweed | heh, that's a useful one | 20:28 |
| tumbleweed | anyway, the point of the project is to make a bot that's fun to have around and dead-simple to write plugins for | 20:29 |
| tumbleweed | in this one you can see it registers the plugin based on the regex in line 8, and puts together a response by making some random choices | 20:29 |
| tumbleweed | it can do a *whole* lot more | 20:29 |
| tumbleweed | Ibid_: what can you do? | 20:29 |
| Ibid_ | tumbleweed: I can help you with: administrative functions, bot accounts and permissions, debugging me, looking things up, remembering things, delivering messages, decisions, games, monitoring things, browsing the internet, conversions, silly fun stuff, calculations, system administration, software development and south african stuff. | 20:29 |
| Ibid_ | Ask me "help me with ..." for more details. | 20:29 |
| tumbleweed | Ibid_: help me with silly fun stuff | 20:30 |
| Ibid_ | tumbleweed: I use the following features for silly fun stuff: bash, bucket, choose, coffee, dinner, draw-aa, duel, dvorak, figlet, fml, fortune, insult, mlia, morse, nickometer, random, redirect, remind, rot13, saydo, tfln and werewolf | 20:30 |
| Ibid_ | Ask me "how do I use ..." for more details. | 20:30 |
| tumbleweed | Ibid_: how do I use choose | 20:30 |
| Ibid_ | tumbleweed: Choose one of the given options. You can use it like this: | 20:30 |
| Ibid_ | choose <choice> or <choice>... | 20:30 |
| tumbleweed | Ibid_: choose should I fix a bug tonight or go to bed early? | 20:30 |
| Ibid_ | tumbleweed: I choose go to bed early | 20:30 |
| tumbleweed | Ibid_: botsnack | 20:30 |
| Ibid_ | :) | 20:30 |
| tumbleweed | ibid.omnia.za.net / launchpad.net/ibid if you want to see more, or ping me on IRC | 20:31 |
| tumbleweed | that's my 5 mins | 20:31 |
| nigelb | Ok, so lightning talks are done! | 20:34 |
| nigelb | Sorry it was too short. | 20:35 |
| nigelb | Now, I'm handing over to mhall119 for some impromtu fun :) | 20:35 |
| mhall119 | ok, so I floated this idea to nigelb only a little bit ago, but I wanted to try having a reverse-lightning talk | 20:35 |
| mhall119 | what's that you say? | 20:35 |
| mhall119 | well, I'm glad you asked | 20:35 |
| mhall119 | in a reverse lighting talk, you get 5 minutes to tell people what you'd like to see made | 20:36 |
| mhall119 | so, if you've ever though "someone should write a program to do x", here's your chance to tell us | 20:36 |
| mhall119 | if it's interesting, maybe someone will do it | 20:36 |
| mhall119 | but you only have 5 minutes to describe it in enough details for a developer to implement it, so you're not getting a new OS or anything big | 20:37 |
| mhall119 | would anybody like to give it a shot? | 20:37 |
| mhall119 | nobody? | 20:38 |
| mhall119 | ok, well maybe we'll give this a try when we have time to advertise it prior to it actually happening | 20:41 |
| nigelb | Ok, then. We tried. | 20:41 |
| nigelb | Thank you all for showing up at the Ubuntu Developer Week! | 20:41 |
| nigelb | Until next time, this is a goodbye from the classroom team :) | 20:42 |
| nigelb | Don't forget we have an upcoming Ubuntu Cloud days! | 20:42 |
| nhaines | And don't forget next week is Ubuntu Community Week. :) | 20:45 |
| nigelb | Yes! that too :-) | 20:46 |
| pleia2 | oh, randall said he'd have the schedule put in calendar tonight so we can review over the weekend | 20:46 |
| pleia2 | \o/ community week! | 20:47 |
| ClassBot | There are 10 minutes remaining in the current session. | 20:50 |
| ClassBot | There are 5 minutes remaining in the current session. | 20:55 |
| === me is now known as Guest53140 | ||
| Guest53140 | apocalypse | 20:59 |
| ClassBot | Logs for this session will be available at http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html | 21:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || | ||
| === barjavel.freenode.net changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Project Lightning Talks - Instructors: nigelb, tumbleweed, crazedpsyc, mhall119 | ||
| PwnusMaximus | hi guys, whats the topic today? | 21:52 |
| pleia2 | Ubuntu Developer Week just ended an hour ago, you can view the logs from today here: http://irclogs.ubuntu.com/2011/07/15/%23ubuntu-classroom.html | 21:52 |
| PwnusMaximus | :( | 21:55 |
| PwnusMaximus | thanks for the link' | 21:55 |
| Sayyan | Is there somewhere with links to all the chatlogs? | 22:26 |
| === medberry is now known as med_out | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!