=== cratylus_afk is now known as cratylus [00:02] * cratylus is back. [00:02] JanC apologies for that still getting the hang of this client [00:02] will fix now [00:05] where can i get the logs of classroom? [00:05] heheh. i found. sorry the stupid question === Ancho is now known as Ancho|away === popey_ is now known as popey === thekorn is now known as _thekorn === _thekorn is now known as thekorn === copyleft_ is now known as copyleft === Ancho|aw` is now known as Ancho [11:47] hello [12:00] Hi class [; === JanC_ is now known as JanC === MosquitoOo is now known as MaWaLe === enli is now known as enli|afk [16:00] Hello hello === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Ubuntu Open Week - Current Session: Wine Q&A - Instructor: YokoZar || Questions in #ubuntu-classroom-chat [16:01] Good morning everybody, it's time to start the second day of Ubuntu Open Week [16:02] (08:02:41 AM) sebsebseb: YokoZar: afternoon here, plus in UTC, which is the time zone Open Week is going by :D [16:02] As sebsebseb has pointed out, there are in fact other time zones than mine. [16:03] I promise to use this information for good rather than evil [16:04] Now, this is meant to be mostly a Q+A session, as in the past I have received more than enough questions to cover an entire hour. Today's topic is Wine, and I've been Ubuntu's "Wine guy" from pretty much the start. [16:05] Wine, to give a brief summary, is the program that lets you run Windows applications on Ubuntu. Or, the way I like to think of it, once a program works in Wine it's no longer a Windows application, but rather just a plain old application that works in Ubuntu as well :) [16:07] (08:06:49 AM) johnsgruber: QUESTION: Is it possible, and safe to run something like quicken or Itunes under wine. Those are the two reasons I have to boot windows [16:08] There are two questions here, but they go together. As a general rule, the worst thing Wine can do when it attempts to run an App is not work. So if you want to know if you can run a program, it doesn't hurt anything other than your time to try it out [16:09] But there are likely many others who have tested the app before. If one of them is really nice, they'll have made a recent test entry in Wine's application database (http://appdb.winehq.org/) that you can read. [16:10] The Wine project is always looking for people who can provide more recent test results. We're also very keen on knowing if an application stops working as well as it did in the past (a "regression"), as it's much easier to fix them when they're caught quickly [16:11] As far as how well iTunes and Quicken work, I would suggest checking the AppDB as it depends on which version of Quicken and/or iTunes. Both applications are major targets of Wine developers and get worked on a lot, however iTunes in particular uses a lot of "weird" parts of the Windows API and has been a huge effort to get working. [16:11] (08:07:12 AM) sirmacik: QUESTION: Are You adding many changes/patches to the wine package on ubuntu? What they are changing in it? [16:13] I like to keep the Wine package as close to upstream as possible, however there will be a growing difference in later releases. The reason is that Wine's upstream consists of the "pure" Wine with hardly any interface - the Applications->Browse C: Drive link you see in the package, for instance, originates in Ubuntu [16:14] I will also be merging in (and providing my own code for) another upstream project called Vineyard, which I roughly designed a couple years back and was ultimately coded by Christian Dannie Stroggard. Hopefully I'll have a demo of this ready by the Ubuntu Developer Summit. I was originally planning to include it with Wine1.2, however that was not released in time for Lucid [16:15] Consequently, Lucid Wine looks very similar to Karmic Wine, except it's a newer Wine release and refuses to run executables that don't have the execute bit set (more on this later) [16:16] (08:07:45 AM) Nagz: QUESTION: Will the newly working iPhone/iPod access work with iTunes/wine ? [16:17] By this I assume you're talking about the ability to access iPods and iPhones in programs like rhythmbox for music. This does not affect Wine, as Wine can't use that interface to talk to the iPhones because the programs it runs that do it (namely iTunes) use a different method [16:17] What Wine needs to do that is code for a USB driver - then any arbitrary USB device that a Windows app needed to talk to would work (like iTunes) [16:17] This is different from certain standard USB devices like keyboards and USB sticks, which already work in Wine [16:18] It's a good example of two seemingly unrelated things (like, say, iTunes+iPods and a program that uses a USB license-key dongle) both needing the same underlying Wine component to work. [16:19] There used to be a bit of a joke race between Wine and Songbird about who could access iPods first, but they've both lost ;) [16:19] (08:08:35 AM) gquigs: QUESTION: I want to package some applications (https://bugs.launchpad.net/ubuntu/+bug/387753) that use wine, is their a guide to help me do it? [16:20] No not yet, however you can ask me personally and we'll work on this together. I've done it before as a prototype, and there are several ways to do it. I'm quite keen to have more Wine-powered applications in the repository. [16:22] If it's a free software application then we can also attempt to get it building under winelib, which would make things much easier in the future. Compiling from source is always nice anyway, however there is also work on porting Wine to ARM, and any winelib-based port would be able to start working on ARM without much additional effort -- even though Windows doesn't run on ARM at all! [16:22] *not technically true, since Windows Mobile has an ARM version and the Windows Mobile API is very similar to Win32 [16:23] (08:08:37 AM) freckle: QUESTION: is there plans to make buisness apps like Sage Line 500 run well under wine. Currently there are issues with paging screens. [16:24] So it's a little vague if I say that "all apps are supposed to work in Wine", but in a way it's accurate. Wine is developed with the principle of doing the "right" thing, ie exactly what Windows does. If a program isn't working it's because Wine developers have either not implemented a Windows function it's using or they've done it incorrectly. [16:25] The former is usually a FIXME: warning if you run Wine in the terminal, and the latter is either an ERR: message or just weird behavior [16:26] Regardless, any program not doing what it's supposed to be doing is a legitimate bug report to file at winehq.org, and if the fix is easy enough to do it can happen very quickly [16:26] That said, Wine developers do target specific apps to try and get working first. [16:27] Generally these applications are Codeweavers' supported applications (~80% of Wine development is paid Codeweavers staff), however there's also a lot of community patches, especially for popular programs. [16:27] (08:10:27 AM) sebsebseb: YokoZar: Do you think it is ok for Windows programs developer to opt out of making native Linux apps, if their app will work properly in Wine, without a user first having to mess around with wineconfig which tends to not be much fun, if fun at all. Plus most users don't really know how to use wineconfig properly. [16:27] I agree, I hate winecfg [16:28] Part of the work in the Vineyard project is to replace winecfg with something much nicer that asks only the essential questions [16:28] In an integrated desktop app. Think System->Preferences->Windows Applications [16:29] Any configuration that a user currently has to do in the registry or by mucking about with Wine should be handled automatically by Wine. [16:30] There's been some effort at making this a reality upstream. However there are a couple questions that we will always have to make configurable (such as which Windows version to emulate), and that's the kind of question that will live in the new configuration dialog. [16:31] As for whether it's ok for a developer to not make a "native" app, I think it's important to consider what the user experience is like. If the app doesn't work very well in Wine, then a native app would naturally have many advantages. However if the app works perfectly in Wine and requires no configuration, then it's a different matter [16:33] In principle a user doesn't even have to know that an app is using Wine internally, much like how Mac gamers don't know when programs are ported using Cider. This is all a question of packaging - in principle any Windows program could be turned into a proper Ubuntu package (depending on Wine internally), given .desktop entries so it runs from Applications->Games rather than Applications->Wine, given sane default settings, and [16:33] If you do all those things in a program that works perfectly in Wine there wouldn't be any real user experience difference between that and a Native port. [16:34] Porting with Wine rather than a "proper native" port also has advantages to the developer of letting them unify their code bases. Google's Picassa is ported with Wine in this way, for instance, and they use literally the same binary between Windows and Linux. [16:35] If I had more time I would like to help make this process easier for Windows developers to get their applications ported in a nice, usable way for Ubuntu. In principle we could even have a "make Ubuntu package based on Wine" plugin for Visual Studio ;) [16:35] (08:13:44 AM) mhall119|lernid: QUESTION: What is the current API version targeted by Wine? [16:35] All of them ;) [16:36] Seriously though, Windows technically has a different version of the API for each Windows version, but Microsoft tries to keep it as similar as possible. This is why programs written for 3.1 will still work in Windows 7 to a large extent [16:37] Microsoft does add new bits to the API of course (and thus new FIXMEs for Wine) [16:37] So Wine has some code in it that's "do this in Vista-mode, do this in XP mode", but most of Wine is just "do this", much like Windows is [16:38] Really, there's not much difference between switching Wine from Vista to XP mode and setting a Windows application to use "Compatibility mode" in Windows [16:39] Regardless, Wine developers target applications rather than a particular API version, as applications are what people care about. This is different from the approach of the Mono project, who do target versions of the .net API, but things are much cleaner with .net compared to Win32 [16:39] (08:14:45 AM) virtuald: QUESTION: Spotify recently added support to play mp3 files with windows codecs, but when it finds the string WINE-MP3 somewhere it fails, because it didn't work in their limited testing. What can be done about this? [16:40] Spotify can be harassed into working with Wine. I've actually tried to contact Spotify myself and talk with them personally, because I know they're keen to have better Wine support. They're actually really nice that way. [16:41] Regardless, it's more or less just another Wine bug, and there are quite a few open Spotify bug reports (in both Launchpad and winehq) [16:41] (08:26:56 AM) sirmacik: QUESTION: Wine is a piece of a really good software, but why it's logs are so unredable? Many times when it crashes it's log tells me nothin'. I know I should paste some sample but unfortunately I don't have any close at hand :/ [16:42] A few reasons for this. One may simply be not having the wine debug symbols installed (which are split into a separate -dbg) package, which gives more usable (to a developer) crash logs [16:43] The other reason is that Wine often doesn't know why it (or the application it's running) crashed [16:44] So if a program asks Wine how many bricks are in the great wall of China, and Wine tells it 2 million when it was supposed to say 3 million, you wouldn't see a "FIXME: wrong number of bricks" message in Wine. And the program might carry on working for a little bit, until later it runs out of bricks and the mongol hordes invade. [16:45] (08:29:40 AM) sebsebseb: [16:13] QUESTION: Do you think it is ok for Windows software developers to opt out of making native Linux apps, if their app will work properly in Wine, without a user first having to mess around with wineconfig, which tends to not be much fun, if fun at all. Plus most users don't know how to use wineconfig properly. [16:45] (08:30:06 AM) sebsebseb: YokoZar: I mean like utorrent for example website even says it's made for Wine [16:45] To clarify: I think it's ok if the user experience is basically the same as a "real" native app [16:46] Some native apps you have to go through a big hassle to download and install (like Doom3) [16:46] With uTorrent the experience is very similar: you go to a website, download the app, and install it. That's actually pretty much the same experience as you get on Windows [16:46] But in Ubuntu we can do much better, with proper packages and the Software Center. [16:47] So if, say, there were a uTorrent app with a minimal package that had some .desktop files and put it in Applications->Internet, and it were available through software center, I'd say it's ok that there's no native version. [16:47] (08:30:15 AM) virtuald: QUESTION: how do Vineyard relate to PlayOnLinux, wine-doors and winetricks? [16:48] Vineyard doesn't catalog specific apps like those projects do. It would work alongside them to replace the stuff currently in the Applications menu. [16:49] One part of Vineyard, for instance, is a python-wine interface. This allows me to write code for Software center to display installed Wine apps there, so you could then remove programs using Software Center rather than the awkward separate Wine uninstaller [16:49] (08:31:52 AM) amichair: QUESTION: How close is WINE to Windows nowadays? What's the probabiliy of a random windows app working correctly? And at what rate is that probability rising? (hopefully :-) ) [16:50] Higher than it used to be, for sure. It's gotten to the point where I expect most apps to work until I hear otherwise, even games. [16:50] There are are 10 minutes remaining in the current session. [16:51] I actually wondered that exact question - how fast is Wine improving - and went as far as making a mathematical model of Wine's growth [16:51] You can see it on my blog here: http://yokozar.org/blog/archives/48 -- there's even code to download and run your own simulation :) [16:52] But the executive summary is: given any reasonable model of Wine development, how we fix bugs, and what apps are affected by, we should expect applications to work at an increasingly fast pace. [16:52] This is what Wine developers call "collateral damage" - by making one app work by implementing something, you make part of another app work because it needed it too [16:53] Eventually these things add up, and you start having a whole lot of apps work without much (or any) specific effort [16:53] (08:41:25 AM) sebsebseb: YokoZar: as for Mono it apparnatly can run .NET version 1 apps, anything later than, that nope, since it's quite different to the actsual .NET. Plus then the whole Mono is bad for Linux distro's thing, because it uses a Microsoft programming technology #C and they could maybe patent sue distros over that or something. [16:54] So I should talk about Mono for a moment [16:54] It's a sister project in many ways [16:54] Although Wine doesn't communicate as much with Mono as it should [16:55] However there are a good chunk of .net apps that don't yet work in Wine. Wine is trying to make it so that if you install either Microsoft's .net runtime or Mono's .net runtime these applications will work. [16:55] There are are 5 minutes remaining in the current session. [16:56] The Mono project has missing parts of the .net API in much the same way that Windows does. We maintain a wiki page about what Wine needs from the Mono project, and what ultimately has to come from the community: http://wiki.winehq.org/Mono [16:56] There are some parts that Mono would accept into the code, but no one is getting paid to work on them officially. Stuff that would be valuable to Wine [16:57] The ultimate goal would be to run "impure" .net apps - so called "mixed mode assembly" apps that use both .net and the Windows API. These are things that can't run on "just" mono [16:57] They would need Wine too [16:58] As far as patents go, I am completely unworried by them. It's not because I trust Microsoft at all, but rather it's because Microsoft (and others) have so many patents on so many vague things that Mono is just as much as a problem as any other piece of software. There are even patents on CLICKING [16:58] (08:47:34 AM) sebsebseb: YokoZar: proper packages? as in native apps? [16:59] It's a good point - once a program is ported with Wine, installable via software center, and basically looks the same as any other program, it hardly makes sense to not call it "native" [16:59] But often people say "native" when they mean "the hard way of porting that doesn't involve Wine and requires manually rewriting DirectX to use OpenGL and so on" [17:00] Regardless, I believe I got every question. If I missed yours feel free to ask me personally :) === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Ubuntu Open Week - Current Session: Marketing Your LoCo Team - Instructor: leogg || Questions in #ubuntu-classroom-chat [17:00] The hour is now up. I believe leogg is next [17:01] Heya! [17:01] For those of you who don't know me... [17:01] My name is Leandro and I'm a member of the Ubuntu LoCo Council and an active contributor of the Ubuntu Nicaragua LoCo Team [17:02] Today I'll talk about "Tools, tips and tactics for promoting your Ubuntu Local Team" [17:02] My intention was to cover several areas, such as the Internet, video and audio production, graphics, newsletters, etc. [17:02] But I realized yesterday (when I gave this session at the UOW in Spanish), that one hour is not really that much time for this topic :( [17:03] So I'll give you the 'light' version and focus entirely on the Internet part [17:03] Hopefully, in the near future, I'll blog some more on this topic if you're interested :) [17:04] First of all... Why do you need to promote your LoCo? [17:04] * Recruit new contributors [17:04] * Share your experiencies with other teams around the world [17:04] * Show the awesomeness of your LoCo Team!!! :) [17:05] Let's begin taking a close look at the LoCo website [17:05] I assume that most (if not all) of the LoCo teams already have a website... [17:06] So... how is it working for you? [17:06] Is your website really effective? [17:07] Do the people who visit your website get involved in the community? [17:07] One of important questions we always forget to make is "What are the goals of the LoCo website?" [17:08] * To provide support and information about Ubuntu in your local language? [17:09] * To educate about free software? [17:09] * To create an organisational identity (e.g. Ubuntu users from North Carolina)? [17:10] * To expand your base and mobilise your supporters? [17:10] * All of the above? [17:10] We must know all the answers long before we even start to discuss about which platform we're going to use for the site === yofel_ is now known as yofel [17:11] The content and structure of your website will depend on what you want to use the website for [17:12] But if your LoCo already have a website? What can you do? [17:13] Well... good news! [17:14] As all of you know, Ubuntu has a new branding... and that's the perfect excuse for dumping that old dull site and have a new fresh start [17:14] Who knows? Maybe you'll be able to recruit new contributors for your team :) [17:15] Keep in mind: [17:15] The KISS principle! (no... it's not the band!) :) [17:15] http://en.wikipedia.org/wiki/Kiss_principle [17:16] "Keep it simple and straightforward" [17:17] A website with a overwhelming amount of information may look messy and can be hard to read [17:17] Remember: Your website is the face of your community to the outside world! [17:18] I really love http://ubuntu-za.org/ [17:18] Nice, simple, clean [17:19] (BTW, when are you guys releasing the theme? ;) ) [17:20] It might be a good idea to create a 'webmaster team' on Launchpad and a related project (your website!) [17:20] Webmaster team: [17:20] https://edge.launchpad.net/~ubuntu-ni-webmasters [17:21] Related project: [17:21] https://edge.launchpad.net/ubuntu-ni-website [17:21] Bugs! [17:21] https://bugs.edge.launchpad.net/ubuntu-ni-website [17:22] Using LP enables anyone on your team to file bugs against the website (as a way to track errors and improve the site) [17:23] You can also create blueprints, assign tasks and answer questions (support) [17:23] Resources for LoCo websites: [17:23] Drupal, FTW! - http://drupal.org/ [17:24] Most Ubuntu sites uses Drupal (it doesn't mean that you _must_ use it too, but it helps for visual identity and consistency all across the sites) [17:25] The Ubuntu Drupal Development wiki - https://wiki.ubuntu.com/UbuntuDrupal [17:26] Ubuntu Drupal Development Suite in LP - https://edge.launchpad.net/ubuntu-drupal [17:26] leogg: We changed (ubuntu-za) from media wiki because of the identiy thing [17:26] I prefer media wiki over moin moin [17:27] It's easier to use and tweak [17:27] But you're right abut the 'identity thing' [17:27] The look-and-feel is important [17:28] Your users must be aware they're on a Ubuntu site [17:28] Ok... I have no questions so far... [17:28] So I'll just move on :) [17:29] Next: [17:29] 2. Micro-blogging [17:29] Micro-blogging sites (such as identi.ca and twitter) allows users to send 'updates' (text-based posts called tweets or dents) up to 140 characters long [17:30] Twitter and Identica will allow you to send updates to one person, to a closed group of contacts or as public messages that can be seen by anyone [17:31] These updates are displayed on the user's profile page and also instantly delivered to other users who have signed up to receive them [17:31] Micro-blogging is a great tool that can deliver your message in a simple and effective way to hundreds (or even thousands) of people [17:32] If you haven't done it yet, create an account for your team [17:32] Go! Go! Go! :) [17:32] You can link your identica account to the twitter account [17:33] In that way all updates will appear on both sites [17:34] Another cool thing you can do is link your micro-blogging account to the blogs aggregated on your planet (if you have one) === apachelogger is now known as huntlogger === zen is now known as Guest72590 [17:35] That's a good idea if you don't have much spare time for tweeting/denting [17:35] http://twitterfeed.com/ [17:35] Make good use of your hashtags! [17:36] A post in identica with the !ubuntu hashtag will make your update visible to the more than 6,000 members of the Ubuntu users group [17:36] Again... Make good use of your hashtags! (use it wisely, do not spam!) [17:37] leogg: Do you know when canonical are going to release official themes/fonts? [17:37] Soon :) [17:38] Ivanka Majic, the Design Team Lead and all the guys at Canonical are doing a wonderful job! [17:38] But to be honest, I don't know when they're going to release the official artwork [17:39] Be sure to check out https://wiki.ubuntu.com/Artwork/VisualIdentity [17:39] How 'bout just using a Identica-group? Ubuntu-fi went for just creating one of those, and biweekly we gather a blogpost from all the (important) dents. Same post is also put to our Facebook-page. [17:40] That's a great idea! [17:40] We have one too :) [17:40] One of the reasons I avoid micro-blogging is precisely because it seems to become spam really fast. [17:40] True! [17:41] As I said... use your tools wisely and with moderation :) [17:42] !ubuntu is mostly converstations instead of announcements [17:42] Yep, and occasionally a lot of flaming [17:42] Let's move on... [17:43] 3. Social networking [17:43] This part may be somewhat controversial (considering that we are part of a free software community) [17:44] Facebook is not a free platform (neither is Twitter) [17:44] Should we, as free software communities, use (and promote the use) of non-free platforms? [17:45] My personal opinion on this: [17:45] YES! [17:46] As much as I would love to see the communities use 100% free software... [17:46] ...the reality is that "we must go where the non-Ubuntu users are" [17:46] It's useless to advocate about the benefits of free software to our community members [17:46] They already know this stuff! [17:47] We must cross the street and persuade our proprietary neighbours... yes, the ones who use Facebook :) [17:47] Social networks have a viral aspect: people may sign up to your cause because they've seen it in a friend's news feed or on their profile on a social network site [17:48] Make it easy for people to sign up by adding your social networking profile to your website. [17:49] * Create fan communities on the social network sites, and encourage your friends to participate [17:50] * Tell people to use specific tags so you can aggregate (bring together) all content they create that relates to your team [17:50] Resources on social networking: [17:50] There are are 10 minutes remaining in the current session. [17:51] Online communities - http://www.facebook.com/ [17:51] (not the only one, but at least the one we use as community) [17:51] Social bookmarking - http://delicious.com/ [17:52] Social news site - http://digg.com/ [17:53] leogg: Why did you split microblogging and Social networking, How did you feel they differ? [17:53] I think that social networks, such as Facebook, are way more flexible than the micro-blogging platforms [17:54] For example, you can upload videos and photos to FB and they show up on your profile [17:54] The same thing cannot be done with twitter or identica [17:55] Any more questions? [17:55] There are are 5 minutes remaining in the current session. [17:58] Well... that's all then... :) If you want to get in touch with me, just drop by #ubuntu-centroamerica [17:58] Thank you, guys! [17:59] leogg, Thank you so much! [18:00] Up next is Nigel Babu with Patch Team Review === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Ubuntu Open Week - Current Session: Patch Review Team - Instructor: nigelbabu - Slides: http://is.gd/bTRv0 || Questions in #ubuntu-classroom-chat [18:00] Slides for Patch Review Team: http://people.ubuntu.com/~nigelbabu/patch-review.pdf [18:01] Thanks Amber :) [18:01] nigelbabu, the floor is yours! [18:01] Hello folks! [18:01] I'm Nigel Babu from the Ubuntu Reviewers Team and I'm here to talk about patch review. [18:02] I've got a bit of ground to cover, so lets get started. [18:02] [SLIDE 1] [18:02] The slides for this talk is at http://people.ubuntu.com/~nigelbabu/patch-review.pdf [18:02] I'm not using them extensively, so if you don't have it, you're not missing much. [18:03] [SLIDE 2] [18:03] What does the Reviewers Team do? [18:04] Ubuntu has some amazing contributors contributing patches to bugs they encounter. [18:04] Over the past few years, we've not been able to handle this large influx of patches. [18:04] The Ubuntu Reviewers Team works to get these patches reported upstream and thus "give back" to the community. [18:05] The Ubuntu Reviewers Team get the patch, test it, and report it on the upstream bug tracker if the patch is working. [18:05] If a patch does not work as expected, the submitter is encouraged to submit a working patch to fix outstanding issues. [18:06] In case the submitter does not respond, the reviewer makes the modification giving credit to the submitter. [18:06] If a patch is critical enough, like a security issue or a major blocker, we work to getting it immediately into Ubuntu and forward upstream. [18:06] This may also qualify for an SRU to previous versions of Ubuntu. [18:07] [SLIDE 2] [18:07] How can you help? [18:08] While you can help in many ways, patch review is the important task for the Reviewers Team at the moment. [18:08] There are more than 1800 open bugs with patches attached that needs review. [18:08] I'll be covering how to do patch review today. [18:08] There are more ways that you can help, you can see https://wiki.ubuntu.com/ReviewersTeam/GettingInvolved for those. [18:09] [SLIDE 3] [18:09] [SLIDE 4] [18:10] Any quesetions so far? [18:10] moving on then [18:11] First step is to make a query for bugs with ubuntu-reviewers subscribed with only patch tag. Select one to work on. [18:11] you can see this query in https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide, its a very big link [18:11] Next step is to reproduce the bug [18:12] Unless a reviewer reproduces the bug, its kind of difficult to check whether the patch works ;) [18:12] Next, review the patch and test it. [18:13] If it does not work properly or needs more work, add the patch-needswork tag. Give the patch submitter some guidance on the rationale for the tag, and ask whether they are willing to update it to resolve outstanding issues. [18:13] If the patch works, subscribe yourself to the bug, forward the bug and patch upstream, and add patch-forwarded-upstream tag. If the change on the upstream package is debian specific, add the patch-forwarded-debian tag and forward to Debian. [18:14] oh yes, subscribing yourself on any bug is very important, this allows you to keep track of the feedback [18:15] The upstream developers may give positive or negative feedback on the patch, the next step is to review those [18:15] If upstream accepts the patch, remove patch-forward-upstream tag, and add patch-accepted-upstream (or patch-accepted-debian) tag. Indicate the VCS revision and/or expected upstream/debian version/revision that will include the bugfix. If the change is significant enough to be fixed in Ubuntu, get the patch uploaded. [18:16] An example of such a fix is a poppler bug that was fixed for lucid. Upstream accepted the patch a day after final freeze, but I talked to desktop team and got the fix for lucid. [18:17] If upstream requests patch rework, add the patch-needswork tag, and indicate how to find the upstream feedback on the patch in the bug report. Ask the patch submitter whether they are willing to work with upstream to resolve outstanding issues. [18:17] pretty much straightforward step this one [18:17] If upstream rejects the patch, remove patch-forward-upstream tag, and add patch-rejected-upstream (or patch-rejected-debian) tag. Copy the reasoning for upstream rejection into the Ubuntu bug. Whether the changes get into Ubuntu in this case depends on the will of Ubuntu developers backing the change. [18:18] Most of the times these changes may not make it into Ubuntu but some of them do make it ;) [18:18] If upstream ignores the patch for a moderate amount of time, add the patch-forwarded-debian tag and forward to Debian (Handle feedback from Debian similar to handling upstream feedback ) [18:19] upstream not responding is a situation that arises a lot of times, this step may alleviate the wait for some time. [18:19] And the final step is If the patch is unnecessary or addresses something that does not need to be fixed, add tag patch-rejected, give reason in the comments, and if required close the bug to Won't Fix. [18:20] So, thats the entire review workflow, its a bit playing with tags, because LP needs a little bit more work into handling each patch. [18:20] Any questions on this? [18:22] [SLIDE 5] [18:22] I seemed to have messed up my slide numbers when I listed them earlier ;) [18:22] How to Join? [18:22] Does this sound exciting enough? Want to help us out? [18:23] To join the Reviewers Team you need to: [18:23] 1. Sign the Ubuntu Code of Conduct. [18:23] 2. Be part of Bug Squad. [18:23] 3. Have knowledge of Ubuntu/Debian packaging. [18:24] All the 3 are very critical, you need to know how to deal with upstream trackers and also generate debdiffs. [18:24] You don't need to be an expert though, we're all around and willing to help [18:24] All you need to do is ping one of the team members [18:25] The current team members are the folks who are members of https://launchpad.net/~ubuntu-reviewers [18:25] If you have installed the launchpad greasemonkey scripts, the reviewers show up with a small bandage icon [18:26] A-R-R asked: I do want to help but I still need to learn Ubuntu/Debian packaging procedures. Where should I start learning from? Any recommended sources? [18:27] A-R-R: Excellent question, the best place is to look at the packaging guide in the MOTU documentation. [18:27] https://wiki.ubuntu.com/PackagingGuide/Complete [18:28] If you feel you're ready for being a team member, you can apply for membership in the launchpad team. [18:28] As with any Ubuntu development team, you are expected to already work as part of the team before you apply for membership. [18:28] Most of the work can be done without being a member, there is no blocker to do review if you are not a team member. [18:29] When you apply, be prepared to prove the review work that you've already done or have a current member vouch for your work. [18:29] Alternatively, come hang out on #ubuntu-reviews and do stuff until someone gets annoyed and bugs an admin to add you. ;) [18:29] Earlier in the yofel earned his membership that way :D [18:30] *Earlier in the day [18:30] Looks like I was kinda fast with the session, so I have plenty of time for questions :) [18:30] [SLIDE 5] [18:30] [SLIDE 6] [18:31] Patch Day (https://wiki.ubuntu.com/PatchDay) is now going on where we're mobilizing people to help review patches on May 5 in all time zones (adding to a total of 49 hours!). [18:32] We started at 1000 UTC today and we've covered close to 30 bugs by now! [18:33] The really big attraction of Patch Day is there will always be a review lead on the channel whom you can ask help and guidance. [18:33] The channel is #ubuntu-reviews btw [18:33] Feel free to participate and help out! [18:33] Patch Day runs till May 6 1000 UTC [18:33] So, any questions, please ask away [18:34] I have 30 minutes to take questions. I expected lots of them and kept time, don't disappoint me. [18:35] < vocx> About which kind of software are most patches? [18:36] Most of the time, its desktop applications that gets a lot of patches [18:36] The bugs that people find annoying and really want eliminated, we have one or two people annoyed enough to look at the code and find a fix :) [18:38] A-R-R asked: What exactly is meant by 'upstream'? [18:39] Most of the time, Ubuntu doesn't develop all the applications. We use other applications to make a product called Ubuntu. [18:39] Upstream is the original developer of the applications we use. [18:40] For example, the gnome desktop environment has an upstream in the gnome project, that is where the original developers coordinate [18:41] Patch review is done of all patches attached to bugs in Launchpad, but reviewers need to work on all upstream trackers [18:42] It may the gnome bugzilla, the debian bts, the kde bugzilla, and many others [18:45] MononcQc> is the patch and review team usually composed of the same programmers who implement new features or applications? [18:45] There may be an overlap, but its not intentional. [18:46] We have a lot of very versatile contributors who're everywhere (like maco, I keep running into her) [18:46] So, you may see the same people in many teams :) [18:46] if you could prepond your questions with 'QUESTION: [18:47] that would be really great, it saves me the trouble of copy pasting [18:49] Just wanted to point out that patch reviewers don't have to be very good programmers (or in some cases, programmers at all), so there should be people who are reviewers but are not writing new features [18:50] There are are 10 minutes remaining in the current session. [18:51] why would one submit a patch to launchpad and not submit a patch directly upstream? [18:51] If you can report it upstream, please do report it upstream. [18:52] Only, most people tend to submit(err.. not report) patches in Ubuntu bug tracker (launchpad) [18:52] Now, if the package is something that has someone caring abuot, things go fine [18:52] if its an orphan package, it ends up being on launchpad too long and we get a big backlog [18:53] and as maco reminds me, its easier to just report it in lunachpad and finding out the particular bug tracker and reporting it there. [18:54] report it in lunachpad *than* finding out the particular bug tracker and reporting it there [18:55] There are are 5 minutes remaining in the current session. [18:56] Also, dholbach will be taking 2 session on Friday about Ubuntu development and how to get involved, so that should help learn how to create debdiff, etc [19:00] so thats about it folks, thank you for participating :) [19:00] Thanks nigelbabu1 [19:00] Great session! === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - http://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Event: Ubuntu Open Week - Current Session: Adopting a Package and being an upstream contact - Instructors: jcastro, qense || Questions in #ubuntu-classroom-chat [19:01] qense and jcastro are up next the session will begin in about two minutes... [19:01] They will be going over - Adopting a Package and being an upstream contact [19:02] so stretch, grab something to drink and we'll get started in just a min or two :-) [19:02] oh my god, they're shooting at the dam! [19:02] welcome qense! [19:03] you've been introduced the floor is all yours! [19:03] a bit an unorthodox introduction [19:04] :-) [19:04] apologises, I'm a bit from my apropos, it just looked like someone starting shooting in the crowd at the NAtional Monument in Amsterdam, live on television [19:04] Seems alrgith now, lets start [19:04] Hello everyone, I'm Sense Hofstede -- https://launchpad.net/~qense -- and this session will be all about 'adopting a package and being an upstream contact', or Adopt-a-Package and Adopt-an-Upstream. [19:04] Unfortunately Jorge Castro (jcastro) is too busy to attend this session so I'll be doing this alone. [19:05] Lets first explain to you what the project actually is. [19:05] There are different ways of contributing to a distribution. For example, you could cherry-pick the tasks you'd like to work on, or you could choose to focus on a specific subset of the available tasks. [19:05] Everyone has a different approach that works best for her or him. However, you do work more efficiently and effectively when you focus on a clearly bounded area. [19:06] This is what Adopt-an-Upstream and Adopt-a-Package are: you focus on a project/application you like and make sure it rocks in Ubuntu! [19:06] Smaller applications can be adopted by a single person, but if the project's large or when it gets a lot of bug reports it quickly becomes too much to do on your own. In that case you should consider teaming up with a group of like-minded people and adopt as a group. [19:06] Now, it is quite some work to focus on all facets of a project's existence in Ubuntu -- I'd say you're no longer focusing then -- so you split the work up in different tasks. [19:07] When you're sure you want to adopt something and have decided what that something would be then it's time to start thinking which part of the work you want to adopt. [19:08] Because adoption of an upstream encompasses the following points: [19:08] Communication [19:08] both communicating Ubuntu schedules and announcements of importance to the upstream project to the upstream project, and communicating the project's schedules and announcement to the developers in Ubuntu that should know about it. [19:08] Bug triaging or Adopt-a-Package [19:08] That is: you work on triaging -- processing -- the bugs reported against the adopted project. More on this later. [19:09] Packaging [19:09] Making sure the latest version of the package is available in Ubuntu, either by merging or syncing it from Debian, or by packaging it yourself. [19:09] Forwarding patches upstream [19:09] For some bugs there are fixes available that Ubuntu maintains as patches. It's the best for everyone if those patches are also sent upstream so they can be included in the code. [19:09] You've been able to hear more about that in the previous session. [19:09] and finally: Representing the project in Ubuntu and Ubuntu upstream [19:10] This means being the contact person of that project in Ubuntu and the Ubuntu contact person upstream. [19:10] That sure are many things to do! [19:11] Lets talk a bit more about how we could do that, [19:11] It can happen that someone else is already working on one or more of the tasks I mentioned. [19:12] If someone or a group of people have already adopted a project then you should try to cooperate with them. [19:12] Some people have formed a team for adopting a project. [19:12] An example of this is the MozillaTeam: https://wiki.ubuntu.com/MozillaTeam [19:12] Although that team was created before Adopt-an-Upstream was started it is still a very good example for people that actually want to adopt a package. [19:13] Any questions so far? [19:14] OK, lets take a closer look at connecting with the upstream project. [19:15] Because that's the most important thing of it all and that's what Adopt-an-UPSTREAM is actually about. [19:15] First of all, please keep in mind that the upstreams are very important to Ubuntu -- without them we'd barely have anything in the repositories and nothing to run what we would have -- so please try treat them respectfully. [19:15] Although I'm sure most of you will. :) [19:15] There are a few actions you can take to make sure you don't miss anything you need to know. [19:16] First of all, if you're often on IRC, it is strongly advised to join the project's channel as well; this makes it easier for the upstream developers to contact you when they need to ask you something and allows you to quickly ask them your questions. [19:16] It's also a good idea to subscribe to the project's mailing list, or -- when there are multiple -- to the list that you'll most likely find the discussions on you want to follow. [19:16] Some projects also have mailing lists that are only used for sending release announcements, often with the release notes. [19:16] That is a valuable source of information and something you should pass on to the affected Ubuntu developers if it is interesting for Ubuntu. [19:17] drubin asked: Do you have to be an upstream dev to be apart of this? Also is there a formal process to be included on bugs related to that package? [19:18] drubin: You don't have to be an upstream developer in order to contribute. Experience from upstream is valuable, but it's certainly not required. It is helpful, though, if you have some experience with the specific area you're adopting. [19:19] drubin: If you want to be subscribed to all bugs of a certain package you can go to the bug overview page of that package and subscribe there. [19:20] Say, e.g., you want to get mail for all bugs reported against Nautilus on Launchpad you go to . You see a link at the left "Subscribe to bug mail". Press that and you'll get mail fora ll bug reports. [19:20] Be careful though, some packages get a lot of mail and you don't want your inbox overflowing with bug mail. [19:20] For upstream bug trackers it differs per tracker. [19:21] Lets continue. [19:21] If the upstream project chooses to make a radical change you should warn Ubuntu on time. [19:21] Example given: during the Ubuntu Developer Summit a collaborative text editor called 'Gobby' is used. A release or two ago, before the UDS for Ubuntu 10.04 Lucid Lynx, a new version was released which changed the protocol. [19:21] In order to make sure that everyone, even those that don't use the latest release of Ubuntu, can participate Ubuntu decided to stick to the old protocol. [19:22] The new release of Gobby was packaged separately and the previous Gobby release was left in the repositories so it could be used during the UDS. [19:22] This is something upstream adopters could help with. [19:23] On the other hand, of course, when large changes are made in Ubuntu -- like the Application Indicator that were added to Ubuntu Lucid -- it is the task of the adopter to notify upstream and cooperate with them in adding support for it to the project. [19:23]