=== Andre_Gondim-afk is now known as Andre_Gondim === maco is now known as maco2 === stingernewt is now known as damionloop === IAmNotThatGuy is now known as mohi1 === mohi1 is now known as 15SAAJGOH === IAmNotThatGuy is now known as mohi1 === nhandler_ is now known as nhandler === IAmNotThatGuy is now known as mohi1 [12:14] abhi_nav: hello [12:14] hi abhijain [12:15] actully when i am on ubuntu prefrences window and try to connect devices >connect no connecticvity with my account [12:16] abhijain, but why are you here? this is not the channel to ask question? come in #Ubuntu === pjarnahomzz is now known as pjarnahom [15:03] hi === abhi_nav_ is now known as abhi_nav === abhi_nav_ is now known as abhi_nav [16:41] https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 about to start in 19 minutes in #ubuntu-classroom === Hutley is now known as Guest76305 [16:57] HELLO EVERYBODY, WELCOME TO DAY 3 of UBUNTU DEVELOPER WEEK! [16:57] before our first session of today kicks off, just a few organisational things, as usual [16:57] if you made it here, that's great, plus please also join #ubuntu-classroom-chat, which is where you can ask questions (yes, lernid does that for you already) [16:58] when you ask questions, please prefix them with QUESTION:, so they stick out [16:58] ie: QUESTION: What kind of music does Jorge Castro like? [16:58] etc [16:58] https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions has some description of all the upcoming sessions, plus also if you need to prepare for them somehow [16:58] hi [16:59] if you didn't get to see all the other sessions, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek - the logs are linked from there [17:00] first on stage are Nigel Babu and David Futcher - enjoy their session about Operation Cleansweep and Patch Review with them [17:00] thanks dholbach :) [17:00] thanks daniel :) === 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: Operation Cleansweep - Reviewing Patches - Instructors: nigelb, bobbo [17:01] ok! Now, we're kicking [17:01] Hello everyone, I'm Nigel and with me is David. We're going to talk about patch review. [17:01] * bobbo waves [17:01] I'd like you all to take a look at https://wiki.ubuntu.com/OperationCleansweep [17:01] This cycle, this is a very critical operation that we'd like to see carried out. As you can read [17:01] This cycle, this is a very critical operation that we'd like to see carried out. As you can read [17:02] grr [17:02] in the wiki page, operation cleansweep is about reviewing all the bugs in Launchpad against the Ubuntu project which have a patch attached. [17:02] (sorry folks, paste fail ;) [17:02] We have a lot of awesome contributors who write code to fix bugs, but we lose out on this awesomeness because we're slow to review the patches. [17:02] Its not something thats new to an open source project, but its something that we in Ubuntu would like to pay attention to and we NEED your help! [17:03] So how can you help out with patch reviews? [17:03] We have a script which automatically finds bugs with patches that need reviewing [17:03] Of course, it can't decide whether the patch is good or not, we need a human for this. This is where you guys come in [17:03] The script subscribes us to all Ubuntu bugs with a patch attached minus the packages that we exclude (https://wiki.ubuntu.com/ReviewersTeam/ExcludingPackages) [17:04] The first step to reviewing patches is to look at the current work queue. [17:04] We've got a big Launchpad query which filters out all the reviewed patches and just shows the ones we need to look at [17:05] You can find the bug list at http://tinyurl.com/2u7kf3b [17:05] AS you can see was have currently around 1500 bugs in the unreviewed queue [17:06] Those are bugs that have patches that need to be reviewed and we haven't gotten around to do [17:06] Just for perspective, we started out with just under 2000 bugs in that list [17:06] Yeah, we're getting there, but unfortunately new patches are added every day! We get almost 100 new patches a month, maybe more. [17:06] also nigelb's laptop just broke, so that's slowing us down too :D [17:07] heh, its getting fixed :) [17:07] We'll quickly summarize the process and we will show you some specific examples to get a better grasp of the idea. [17:07] Can all of us open the review guide? Its at https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide [17:07] So now you have the list of bugs. Pick a bug to work on. [17:08] Once you pick a bug, you have to reproduce the bug again. Sometimes the bug is fixed and someone forgot to close it from changelog or it was fixed upstream. [17:08] No point of the patch if the bug is already solved. Close the bug as "Fix Released" [17:08] If the bug is reproducible, the next step is to check if the patch applies. [17:09] If the patch is old, the source may have changed so much that the patch does not apply any longer. === daker_ is now known as daker [17:09] If the patch fails to apply or fix the bug, you should add the patch-needswork tag and ideally leave a comment explaining what is wrong with the patch [17:09] and ask the original author if he can re-write the patch. [17:10] f you can make sense of the code enough to correct, that would be even more great [17:10] fail, If* [17:11] This bug though will be off our list since we can't work with the patch unless its reworked. [17:11] If the patch applies and the bug still exists, we need to check if it fixes the bug. [17:11] Again, no point in a patch if the bug is present after applying the patch and run the program again. [17:12] If the patch works, we have a few options [17:12] Ideally we should forward it upstream for their take on it because we don't want to conflict with them if they have a better way of fixing it or if we introduce some dangerous regressions [17:13] Also, since upstream is the original author of the code, they have a good idea of what makes sense. [17:13] Encourage the patch author to forward the bug upstream or forward the bug upstream yourself, once the patch is forwarded upstream, add the patch-fowarded-upstream tag. [17:14] This helps us keep track of the good that came out of it (and jcastro gets the credit :p) [17:14] Depending on what upstream feels about it, you may need to modify the tag to patch-accepted-upstream or patch-rejected-upstream. [17:14] Sometimes though, the bug maybe a bit more critical than to wait for upstream to fix it and we're sure the patch is going to help us. [17:14] In that case, we forward the bug to Debian and add a 'patch-forwarded-debian' tag. [17:15] Again, depending on feedback from Debian, we mark the patch as and patch-accepted-upstream and patch-rejected-upstream. [17:16] In very rare cases though, the patch is just wrong and we have to reject it. [17:16] In that case, we tag the bug with 'patch-rejected' [17:16] In other cases the bug is so severe that the need to deal with it as quickly as possible [17:17] or the patch is so perfect, well tested and unlikely to cause regressions that we won't lose sleep if we apply it without upstream looking at it [17:17] In these cases, the patch is applied in the Ubuntu package, and then forwarded to upstream or debian [17:18] One extra complication is that sometimes patches onfly affect the packaging of an application [17:18] ok, so you've all asked some questions, we'll be answering those now [17:18] devildante67 asked: Does Operation Cleansweep include bzr branches or only patches? [17:19] It includes only patches. the bzr branches would follow udd and are sponsored in directly. [17:19] udd = ubuntu distributed development [17:19] joaopinto asked: when we have the technical ability to do so, is it ok to rework the patch ourselves or should we wait for the path feedback instead ? [17:20] like bobbo said earlier, if you can rework it, by all means, go ahead :) [17:20] AudioFranky asked: How do I know/find the exact Ubuntu source package version against which the original patch submitted created his patch? [17:21] If a bug was reported via apport, should be there in the bug report. Otherwise, its going to be a bit of guesswork based on version of ubuntu, date of filing, etc [17:21] joaopinto asked: are those tags/workflow written somewhere ? [17:21] You can often check using the date the bug was reported and matching it up with the changelog :) [17:21] thanks bobbo :) [17:21] Yes, Review process is documented [17:22] https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow [17:22] https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is your friend :) [17:22] mythos asked: the ability of the reviewer is never checked, so everybody can review patches? [17:22] Yes, everyone can review patches. Noone blocks you on anything. There is a team, but not being a member does not block you from contributing. [17:23] dupondje asked: when a patch is created for a important bug in for example lucid, and its fixed in maverick, do we still need to review it to get it into lucid then ? [17:23] It is a case-by-case situation, but this calls for an sru and the sru process [17:24] often, I've taken up sru for hardy or earlier releases when the patch was there, but it was fixed in a later ubuntu release and everyone forgot about sru [17:24] sru = Stable Release Update [17:25] ok, so ClassBot tells me the good news that question queue is empty [17:25] lets move onto some specfic examples [17:25] Bug #544242 [17:25] Launchpad bug 544242 in empathy (Ubuntu) (and 1 other project) "[PATCH] Empathy should allow users to toggle auto-away mode on/off (affects: 1) (heat: 38)" [Wishlist,Fix released] https://launchpad.net/bugs/544242 [17:25] This bug was opened with a patch provided by the reporter. It was subscribed by the subscription script with the patch tag. [17:26] The patch was forwarded upstream, and recieved the patch-forwarded-upstream tag [17:26] After upstream accepted this patch, it recieved the patch-accepted-upstream tag and is ready to be fixed in Ubuntu. [17:26] Bug #544242 [17:26] Launchpad bug 544242 in empathy (Ubuntu) (and 1 other project) "[PATCH] Empathy should allow users to toggle auto-away mode on/off (affects: 1) (heat: 38)" [Wishlist,Fix released] https://launchpad.net/bugs/544242 [17:27] fail [17:27] Bug #462193 [17:27] Launchpad bug 462193 in djvulibre (Debian) (and 2 other projects) "djvulibre-bin produces garbage in the root (/man1/*) (affects: 16) (dups: 2) (heat: 56)" [Unknown,Unknown] https://launchpad.net/bugs/462193 [17:27] This patch only had to go to Debian as the changes only affected the application's packaging [17:28] it makes non sense in most cases to send patches against the packaging to the upstream as they normally don't touch it at all [17:28] so it was forwarded to Debian and received patch-forwarded-debian [17:28] it was then accepted and receive patch-accepted-debian [17:29] and now we're waiting for the fix to be merged or synced into the Ubuntu archives [17:29] One last example [17:29] joaopinto asked: Once a bug gets patch-accepted-upstream, how do we ensure that the patch is applied to the current development package ? [17:29] bobbo: finish the example and we'll answer this :) [17:29] okay :) [17:30] Bug #33288 [17:30] Launchpad bug 33288 in poppler (Ubuntu Lucid) (and 2 other projects) "Evince doesn't handle columns properly (affects: 28) (dups: 9) (heat: 191)" [Medium,Fix released] https://launchpad.net/bugs/33288 [17:30] ah, that was a famous one :) [17:30] The patch was forwarded upstream, where it was rejected [17:31] it's now been fixed, however with a different patch [17:31] [17:31] heh, thanks bobbo :) [17:32] ok, so about the question [17:32] in our hurry to write this session up, we missed a step, which actually answers the question [17:33] when you decide to change the tga or comment on the bug, subscribe yourself to the bug. That way you can keep track of the bug. [17:33] When the patch is accepted upstream, you can either get it into ubuntu directly if its very severe or wait for it to flow downstream [17:34] But essentially, our mission would be complete, i.e. patches don't rot in launchpad and die [17:34] Also, contributors who write awesome patches don't get discouraged from writing more code [17:35] devildante67 asked: In the last example, the patch has been accepted, but the upstream bug is still set to Confirmed, even with the tag patch-accepted-upstram. How's that possible? [17:35] I've just checked this up [17:35] either the upstream bug report simply hasn't been updated [17:36] the upstream bug hasn't been updated - there is a comment "pushed to git master" [17:36] or it may be because we have cherry picked our patch from their git repository and they don'[t move from COnfirmed until it's actually been pushed out in a final release [17:37] joaopinto: To answer your question, you have to take the initiative. [17:37] If its a main application, talk to desktop team or other subteams if its in their packageset [17:37] they'll glady welcome the help [17:38] If its universe, try mailing the DM who's responsible for the package. [17:38] as long as there is an active package maintainer in Debian, all upstream accepted patches should filter down at some point [17:38] Now, if there is no active maintainer and the patch is good, you have to do some effort on the debian side [17:40] If a package is orphaned in debian, you can do a QA upload. [17:40] You'll need a DD who can sponsor you though. [17:40] A quick mail to debian-mentors mailing list should help you in that case [17:40] If you're not a packager, you can tell a MOTU and they'll hopefully keep track of the package for you [17:41] I'd like to point your attention to a package called galrey [17:41] http://packages.debian.org/sid/galrey [17:41] dropping a mail to the MOTU mailing list or shouting in #ubuntu-motu will at least put it onto a packager's radar [17:41] this package had a patch in ubuntu, its an orphaned package in debian [17:42] I spoke to a MOTU friend and she recommended uploading to debian directly, since we don't want to carry a diff. [17:42] A quick hop into oftc, #debian-mentors and in some time it was awaiting sponsorship and the DD who guided me uploaded into the debian archive [17:43] I put in a sync request and we got into lucid in a few days [17:44] joaopinto: I'll answer in here for that one [17:44] joaopinto asked "that's a bit odd, because a bug reporter expects a bug to be fixed for the current release, isn't that the goal of testing development releases :) ?" [17:45] Expectations are high, but that leads to trouble like diverging from upstream and diverging from debian. [17:45] If you've every done a 3-way merge, you'll know that we *really* don't want that [17:46] When packages are synced that's a better use of our time. Even if we don't work on Ubuntu directly at times. [17:46] Its a bit of a pain, but the reward is much better. More distro's carry the patch and more people have a happy time. [17:47] joaopinto: does that answer your question to some extent? [17:48] Anymore questions folks? [17:48] You see, bobbo and I both lost notes for this session and wrote it in 20 minutes before session started, so its a bit short :) [17:48] dupondje asked: if a bugreport has status 'incomplete' it has been rejected and doesn't need check anymore? Also 'Fix Commited' means is has been accepted? So no check needed neither ? [17:49] incomplete = we need more information abaout the bug from the reporter [17:49] Incomplete means that not enough information has been given in the report and we have asked for more [17:49] Fix Committed is a bit of an odd one in Ubuntu [17:49] it can mean many different things and it's often not used correctly [17:49] and desktop team uses it for a specific purpose which confuses us often. [17:50] Generally, fixed commited means the fix in repositry, but not yet rolled into a release. [17:50] There are are 10 minutes remaining in the current session. [17:50] basically for patch revirew purposes, it's best to ignore Fix Committed and focus on the patch-* tags on the bug instead [17:51] dupondje asked: if a bugreport has status 'incomplete' it has been rejected and doesn't need check anymore? Also 'Fix Commited' means is has been accepted? So no check needed neither ? [17:51] we did that one :) [17:51] fail, I can't work classbot [17:51] heh [17:51] empty queue, does anyone have any questions for the final 9 minutes? [17:52] none? Okay then [17:52] We'd lvoe for you guys to help out reviewing patches and reach the goals of Operation Cleansweep [17:53] Join us in #ubuntu-reviews [17:53] talk about it at your loco events [17:53] if you want more information or would liek some help getting started please feel free to drop into #ubuntu-reviews [17:53] Help us by reviewing 1 patch a day [17:53] Also, we have this beautiful progressbar that daker made for us [17:54] if you can showcase it on your website or blog that would be great [17:54] devildante67 asked: Is Operation Cleansweep a Maverick only operation, or do you plan on extending it for future releases? [17:54] The original plan was to get all 2000 patches reviewed by this cycle's releaase date [17:54] The focus is on getting unreviewed patches to 0 by maverick release [17:55] we'll have more patches and then our focus would be keeping it low all the time, reviewing them instantly [17:55] There are are 5 minutes remaining in the current session. [17:55] This i project was started to get rid of the huge pile of patches sitting in LP [17:56] so that in future, patches will be reviewed much quicker [17:56] jono just spontaneously came up with the idea [17:56] (and spontaneously assigned it to me :p) [17:56] nigelb: you asked for it :) [17:57] dholbach: heh [17:57] ean5533 asked: So who's fault is it that it got this bad? nigelb or bobbo? [17:57] Well, the situation got bad because we never had a system to deal with it [17:57] About 6 months back, I was innocently hanging out in #ubuntu-motu and said "I'm bored" [17:57] (big mistake) [17:58] penguin42 asked: What about patches in debian bug tracking system that fix bugs shared with us? [17:58] yes, in retrospect :p [17:58] Emmet a.k.a. persia said, "go review patches" and I started writing the workflow which we all perfected. [17:58] They are essentially patch-forwarded-debian [17:58] Okay we'd better clear off before the next session [17:59] thanks for listening and please get involved with Operation Cleansweep! [17:59] Yes, Thank you folks. I'm not going anywhere though. I'll talk about the "how to forward patches" with pedro :) [17:59] We're having a bug day for Operation Cleansweep next week so stay tune ;-) === 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: Forwarding Bugs And Patches Upstream - Instructors: pedro_, nigelb [18:01] Hello guys! My name is Pedro Villavicencio Garrido and i'm the guy behind the Ubuntu desktop bugs [18:01] today together with the awesome nigelb we're going to teach you how to forward bugs and patches upstream [18:01] I'm going to introduce you to the workflow we use for the GNOME bugtracker [18:01] * nigelb wave again === ext2 is now known as ext3 [18:02] which also applies to the freedesktop tone [18:02] s/tone/one [18:02] since they're using Bugzilla as well [18:02] if you never heard about bugzilla before -> http://www.bugzilla.org/ [18:03] the GNOME project uses as said Bugzilla for tracking their bugs reports [18:03] you can find it at https://bugzilla.gnome.org === pjarnahom is now known as pjarnahomzz [18:04] If a bug in launchpad needs to be send there what you need to do first of all is to well... create an account [18:05] assuming you're not familiar with it, at the top of the page there's a 'New Account' link [18:05] if you click on that you'll be redirected to a page which is https://bugzilla.gnome.org/createaccount.cgi [18:05] in most of the bug trackers out here the only requirement to create an account is provide a valid email account [18:06] and the GNOME Bugzilla is not an exception [18:06] so just provide your email account and you'll receive a confirmation email [18:06] just follow the steps described on that and your account will be ready to rock [18:07] Ok now you created your account so you're ready to start opening bugs upstream [18:07] but first! [18:08] it's important to search for already reported bugs [18:08] we don't want to start flooding upstream with duplicates [18:08] it creates a lot of more work for the maintainers and the bugsquad [18:09] alright for searching you need to go to [18:09] https://bugzilla.gnome.org/query.cgi [18:09] and put any text you'd like to search for , for example 'love' [18:11] if you did what i did you'll get a bug report [18:11] like this one: https://bugzilla.gnome.org/show_bug.cgi?id=438847 [18:11] Gnome bug 438847 in gnome "i love you" [Normal,Resolved: incomplete] [18:11] such of nice report isn't ? [18:12] that's how it looks a report on the GNOME Bugzilla ,will go a bit deeper in to that in a bit [18:12] now if you didn't find the report you're were looking for [18:12] what do to? [18:13] well an extra hint would be to search on the list of most frequently reported bugs [18:13] which is available here: https://bugzilla.gnome.org/duplicates.cgi [18:13] is your report there or not? [18:13] let's say : yes [18:14] now how can i know if that report is already being tracked on Launchpad? [18:14] there's a little trick for doing that [18:14] (don't tell anyone!) [18:14] for example if we want to know if bug https://bugzilla.gnome.org/show_bug.cgi?id=479979 [18:15] Gnome bug 479979 in window selector "Crash in wnck_task_button_glow()/cairo_translate()" [Critical,Resolved: incomplete] [18:15] is being tracked we need to pass something like this to launchpad [18:15] https://bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/479979 [18:15] click on that url [18:15] it will take you to a report in launchpad which is watching that upstream report [18:16] charlie-tca asked: that is a great report! [18:16] indeed charlie-tca ;-) [18:16] btw you can do that for all the bug trackers which are listed here: https://bugs.launchpad.net/bugs/bugtrackers [18:17] it helps a lot when you're searching for upstream reports [18:17] ok now let say that the report you're looking for is not on the upstream bug tracker, so you need to open a new one [18:18] Click on the New link at the top and a list of parts is going to be presented to you, if you don't know to which set a product belongs, just click on All and search for that program there, for example nautilus [18:18] bugzilla is going to show a long list , like the one here: [18:18] https://bugzilla.gnome.org/enter_bug.cgi?classification=__all === ZachK_ is now known as zkriesse [18:19] devildante67 asked: Can't we do that nice secret trick directly in the site? [18:19] not really in launchpad, there's no search box for those, but yeah would a neat wishlist [18:20] what i did for my workflow was to create a keyword on firefox so everytime i enter something like: gnome #123456 [18:20] Gnome bug 123456 in general "ItemFactory.create_items and bug" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=123456 === Jack is now known as Guest49040 [18:20] it will search automatically for that bugs for me instead of entering the whole url over and over again [18:21] ok if you click on the nautilus product you'll see something like this: [18:21] http://people.canonical.com/~pedro/new_bug1.jpg [18:21] where you have something similar to what we have in launchpad [18:21] a field to enter a Summary [18:21] Description , add an Attachment etc [18:22] now if you click on the "Show Advanced Fields" you'll see something like this: [18:22] http://people.canonical.com/~pedro/new_bug2.jpg [18:23] You can use either of those to open a new bug [18:23] most of the information which is requested there is already available in our bugs at Ubuntu [18:23] like the version of GNOME used, the version of the program, the summary etc [18:24] Now paste the title of the bug in launchpad and improve it if that title isn't good enough [18:24] it's always better to use something like "nautilus search freeze when searching for odp files" then "nautilus freezes" [18:24] also use a good description of the issue, add clear steps to reproduce it if applicable and add all the information that might be relevant like comments from users, screenshots or even screencasts [18:25] And if applicable add a keyword [18:26] a keyword is similar to what we call 'tags' on launchpad [18:26] you can see those used on GNOME at https://bugzilla.gnome.org/describekeywords.cgi [18:26] for example: use STACKTRACE for crashes with full debug backtrace [18:26] usability for well usability issues [18:27] documentation for bugs in the docs, etc etc [18:27] ok how a report forwarded from Ubuntu looks like [18:28] please have a look to https://bugzilla.gnome.org/show_bug.cgi?id=589386 [18:28] Gnome bug 589386 in general "Reverting changes when submenus are created make the submenus appear as alacarte-made-#" [Normal,New] [18:28] as you can see there, the format we use is to add a Link to the launchpad report [18:28] a description of the issue and if we have more information we add it as well like the logs on that particular report [18:29] simar_mohaar asked: does the trick yout told to find bugs in launchpad that is watching a upstream bug is applicable to free desktop also .. say eg - 21614 in freedesktop how to find on launchpad [18:29] yes that works for freedesktop too, let me give you the link [18:30] https://bugs.edge.launchpad.net/bugs/bugtrackers/freedesktop-bugs/21614 [18:30] those are the bugs that are watching that upstream report [18:30] maybe they could be marked as duplicate if they aren't yet ;-) [18:31] Ok If you saw that alacarte report [18:31] you'll see that the status are different than in launchpad [18:31] for example that bug was confirmed but the status is New [18:32] the New status in the GNOME bugzilla is similar to our Triaged status [18:32] and our New status there is UNCONFIRMED [18:33] there's a few status on bugzilla that you might not familiar with , you can read about those at [18:33] https://bugzilla.gnome.org/page.cgi?id=fields.html [18:33] so don't change the status to New if you just filed the report and nobody else confirmed it :-P [18:33] simar_mohaar asked: One more thing pedro, that how you create keyword in firefox like #56383 say so we don'y have enter the whole URL always.? Sorry I dinn't get it . :< [18:34] simar_mohaar, I can teach you how to do it after the talk ;-) [18:35] Alright let's assume you have your bug filed upstream [18:35] a shine and new upstream report [18:35] what to do now? [18:36] well what you need to do is to create a Bug Watch in Launchpad for that upstream report you just filed [18:36] how to do it? easy, you need to click on the Also affects project link which is available in every report at launchpad [18:37] you'll get something like this: http://people.canonical.com/~pedro/also-affects.jpg [18:37] where you can paste the link that bugzilla gives you [18:38] then just click on Add to Bug Report === abhi_nav__ is now known as abhi_nav [18:38] and your report will look like this one https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/510322 [18:38] Launchpad bug 510322 in gnome-panel (Ubuntu) (and 1 other project) "wnck-applet crashed with SIGSEGV in cairo_translate() (affects: 30) (dups: 4) (heat: 139)" [Medium,Incomplete] [18:38] a new field is going to appear [18:39] with the name of the project, status, importance and a link to that upstream report on the assigned to field [18:39] ok we're almost done! [18:39] what you need to do now, is to comment on the bug report in launchpad with something as: [18:40] Thanks for your bug report. This bug has been reported to the developers of the software. You can track it and make comments here: URL [18:40] where URL is of course the link bugzilla returns you previously [18:41] then you just need to change the status to Triaged or Confirmed if you don't have the rights to set it as Triaged and that's all! [18:41] this same second part of the workflow applies to mostly all of the projects in Ubuntu with upstream projects [18:42] what only changes is the how the upstream projects manage their bugs, with more keywords, some different status or severities etc [18:43] Ok i know you're all interesting on how to do it for Patches so i pass the mic to the awesome nigelb who is going to talk you about that [18:43] nigelb, stage is all yours! [18:43] thanks pedro_ [18:43] He conviniently has a call right now, so he's passed the batton to me [18:44] So, in the last session bobbo and I talked about why you need to forward patches, when you need to forward patchs, and to some extend where [18:44] I intended to give pedro the task of explaining the "how to forward" patches, but I see its come to me. [18:44] ;) [18:45] so, you've seen the gnome bugzilla and seen how it works and how to report a bug [18:45] if you scroll down a bugzilla bug, you'll see a table that lists the patches available (empty if no patches yet) [18:46] It looks like this http://imagebin.ca/view/GBIh_i5.html [18:47] if you click on the button, you'll go to another page [18:47] it looks like this http://imagebin.ca/view/GtvMF1.html [18:48] initially, it asks that you select a file to upload and give a description for it === mab is now known as Guest87736 [18:48] its a good idea to give the description as whatever it fixes, like "Fixes the crash that happens when you do $foo" [18:49] you can either force bugzilla to consider it as a patch or let it automatically decide whether it was a patch [18:49] then, enter a comment and press submit [18:49] viola! your patch is submitted upstream [18:50] you'll notice there is a field called "obsolete" [18:50] There are are 10 minutes remaining in the current session. [18:50] thats for when you've rewritten a patch (which was initially written by you) and you upload the new patch [18:50] you can mark the old one as obsolte [18:51] but they're smart people, they don't let you mark your patch obsolteling someone else's ;) [18:51] penguin42 asked: Is there anything that needs to be done to make sure it's traceable to the original author or the ubuntu bug it came from? [18:52] Well, personally a lot of us start the bug with "This bug was orginally reported in Launchpad, bug# 123" [18:52] that way other triagers know which one its linked to [18:52] mgamal asked: How should we forward patches to upstream projects that follow a different patch submission procedure (e.g. Linux Kernel)? [18:52] very good question [18:53] Each project has different specifications and rules, its very importannt that you read their guidelines if any [18:54] And, the Kernel is very special from other projects. Jfo can explain more on that. I'm not very familiar with their procedures [18:54] the freedesktop project also uses bugzilla and their patch submission interface looks very similar to gnome bugzilla [18:54] (well, its after all bugzilla with different themes) [18:55] here's how that looks http://imagebin.ca/view/BsKUieS.html [18:55] There are are 5 minutes remaining in the current session. [18:55] http://imagebin.ca/view/X0Fpl-pn.html [18:56] simar_mohaar asked: What exactly is a patch. If a patch provides a fix is it the same thing that we update to our system during Updates? [18:56] a patch is essentially a diff file. Its a diff of current source vs new source [18:56] And a patch is not what updates your system during update [18:56] I have one more bug tracker to talk about [18:57] this tracker deserves a session of its own [18:57] its very special in that, its one of the view that doesn't require that you sign up before you report a bug [18:57] but it doesn't let you file a bug from a webform [18:57] you have to either send a mail in a particular format or use a commandline tool [18:57] any guesses? [18:58] c'mon, no guesses? [18:58] yep, jacob [18:58] Its the Debian BTS [18:58] Its the tracker we all love to hate. [18:59] Its a bit complicated to work with. I won't be going into detail, but I'll give you some links where you can learn about it [18:59] http://www.debian.org/Bugs/Reporting [19:00] you can use that debian page to know more about reporting bugs on debian or use reportbug [19:00] reportbug is a commandline tool that helps you do it provided you can send email from your system [19:00] And with that, my time is done :) === 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: Daily Builds And You - Instructor: jcastro [19:00] Thanks folks for listening in! [19:01] alright! [19:01] hello everybody :) [19:01] welcome to our class [19:01] this session will be about daily builds, I'm Jorge Castro ... [19:01] and I'm Daniel Holbach [19:01] and we're working with the launchpad team to make daily builds a reality [19:02] before I start [19:02] let me give you some information that you need to follow along in this class [19:02] https://help.launchpad.net/Packaging/SourceBuilds [19:02] and all the pages in that section of the wiki will help you out [19:02] so first off, what the heck is a daily build? [19:02] Yes, https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted is the page you should probably bookmark :) [19:02] simply put [19:03] a daily build is a PPA that contains software from a project that is updated every day [19:03] so for example, if we have daily builds of gedit, then the daily build will have the code from that day in the PPA [19:03] so why would we do this? [19:03] First of all, the main reason is testing [19:03] if you're writing a program, you want to be able to test it [19:04] however because ubuntu releases are stable (meaning we don't update to new versions generally) [19:04] then this can be hard to get people to test. [19:04] ideally we want any upstream project to be able to fix a bug and enable users to check to see if it's fixed [19:04] and we plan to do this by offering the latest builds of things [19:05] it can be annoying when a developer tells you "try it with this patch, let me know if it works!" [19:05] with daily builds we can now easily test that software [19:05] and enable the upstream developer to get those fixes out to their users [19:05] which is what it's all about [19:05] however, there can be badness too, it's not all cupcakes and unicorns [19:06] if you commit broken code, it shows up in the daily build [19:06] since dailies are automated, if you break your code, this can break the software [19:06] some well run projects use things like distributed version control and unit testing to make sure that trunk always builds [19:06] this is a Good Thing(tm) [19:07]