[01:22] date -u [01:25] ecanto: you need to do that in the command line [01:25] @now [01:25] Current time in Etc/UTC: January 28 2010, 01:25:16 [01:25] cjohnston thanks. (: === ecanto is now known as dmesg === dmesg is now known as ecanto === tobias is now known as Guest12445 [15:47] * jcastro taps on the mic [15:49] * dholbach looks for the technicians to fix the feedback loop === dholbach changed the topic of #ubuntu-classroom to: Ubuntu Classroom || Support in #ubuntu || https://wiki.ubuntu.com/Classroom || https://wiki.ubuntu.com/Packaging/Training || Upcoming: Mon 25 Jan - Fri 29 Jan 2010: https://wiki.ubuntu.com/UbuntuDeveloperWeek || Run 'date -u' in a terminal to find out the UTC time | Ask questions in #ubuntu-classroom-chat === tobias is now known as Guest11086 [15:59] WELCOME EVERYBODY TO DAY 4 OF UBUNTU DEVELOPER WEEK! [15:59] If you don't know why you're here and what's going on, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek :-) [16:00] Questions all go to #ubuntu-classroom-chat and please prefix them with QUESTION so they stick out! [16:00] if you're uncomfortable asking questions in English, please head into one of the channels listed at the end of https://wiki.ubuntu.com/UbuntuDeveloperWeek [16:00] there will be people who will translate questions and answers for you if necessary (consider helping out yourself, please :-)) [16:01] OK, enough organisational mumbo-jumbo! [16:01] I'm here with the amazing Jorge O. Castro, jcastro! [16:01] woo hoo! [16:01] we have been preparing real hard for this session, hope you like it! === godzilla is now known as Guest53616 [16:02] And together we'll talk about Adopting an Upstream! Why it's fun, necessary and makes the world a better place. [16:02] jcastro: What's an Upstream? [16:02] that's a good question [16:02] first, when you get an ubuntu CD it comes with a bunch of great software [16:02] things like Firefox, Openoffice, GNOME, KDE, etc. [16:03] what Ubuntu does as a distribution is take all those things, assemble them into one operating system, and then ship [16:03] so, these projects, we call them upstream, like in a river [16:03] and distributions like us are downstram [16:03] and derived distributions like Mint would be downstream from us [16:03] so that's like all the software authors of those projects? [16:03] working with upstreams and downstreams is a critical part of ubuntu [16:03] right! [16:03] (I hope I encourage YOU ALL to ask questions too, I asked the first ones myself... :-)) [16:04] so, for example, it's critical for us to be able to work with upstreams like Firefox to ensure that we're shipping something users will love [16:04] so for example this week in #ubuntu-mozillateam you'll see our Ubuntu teams working with people from Mozilla [16:04] So there's millions of Ubuntu users and there's thousands of Upstream projects... looks like being there for both huge groups is quite an undertaking [16:04] so there's a bunch of cross boundary work going on there that some people don't see [16:05] right, especially when you're trying to fix a problem! But we'll show you how to do that when we get there [16:05] you'll see that sometimes putting a bug in the right place that we can be a service to upstreams when it comes to testing. [16:06] and when we fix problems it's of course our duty to make sure that those fixes get back upstream so that they can improve the overall quality of their project [16:06] and of course, the other half is ensuring that when upstream fixes bugs that we get those out to users, because at the end of the day that's what it's all about [16:06] so [16:06] I have been working on some wiki pages to help people get started [16:07] https://wiki.ubuntu.com/Upstream [16:07] It's unreasonable to expect every upstream author to know in detail how ubuntu works [16:07] some are content just making their software [16:07] and the other way around :) [16:08] so I've put together a little cheat sheet here for them (you can help improve this too if you find mistakes) [16:08] so that they can have one place to find important things, like when we freeze, what our security policy is, etc. [16:08] and also give them information on how things are going on the ubuntu platform [16:08] so if you wanted to find out about notify osd or messaging indicators, I've listed those there [16:09] now [16:09] one thing we've all been working on is a little program to give upstreams an "in" in the distro [16:09] this would be a person that does know how Ubuntu works [16:09] and is passionate about that specific piece of software [16:10] and wants to work on it in Ubuntu but also be there for the upstreams to answer their questions, be an information source, and be there when things go wrong [16:10] we call this Adopt a Package [16:10] dholbach: want to go into that for a little bit? [16:10] sure [16:11] https://wiki.ubuntu.com/BugSquad/AdoptPackage [16:11] and https://wiki.ubuntu.com/Upstream/Adopt [16:11] so to Adopt an Upstream can mean a couple of things [16:11] the most important one being that you act as a tie betwen Ubuntu and that upstream project [16:12] you can answer questions for people on that project, you know what's going on there, you know what's going on in Ubuntu [16:12] an easy example for "knowing what's going on" is: Upstream wants to ship a new feature release 2 weeks before the new Ubuntu release comes out [16:13] in that case you can talk to them and make it clear that it's hard to get that new feature release into Ubuntu because Ubuntu is already almost frozen [16:13] you can help with that kind of misinformation and help with the coordination early and explain what to do [16:13] jcastro and I will talk about the release cycle in more detail later on [16:14] another thing you can work on is bug reports [16:14] as we said before Ubuntu exposes great software to millions of users [16:14] of course these users occasionally run into problems [16:14] and they might not know what an upstream is! [16:14] exactly [16:14] so it's our job to triage those bugs, debug them, get as much information as possible and forward them to the upstream maintainers [16:15] because they are in the best position to work on the bug effectively [16:15] if we can fix it that's great, then we'll forward the patch to upstream [16:15] oh, so we can be good filters you mean? [16:15] exactly [16:15] we can weed out all the junk bugs so upstreams can concentrate on the ones with the best debugging info, descriptions, etc. [16:15] I've heard we have great tools for finding duplicates and dealing with crashes? [16:16] jcastro: maybe we should explain first what "to triage" means [16:16] yes. [16:16] you wanna do it? :) [16:16] https://wiki.ubuntu.com/Bugs/HowToTriage/ [16:16] sure! [16:16] so when users report bugs [16:17] they go into this big pile [16:17] to triage a bug means to subdivide that pile from one huge unmanageable mess to smaller piles [16:17] and as the bug continues on in it's lifecycle it will end up in the right pile [16:17] so, we might start with a big pile [16:17] but then we have smaller piles, kernel, desktop, printing, etc. [16:18] and then those get smaller === tobias is now known as Guest96094 [16:18] until you have a package, like say, nautilus. [16:18] bug triagers are people who sort the bugs in the right pile [16:18] then we might be able to get the bug confirmed, make sure we know in which release the bug occurs [16:18] the great thing about this is that you can do this without being too technical [16:18] then find the right steps to reproduce it [16:18] these days we have tools that do a good job of guessing what pile something should go in [16:19] but we also need to try to reproduce the bug so we can confirm it [16:19] this involves following what the reporter did [16:19] so if the report is "clicking on this button breaks printing" [16:19] https://help.ubuntu.com/community/ReportingBugs has a bit more detail about how this "guessing" works [16:19] then usually you try it, and see if you see the problem too [16:19] also, remember that we have millions of users [16:20] the better we isolate the issue, the less work the upstreams have, they can concentrate on fixing the bug :-) [16:20] I find that most times bugs sitting in the big pile have already been reported, so you can do a bunch of good just marking things as duplicates (if they are indeed duplicates) [16:20] right [16:20] also there's bugs with crash reportsf === tobias is now known as Guest76403 [16:21] Ubuntu has a fantastic machinery that gets as much debug information about those crashes as possible [16:21] automatically [16:21] https://wiki.ubuntu.com/Apport <--- here are pictures of what it looks like [16:21] so what was a painstaking job before (https://wiki.ubuntu.com/Backtrace) is a lot easier now [16:22] the end result is that we can say in function do_something() in line 45 of file bla/something.c the whole thing crashed [16:22] plus other things that developers might want to know :) [16:22] go and see Emmet Hikory's session on Friday about "Interpreting stacktraces" if you want to know more :) [16:22] are these important to send to upstreams? [16:23] they look important! [16:23] holy cow yes! [16:23] with all this information it should be a bit easier for upstream developers to find the cause for the crash and fix it [16:23] a crash in most cases means: the program is gone, it stopped working, unsaved work, etc you know what it's like [16:24] sometimes these crashes happen in special circumstances that didn't happen for the upstream developers when they tested it [16:24] in almost every discussion I was part of upstreams were happy about that kind of conversations and grateful for detailed bug reports [16:24] if you have questions about how to get started with bugs and everything check out https://wiki.ubuntu.com/Upstream/Adopt and talk to the fine people in #ubuntu-bugs [16:25] ok, so apport finds this and reports this to launchpad, what's the next step? [16:25] the Launchpad machinery will do its magic and add more debug information to the bug report [16:25] the next step would be trying to confirm the issue [16:26] if you can confirm it and maybe add some more details to what happened, you can have a look and see if it was already reports in the upstream bug tracker [16:26] if it was, see if you can add more information to the bug [16:26] if it wasn't report it [16:26] sometimes it's useful to have a look and see if upstreams have some kind of "debugging information" documented somewhere [16:27] for some of them it will be something like "start the program with --debug option" or something [16:27] a lot of that kind of information is listed at https://wiki.ubuntu.com/DebuggingProcedures and you should add info for your upstream project if you have any :) [16:28] also Launchpad has a great feature: you can link the upstream bug to the Ubuntu bug, right? [16:28] yeah [16:28] let me show you about that === godzilla is now known as Guest30844 [16:29] actually, give me a minute to find a bug [16:29] dholbach: do a dance! [16:29] * dholbach puts on some music and does the funky Upstream-Bug-Linking dance [16:29] https://wiki.ubuntu.com/Bugs/Upstream [16:30] ok so here is some documentation, depending on the bug [16:30] however, in general, you can just click "Also affects project" in launchpad, and paste in the bug url from the other bug tracker [16:30] https://wiki.ubuntu.com/Bugs/Watches [16:30] they looks like this [16:30] so you see there, on the top example, there's the bug in ubuntu, and the bug in the upstream project's bug tracker [16:30] in this case linux kernel bug 10911 [16:31] these are useful because with certain bug trackers [16:31] like mozilla's bugzilla, we can do neat things like syncing comments between the 2 bug trackers [16:32] https://bugs.edge.launchpad.net/ubuntu/+source/notify-osd/+bug/501393 [16:32] here is a good example of both ubuntu and mozilla developers working on a bug for example [16:32] however, just linking the bug can help [16:32] because it gives everyone a place to gather discussion around a bug [16:33] and especially for new users that might not know how things work [16:33] what other information can we help upstreams with dholbach? [16:33] tell me about this schedule [16:33] another fine thing you can do is: plan a Bug Day with your Upstream: invite them to https://wiki.ubuntu.com/UbuntuBugDay - triage bugs together, give people some coaching with that particular software - once you're good friends with your upstream, sky's the limit [16:34] alright... release schedule! [16:34] upstreams ask me all the time about the schedule [16:34] but sometimes I don't know what means what! [16:34] have a look at https://wiki.ubuntu.com/ReleaseSchedule [16:34] it shows our current release cycle [16:35] you can see how it goes from green in the beginning of the 6 months cycle to red at the end [16:35] green doesn't mean "it's all good, everything works" :-) [16:35] it rather means "everything's allowed from a developer point of view" [16:36] so we start with setting up the build tools in the beginning, plan features at UDS and merge with Debian (more on merges, syncs and Debian in a bit :-)) [16:37] at some stage we hit feature freeze, that's where we plan to have most of the feature in the distro [16:37] Xazax | why is the release cycle for upstream projects important? [16:37] doesn't mean they have to be all perfect [16:37] Xazax: will get to that in a sec [16:37] but it means that they have to be there and be test-able :) [16:38] so we move from feature development to fixing [16:38] and stabilisation [16:38] the later it gets in the release cycle the more conservative we get [16:38] to upload a small patch that fixes a crash 3 weeks before release is probably fine [16:38] but to upload a GIANT new release with n+1 new features will probably get you in trouble with the release managers [16:39] Jorge and I worked on a cheatsheet that makes it easier to understand what is allowed at which stage of the release cycle to ease the planning and coordination somewhat: http://people.canonical.com/~dholbach/cheatsheet.pdf [16:39] that's linked from https://wiki.ubuntu.com/Upstream/Adopt too [16:39] I hope that answers Xazax's question somewhat. [16:40] i would like to chime in on his question [16:40] sure [16:40] with things like a Long Term Support release it's critical for us as a downstream distro to communicate our release schedule [16:40] we sync our schedule with GNOME [16:40] so, we're kind of lined up [16:41] some upstreams want to know when they should release to have their software in ubuntu [16:41] so they can make a release, or decided to skip an ubuntu release, etc. [16:41] so, when we're at UDS [16:41] and we're talking to upstreams we make decisions on things dependent on release cycles [16:42] so it might be "well, that feature won't be ready in time, so we'll go with version 1.x instead" or something [16:42] that sounds very reasonable [16:42] whatever we can't fix during the release time, we have to fix after the release... jcastro: do you know how that works? [16:42] yes [16:43] it's a big source of confusion [16:43] so let's talk about Stable Release Updates [16:43] I think it all started with something like this: http://blog.somekool.net/images/img_4232.jpg [16:43] https://wiki.ubuntu.com/StableReleaseUpdates [16:43] doh! [16:43] shall I tell the story quickly before you move on? [16:43] yes! [16:43] ok [16:44] so in the very early days of Ubuntu we uploaded a couple of fixes (they all were upstream already) to the xserver to a stable release [16:44] that means that users who had installed the release (and not the development version) got those fixes [16:44] the developer had tested them all, they were upstream fixes and everything seemed good [16:45] the problem was that a certain percentage of our users (x% of some millions) suddenly had a broken Xserver [16:45] which resulted in people like my dad having to wrestle with: http://blog.somekool.net/images/img_4232.jpg [16:45] so we realised that we need to be more conservative with fixes like that [16:46] that's where SRUs originate from [16:46] jcastro: so how does this all work now? [16:46] https://wiki.ubuntu.com/StableReleaseUpdates [16:46] we have these [16:47] don't worry, it only looks scary! [16:47] the key point to remember here when talking to upstreams [16:47] is that really bad bugs should be communicated to distros [16:47] you see this all the time on like planet gnome [16:48] "wow, we found a bad bug in gstreamer, distros should ship this fix: $url" or something [16:48] as you hang out and talk with upstreams [16:48] at some point they will have a critical bug that will need to be fixed [16:48] so usually you can take ownership of that, talk to the ubuntu maintainer, and communicate the needs that way [16:48] sometimes upstreams fix small bugs [16:48] dhasenan: thanks [16:49] and of course those are good [16:49] whhooops [16:49] dholbach: thanks [16:49] * kfogel watches out for nick completion [16:49] but it can be frustrating to an upstream when the fix doesn't get into an SRU [16:49] it's just one of those things where the fix needs to be weighed with the risk [16:50] https://wiki.ubuntu.com/StableReleaseUpdates is pretty good at explaining what kind of fixes we want and which make sense [16:50] In general I think we do a good job here, but if an upstream still wants new crack in the distro, we have things like PPAs and backports [16:50] that's also an area where you can contribute [16:50] many ubuntu contributors set up and run PPAs as a service to upstreams for apps people love [16:50] http://people.canonical.com/~dholbach/cheatsheet.pdf should give you an overview over what to do in which case [16:51] that is highly encouraged, and a good way to learn packaging if you want to start the road to becoming an ubuntu developer [16:51] we only have 5 minutes left, so let's talk about debian for a bit [16:52] one of our most important upstreams is Debian [16:52] and we inherit a lot of packages and lots of great work from Debian developers [16:52] usually it works like this: if a package is unmodified in Ubuntu and we're before DebianImportFreeze (Check the release schedule again), it gets "synced" automatically [16:53] which means that the package in Ubuntu will get overwritten with the source that is in Debian right now (and rebuilt) === zen is now known as Guest90818 [16:53] if it's modified in Ubuntu, we need to figure out if we can drop out changes (then we'll ask for a sync) [16:53] and if we can't drop our changes, we need to merge the changes semi-manually [16:54] https://wiki.ubuntu.com/UbuntuDevelopment/Merging explains how the merging works and which tools we use [16:54] common scenarios for differences between Ubuntu and Debian are: [16:54] - we're in different parts of our release cycle and we decide to ship a newer version [16:55] - new improvements we want to try out in Ubuntu (launchpad integration of gnome apps, new indicators, new notifications, etc.) [16:55] and lots of other small things because of different things we support and not support [16:55] but generally the idea is: the more we can have in sync with Debian, the better [16:55] it means less merging, less maintenance hassle and a common code base to look at [16:56] so whatever is suitable in terms of patches to forward to Debian, we do forward [16:56] https://wiki.ubuntu.com/Debian/Bugs has more details on that [16:56] whew [16:56] that was alot of info! [16:56] and only one question, so either we were really great or really bad! [16:57] \o/ [16:57] that's the great thing about working on a certain piece of software is you get to know: lots of users (and make them happy with fixes), the upstream maintainers, lots of great Ubuntu developers that work with you and maintainers of others distros too [16:57] you not only make the world a better place by working on making software better for everybody, but you also get to know a lot of great people AND learn something new :) [16:58] one page you should definitely bookmark is: https://wiki.ubuntu.com/Upstream/Adopt :) [16:58] any final questions? [16:58] jcastro: any final words? :) [16:58] nope, thanks for coming everyone! [16:59] thanks everybody - you ROCK! [17:00] * ogasawara fades in [17:00] next up is Leann Ogasawara who will talk to us about "Kernel patches"! [17:00] Hi Everyone! Welcome to the Kernel Patches Session. [17:00] My name is Leann Ogasawara and I'm a member of the Ubuntu Kernel Team. [17:00] If you have any questions, please post them to #ubuntu-classroom-chat prefixed with QUESTION: [17:01] One of the biggest issues we face as a team is the large volume of bug reports we receive against the kernel. [17:01] One possible way to lend a helping hand is submitting patches to fix these bugs. [17:01] Submitting a kernel patch might seem like a daunting task, but hopefully after today's session it won't seem so intimidating. [17:01] There are five main items I'd like to cover in today's talk: [17:01] 1) Choosing bugs to patch [17:01] 2) Patch submission process [17:01] 3) Walk through an actual example [17:01] 4) Reasons for not applying a patch [17:01] 5) Getting Help [17:02] I should mention that the Ubuntu kernel team's ideal scenario is to have little to no divergence from the upstream linux kernel. [17:02] If a kernel patch will benefit Ubuntu users, it'll likely benefit all. [17:02] This is why it is important to make sure patches get submitted upstream. [17:02] Also, keeping the delta we have between our kernel and the upstream kernel as small as we can makes it much much easier to maintain the kernel from our end. [17:03] As such, the Ubuntu kernel team's preferred policy is for all patches to be submitted and accepted into the upstream kernel before pulling them into the Ubuntu kernel. [17:03] So how does this happen? [17:03] Let's begin with our first talking point. [17:03] == Choosing bugs to patch == [17:03] Ideally we want to isolate good bug candidates that could easily be resolved if a patch were applied. [17:03] A good approach might be to tackle the low hanging fruit first, ie bugs with patches already attached. [17:04] Launchpad has the ability to search for kernel bugs with patches attached. [17:04] https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bugs?field.has_patch=on [17:04] As I had mentioned previously, due to the large volume of bugs, there are times when bugs are filed with patches attached to fix an issue but they unfortunately get lost in the noise. [17:04] If we have additional volunteers trying to keep and eye on these types of quick fixes, it would be much appreciated. [17:05] Even just getting these types of bugs into a triaged state would be a great help. [17:05] If anyone is interested in getting involved, ping me after the session and I'be be happy to help get you started. [17:05] Many times we see a reporter will open a bug and mention the issue can be fixed with a patch that exists upstream alread. [17:05] Since the patch is already upstream, it's a simple process for a kernel developer to cherry pick the fix back into the Ubuntu kernel. [17:06] That is one example of how patches get pulled from the upstream kernel into the Ubuntu kernel. [17:06] However, not all bugs with patches can be resolved so easily. [17:06] Sometimes a bug will have a patch attached but the patch itself has not been submitted/applied upstream nor to the Ubuntu kernel. [17:06] These are the types of patches we want to focus on getting merged upstream and back into the Ubuntu kernel, assuming they are a valid fix. [17:07] It's helpful to inquire with the patch author about the nature of the patch. [17:07] Is the patch just a workaround for the issue but does not address the root cause? [17:07] Was the patch only meant for debugging purposes to isolate the issue? [17:07] We have to keep in mind that not all patches will be the proper fix. [17:07] If the patch is a band aid and not a proper fix, it shouldn't be applied. [17:08] On the other hand, if the patch author just needs assistance with submitting the patch, hopefully the information I talk about next will help. [17:08] If anyone ever has a situation where they have a question regarding a patch they've seen or personally written, please don't hesitate to contact the kernel team. [17:08] We're usually in the #ubuntu-kernel IRC channel on FreeNode and obviously also closely watch the Ubuntu kernel team mailing list. [17:08] I'd like to take a second here to pause and field any questions before we move onto discussing the patch submission process. [17:09] If there are no questions, we'll just move right along . . . [17:09] Navaneeth> QUESTION: Patches applied on ubuntu kernel are sent back to upstream? [17:09] Navaneeth: indeed we actually strive to push the patch upstream first, before applying to Ubuntu [17:10] Navaneeth: that might not always be the case so after each release, we review our delta from upstream and work to get the non-ubuntu specific patches pushed up [17:11] == Patch Submission Process == [17:11] First we need to confirm the patch does indeed resolve the issue. [17:11] If you yourself can confirm the issue is resolved with the patch, that's perfect. [17:11] Otherwise, we need to work with whomever has reported the issue and have them confirm the patch fixes the problem. [17:12] Once we have confirmation the fix is valid, we're ready to send the patch upstream. [17:12] If the bug the patch fixes happens to be reported in Launchpad, for completeness sake, the patch can be uploaded as an attachment to the bug report. [17:12] When uploading the patch, be sure to select the "This attachment is a patch" option. [17:12] Now, lets go through preparing the patch to submit upstream. [17:12] Upstream has this process clearly documented at the following link. [17:12] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/SubmittingPatches [17:13] I'll highlight some of the more important bits below . . . [17:13] 1. Know who/where to submit the patch. [17:13] This can be done by examining the MAINTAINERS file in the linux kernel tree [17:13] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=MAINTAINERS [17:13] 2. Be sure to create the patch against the upstream kernel source, not the Ubuntu kernel source. [17:13] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git [17:14] Note that some subsystems maintain their own git trees. [17:14] If this is the case, create the patch against the subsystem's tree. [17:14] The location of the subsystem's tree can also be found in the MAINTAINERS file [17:14] 3. Clearly describe what the patch is fixing. [17:14] Also be sure to break large patches up into small logical pieces. [17:15] A good rule of thumb is each patch should fix one specific issue. [17:15] 4. Be sure to note the version of the kernel the patch applies to. [17:15] When submitting a patch upstream, the patch should apply cleanly to the latest version of the upstream kernel available. [17:15] 5. Make sure the patch adheres to the kernel's coding style. [17:15] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=Documentation/CodingStyle [17:15] If you run scripts/checkpatch.pl, this should quickly detect any coding style violations. [17:16] 6. Make sure to maintain full provenance of the patch by signing off on the patch. [17:16] Signing off on the patch allows others to see the full history of who's written/reviewed the patch. [17:16] Signing off is done by simply adding the "Signed-off-by:" line to your patch. [17:16] 7. Send the patch as plain text in the email. [17:17] Do not attach the patch. [17:17] It's quicker to review a patch that's already present in the body of the email rather than having to download and open an attachment. [17:17] Your email client should provide a way to inline the text directly from the patch file into the body of the email. [17:17] Additionally, plain text allows others to respond and annotate their feedback directly in the context of the patch. [17:17] Be careful if you just cut and paste as this might have negative affects like switching tabs to spaces and therefore violating the kernel coding style. [17:18] Also, be careful that your email client doesn't mangle the patch by line wrapping the patch. [17:18] 8. Prefix the subject of the email with "[PATCH]" [17:18] This allows people to immediately know this is a patch being submitted. [17:18] 9. Don't give up. Be persistent :) [17:18] If the patch is not immediately applied there are usually reasons. [17:19] Take suggestions constructively and fix up the patch if necessary. [17:19] Patches might go through a few rounds of reviews and iterations before being accepted. [17:19] If there is no response or feedback after submitting a patch, don't be afraid to submit it again. [17:19] Eventually the patch should hopefully receive the required Ack's from upstream and get applied. [17:20] Once the patch is applied upstream it will automatically make it's way into the Ubuntu kernel upon the next rebase. [17:20] If the patch should be considered for a Stable Release Update to a previous kernel release, the patch must come via the upstream stable tree. [17:20] In order for a patch to be accepted into the upstream stable tree, the patch must meet certain criteria. [17:20] The patch should be relatively small in size (less than 100 lines of code). [17:20] The patch must fix a real issue, no hypothetical use case fixes. [17:21] The patch must already exist in Linus' tree upstream. [17:21] For a full list of criteria, please refer to the following: [17:21] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/stable_kernel_rules.txt [17:21] Submitting a patch to the upstream stable tree is as easy as sending the patch in an email to stable at kernel.org [17:21] Alternatively, when originally submitting a patch upstream, one can add a "CC:" line under their "Signed-off-by:" line. [17:22] For a more detailed explanation of sending a patch to upstream stable, ssee the stable_kernel_rules.txt file referred to above. [17:22] Once a patch has been submitted upstream, I usually like to add a reference to the upstream thread from the bug report. [17:22] This allows anyone wanting to track the current status of the patch to read and follow along with the thread upstream. [17:22] Again, if any patch author needs helps submitting a patch upstream, don't hesitate to ask those on the kernel team for help. [17:23] I'm going to pause once more to field any questions. [17:23] mirsal> QUESTION: What about using git to produce patches ? [17:23] mirsal: of course, that's an excellent way to generate your patch [17:23] mirsal: for those not familiar with git, the command it 'git format-patch' [17:24] Navaneeth> QUESTION: Will this session covers debugging kernel source code and fixing a bug? If not, is there any helpful materials available online? [17:24] Navaneeth: I'm going to walk through and example of a bug that was fixed and the patch pushed upstream [17:25] Navaneeth: it likely won't go as in depth into the debugging process as you'd like, I'll point you to helpful materials after the session [17:25] vishalrao_vbox> QUESTION: Do you @ubuntu have a hardware testing lab of sorts? For example can you test SSD support as you can see LP #502219 ? [17:25] vishalrao_vbox: we do have access to hardware we maintain in a lab [17:25] vishalrao_vbox: I do not know off the top of my head about the hw in the bug you note, but I'll take a look after the session [17:26] any other questions? [17:26] ok, we'll move along [17:27] == Example of Submitting a Patch Upstream == [17:27] I thought it would be a good idea to walk through an actual bug whose patch was sent upstream. [17:27] Lets take a look at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/366682 [17:27] This bug was about a system hanging on reboot. [17:27] This particular bug was fixed by creating a patch to add a reboot quirk for this particular system. [17:28] This patch would be beneficial not only for Ubuntu users but all users who had this hardware. [17:28] As such, this was a good patch candidate to send upstream. [17:28] From reading the report, you can see the original bug reporter was able to confirm the patch fixed the issue. [17:28] I, the submitter, carefully read the upstream SubmittingPatches document and made sure to adhere to the items outlined in that document. [17:29] Let's look at the actual email I posted: [17:29] http://lists-archives.org/linux-kernel/27263461-x86-asus-p4s800-reboot-quirk.html [17:29] 1) I tried to make sure I had a clear and well written description. [17:29] I made sure to clearly state what the issue was and what it is the patch was fixing. [17:29] I provided system information to help identify hardware that this patch would impact. [17:29] I made sure to note that the bug reporter had tested and confirmed the patch resolves the issue. [17:30] Additionally, I explained how and why it is I crafted the patch the way I did. [17:30] 2) I made sure to follow the upstream kernel coding style [17:30] 3) As you can see in the link, I inlined the patch within the body of the email [17:30] 4) "[PATCH]" was prefixed in the subject line of the email [17:31] 5) I examined the MAINTAINERS files to see that I should send the patch to the three subsystem maintainers (Thomas Gleixner, Ingo Molnar, H. Peter Anvin) and the x86 mailing list. I also CC'd LKML for good measure. [17:31] 6) I also saw from the MAINTAINERS file that they had their own linux-2.6-x86.git tree so I made sure my patch cleanly applied to the tip of this tree. [17:31] 7) As a final task, I made sure I signed off on the patch by adding my "Signed-off-by:" line. [17:32] The one thing that I failed to do was mention the version of the kernel this should be applied to. [17:32] :/ [17:32] Thankfully the patch was accepted and applied even with this slight oversight. [17:32] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4832ddda2ec4df96ea1eed334ae2dbd65fc1f541 [17:32] ^^ there's the patch in it's upstream form [17:32] Additionally the maintainer CC'd upstream stable when applying this patch. [17:33] As a result we have already had the patch come back to Karmic via the 2.6.31.9 upstream stable kernel. [17:33] This is the typical scenario of how a patch goes upstream first and then makes it's way back into the Ubuntu kernel. [17:33] There are obviously exceptions that are sometimes made. [17:33] If a patch is for example a Critical bug fix, the Ubuntu kernel team may opt to temporarily carry the patch while it's going through the upstream submission process. [17:34]