| === 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 | ||
| abhijain | abhi_nav: hello | 12:14 |
|---|---|---|
| abhi_nav | hi abhijain | 12:14 |
| abhijain | actully when i am on ubuntu prefrences window and try to connect devices >connect no connecticvity with my account | 12:15 |
| abhi_nav | abhijain, but why are you here? this is not the channel to ask question? come in #Ubuntu | 12:16 |
| === pjarnahomzz is now known as pjarnahom | ||
| maja87 | hi | 15:03 |
| === abhi_nav_ is now known as abhi_nav | ||
| === abhi_nav_ is now known as abhi_nav | ||
| dholbach | https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 about to start in 19 minutes in #ubuntu-classroom | 16:41 |
| === Hutley is now known as Guest76305 | ||
| dholbach | HELLO EVERYBODY, WELCOME TO DAY 3 of UBUNTU DEVELOPER WEEK! | 16:57 |
| dholbach | before our first session of today kicks off, just a few organisational things, as usual | 16:57 |
| dholbach | 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:57 |
| dholbach | when you ask questions, please prefix them with QUESTION:, so they stick out | 16:58 |
| dholbach | ie: QUESTION: What kind of music does Jorge Castro like? | 16:58 |
| dholbach | etc | 16:58 |
| dholbach | 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 |
| delcoyote | hi | 16:58 |
| dholbach | if you didn't get to see all the other sessions, check out https://wiki.ubuntu.com/UbuntuDeveloperWeek - the logs are linked from there | 16:59 |
| dholbach | first on stage are Nigel Babu and David Futcher - enjoy their session about Operation Cleansweep and Patch Review with them | 17:00 |
| nigelb | thanks dholbach :) | 17:00 |
| bobbo | thanks daniel :) | 17:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Operation Cleansweep - Reviewing Patches - Instructors: nigelb, bobbo | ||
| nigelb | ok! Now, we're kicking | 17:01 |
| nigelb | Hello everyone, I'm Nigel and with me is David. We're going to talk about patch review. | 17:01 |
| * bobbo waves | 17:01 | |
| nigelb | I'd like you all to take a look at https://wiki.ubuntu.com/OperationCleansweep | 17:01 |
| nigelb | This cycle, this is a very critical operation that we'd like to see carried out. As you can read | 17:01 |
| nigelb | This cycle, this is a very critical operation that we'd like to see carried out. As you can read | 17:01 |
| nigelb | grr | 17:02 |
| nigelb | 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 |
| nigelb | (sorry folks, paste fail ;) | 17:02 |
| nigelb | 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 |
| nigelb | 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:02 |
| bobbo | So how can you help out with patch reviews? | 17:03 |
| bobbo | We have a script which automatically finds bugs with patches that need reviewing | 17:03 |
| bobbo | 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 |
| bobbo | 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:03 |
| bobbo | The first step to reviewing patches is to look at the current work queue. | 17:04 |
| bobbo | 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:04 |
| bobbo | You can find the bug list at http://tinyurl.com/2u7kf3b | 17:05 |
| bobbo | AS you can see was have currently around 1500 bugs in the unreviewed queue | 17:05 |
| bobbo | Those are bugs that have patches that need to be reviewed and we haven't gotten around to do | 17:06 |
| bobbo | Just for perspective, we started out with just under 2000 bugs in that list | 17:06 |
| bobbo | 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 |
| bobbo | also nigelb's laptop just broke, so that's slowing us down too :D | 17:06 |
| nigelb | heh, its getting fixed :) | 17:07 |
| nigelb | We'll quickly summarize the process and we will show you some specific examples to get a better grasp of the idea. | 17:07 |
| nigelb | Can all of us open the review guide? Its at https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide | 17:07 |
| nigelb | So now you have the list of bugs. Pick a bug to work on. | 17:07 |
| nigelb | 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 |
| nigelb | No point of the patch if the bug is already solved. Close the bug as "Fix Released" | 17:08 |
| nigelb | If the bug is reproducible, the next step is to check if the patch applies. | 17:08 |
| nigelb | If the patch is old, the source may have changed so much that the patch does not apply any longer. | 17:09 |
| === daker_ is now known as daker | ||
| nigelb | 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 |
| nigelb | and ask the original author if he can re-write the patch. | 17:09 |
| bobbo | f you can make sense of the code enough to correct, that would be even more great | 17:10 |
| bobbo | fail, If* | 17:10 |
| bobbo | This bug though will be off our list since we can't work with the patch unless its reworked. | 17:11 |
| bobbo | If the patch applies and the bug still exists, we need to check if it fixes the bug. | 17:11 |
| bobbo | Again, no point in a patch if the bug is present after applying the patch and run the program again. | 17:11 |
| bobbo | If the patch works, we have a few options | 17:12 |
| bobbo | 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:12 |
| bobbo | Also, since upstream is the original author of the code, they have a good idea of what makes sense. | 17:13 |
| nigelb | 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:13 |
| nigelb | This helps us keep track of the good that came out of it (and jcastro gets the credit :p) | 17:14 |
| nigelb | Depending on what upstream feels about it, you may need to modify the tag to patch-accepted-upstream or patch-rejected-upstream. | 17:14 |
| nigelb | 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 |
| nigelb | In that case, we forward the bug to Debian and add a 'patch-forwarded-debian' tag. | 17:14 |
| bobbo | Again, depending on feedback from Debian, we mark the patch as and patch-accepted-upstream and patch-rejected-upstream. | 17:15 |
| bobbo | In very rare cases though, the patch is just wrong and we have to reject it. | 17:16 |
| bobbo | In that case, we tag the bug with 'patch-rejected' | 17:16 |
| bobbo | In other cases the bug is so severe that the need to deal with it as quickly as possible | 17:16 |
| bobbo | 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 |
| bobbo | In these cases, the patch is applied in the Ubuntu package, and then forwarded to upstream or debian | 17:17 |
| bobbo | One extra complication is that sometimes patches onfly affect the packaging of an application | 17:18 |
| nigelb | ok, so you've all asked some questions, we'll be answering those now | 17:18 |
| ClassBot | devildante67 asked: Does Operation Cleansweep include bzr branches or only patches? | 17:18 |
| nigelb | It includes only patches. the bzr branches would follow udd and are sponsored in directly. | 17:19 |
| nigelb | udd = ubuntu distributed development | 17:19 |
| ClassBot | 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:19 |
| nigelb | like bobbo said earlier, if you can rework it, by all means, go ahead :) | 17:20 |
| ClassBot | AudioFranky asked: How do I know/find the exact Ubuntu source package version against which the original patch submitted created his patch? | 17:20 |
| nigelb | 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 |
| ClassBot | joaopinto asked: are those tags/workflow written somewhere ? | 17:21 |
| bobbo | You can often check using the date the bug was reported and matching it up with the changelog :) | 17:21 |
| nigelb | thanks bobbo :) | 17:21 |
| nigelb | Yes, Review process is documented | 17:21 |
| bobbo | https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow | 17:22 |
| nigelb | https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide is your friend :) | 17:22 |
| ClassBot | mythos asked: the ability of the reviewer is never checked, so everybody can review patches? | 17:22 |
| nigelb | 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:22 |
| ClassBot | 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 |
| nigelb | It is a case-by-case situation, but this calls for an sru and the sru process | 17:23 |
| nigelb | 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 |
| bobbo | sru = Stable Release Update | 17:24 |
| nigelb | ok, so ClassBot tells me the good news that question queue is empty | 17:25 |
| nigelb | lets move onto some specfic examples | 17:25 |
| nigelb | Bug #544242 | 17:25 |
| ubot2 | 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 |
| nigelb | This bug was opened with a patch provided by the reporter. It was subscribed by the subscription script with the patch tag. | 17:25 |
| nigelb | The patch was forwarded upstream, and recieved the patch-forwarded-upstream tag | 17:26 |
| nigelb | After upstream accepted this patch, it recieved the patch-accepted-upstream tag and is ready to be fixed in Ubuntu. | 17:26 |
| bobbo | Bug #544242 | 17:26 |
| ubot2 | 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:26 |
| bobbo | fail | 17:27 |
| bobbo | Bug #462193 | 17:27 |
| ubot2 | 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 |
| bobbo | This patch only had to go to Debian as the changes only affected the application's packaging | 17:27 |
| bobbo | 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 |
| bobbo | so it was forwarded to Debian and received patch-forwarded-debian | 17:28 |
| bobbo | it was then accepted and receive patch-accepted-debian | 17:28 |
| bobbo | and now we're waiting for the fix to be merged or synced into the Ubuntu archives | 17:29 |
| bobbo | One last example | 17:29 |
| ClassBot | 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 |
| nigelb | bobbo: finish the example and we'll answer this :) | 17:29 |
| bobbo | okay :) | 17:29 |
| bobbo | Bug #33288 | 17:30 |
| ubot2 | 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 |
| nigelb | ah, that was a famous one :) | 17:30 |
| bobbo | The patch was forwarded upstream, where it was rejected | 17:30 |
| bobbo | it's now been fixed, however with a different patch | 17:31 |
| bobbo | </examples> | 17:31 |
| nigelb | heh, thanks bobbo :) | 17:31 |
| nigelb | ok, so about the question | 17:32 |
| nigelb | in our hurry to write this session up, we missed a step, which actually answers the question | 17:32 |
| nigelb | 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 |
| nigelb | 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:33 |
| nigelb | But essentially, our mission would be complete, i.e. patches don't rot in launchpad and die | 17:34 |
| nigelb | Also, contributors who write awesome patches don't get discouraged from writing more code | 17:34 |
| ClassBot | 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 |
| bobbo | I've just checked this up | 17:35 |
| bobbo | either the upstream bug report simply hasn't been updated | 17:35 |
| nigelb | the upstream bug hasn't been updated - there is a comment "pushed to git master" | 17:36 |
| bobbo | 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:36 |
| nigelb | joaopinto: To answer your question, you have to take the initiative. | 17:37 |
| nigelb | If its a main application, talk to desktop team or other subteams if its in their packageset | 17:37 |
| nigelb | they'll glady welcome the help | 17:37 |
| nigelb | If its universe, try mailing the DM who's responsible for the package. | 17:38 |
| bobbo | as long as there is an active package maintainer in Debian, all upstream accepted patches should filter down at some point | 17:38 |
| nigelb | Now, if there is no active maintainer and the patch is good, you have to do some effort on the debian side | 17:38 |
| nigelb | If a package is orphaned in debian, you can do a QA upload. | 17:40 |
| nigelb | You'll need a DD who can sponsor you though. | 17:40 |
| nigelb | A quick mail to debian-mentors mailing list should help you in that case | 17:40 |
| bobbo | If you're not a packager, you can tell a MOTU and they'll hopefully keep track of the package for you | 17:40 |
| nigelb | I'd like to point your attention to a package called galrey | 17:41 |
| nigelb | http://packages.debian.org/sid/galrey | 17:41 |
| bobbo | 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 |
| nigelb | this package had a patch in ubuntu, its an orphaned package in debian | 17:41 |
| nigelb | I spoke to a MOTU friend and she recommended uploading to debian directly, since we don't want to carry a diff. | 17:42 |
| nigelb | 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:42 |
| nigelb | I put in a sync request and we got into lucid in a few days | 17:43 |
| nigelb | joaopinto: I'll answer in here for that one | 17:44 |
| nigelb | 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:44 |
| nigelb | Expectations are high, but that leads to trouble like diverging from upstream and diverging from debian. | 17:45 |
| nigelb | If you've every done a 3-way merge, you'll know that we *really* don't want that | 17:45 |
| nigelb | 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 |
| nigelb | 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:46 |
| nigelb | joaopinto: does that answer your question to some extent? | 17:47 |
| nigelb | Anymore questions folks? | 17:48 |
| nigelb | 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 |
| bobbo | 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:48 |
| nigelb | incomplete = we need more information abaout the bug from the reporter | 17:49 |
| bobbo | Incomplete means that not enough information has been given in the report and we have asked for more | 17:49 |
| bobbo | Fix Committed is a bit of an odd one in Ubuntu | 17:49 |
| bobbo | it can mean many different things and it's often not used correctly | 17:49 |
| nigelb | and desktop team uses it for a specific purpose which confuses us often. | 17:49 |
| nigelb | Generally, fixed commited means the fix in repositry, but not yet rolled into a release. | 17:50 |
| ClassBot | There are are 10 minutes remaining in the current session. | 17:50 |
| bobbo | basically for patch revirew purposes, it's best to ignore Fix Committed and focus on the patch-* tags on the bug instead | 17:50 |
| ClassBot | 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 |
| nigelb | we did that one :) | 17:51 |
| bobbo | fail, I can't work classbot | 17:51 |
| nigelb | heh | 17:51 |
| bobbo | empty queue, does anyone have any questions for the final 9 minutes? | 17:51 |
| bobbo | none? Okay then | 17:52 |
| bobbo | We'd lvoe for you guys to help out reviewing patches and reach the goals of Operation Cleansweep | 17:52 |
| nigelb | Join us in #ubuntu-reviews | 17:53 |
| nigelb | talk about it at your loco events | 17:53 |
| bobbo | if you want more information or would liek some help getting started please feel free to drop into #ubuntu-reviews | 17:53 |
| nigelb | Help us by reviewing 1 patch a day | 17:53 |
| nigelb | Also, we have this beautiful progressbar that daker made for us | 17:53 |
| nigelb | if you can showcase it on your website or blog that would be great | 17:54 |
| ClassBot | devildante67 asked: Is Operation Cleansweep a Maverick only operation, or do you plan on extending it for future releases? | 17:54 |
| bobbo | The original plan was to get all 2000 patches reviewed by this cycle's releaase date | 17:54 |
| nigelb | The focus is on getting unreviewed patches to 0 by maverick release | 17:54 |
| nigelb | we'll have more patches and then our focus would be keeping it low all the time, reviewing them instantly | 17:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 17:55 |
| bobbo | This i project was started to get rid of the huge pile of patches sitting in LP | 17:55 |
| bobbo | so that in future, patches will be reviewed much quicker | 17:56 |
| nigelb | jono just spontaneously came up with the idea | 17:56 |
| nigelb | (and spontaneously assigned it to me :p) | 17:56 |
| dholbach | nigelb: you asked for it :) | 17:56 |
| nigelb | dholbach: heh | 17:57 |
| ClassBot | ean5533 asked: So who's fault is it that it got this bad? nigelb or bobbo? | 17:57 |
| nigelb | Well, the situation got bad because we never had a system to deal with it | 17:57 |
| nigelb | About 6 months back, I was innocently hanging out in #ubuntu-motu and said "I'm bored" | 17:57 |
| bobbo | (big mistake) | 17:57 |
| ClassBot | penguin42 asked: What about patches in debian bug tracking system that fix bugs shared with us? | 17:58 |
| nigelb | yes, in retrospect :p | 17:58 |
| nigelb | Emmet a.k.a. persia said, "go review patches" and I started writing the workflow which we all perfected. | 17:58 |
| bobbo | They are essentially patch-forwarded-debian | 17:58 |
| bobbo | Okay we'd better clear off before the next session | 17:58 |
| bobbo | thanks for listening and please get involved with Operation Cleansweep! | 17:59 |
| nigelb | Yes, Thank you folks. I'm not going anywhere though. I'll talk about the "how to forward patches" with pedro :) | 17:59 |
| pedro_ | We're having a bug day for Operation Cleansweep next week so stay tune ;-) | 17:59 |
| === 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 | ||
| pedro_ | Hello guys! My name is Pedro Villavicencio Garrido and i'm the guy behind the Ubuntu desktop bugs | 18:01 |
| pedro_ | today together with the awesome nigelb we're going to teach you how to forward bugs and patches upstream | 18:01 |
| pedro_ | I'm going to introduce you to the workflow we use for the GNOME bugtracker | 18:01 |
| * nigelb wave again | 18:01 | |
| === ext2 is now known as ext3 | ||
| pedro_ | which also applies to the freedesktop tone | 18:02 |
| pedro_ | s/tone/one | 18:02 |
| pedro_ | since they're using Bugzilla as well | 18:02 |
| pedro_ | if you never heard about bugzilla before -> http://www.bugzilla.org/ | 18:02 |
| pedro_ | the GNOME project uses as said Bugzilla for tracking their bugs reports | 18:03 |
| pedro_ | you can find it at https://bugzilla.gnome.org | 18:03 |
| === pjarnahom is now known as pjarnahomzz | ||
| pedro_ | 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:04 |
| pedro_ | assuming you're not familiar with it, at the top of the page there's a 'New Account' link | 18:05 |
| pedro_ | if you click on that you'll be redirected to a page which is https://bugzilla.gnome.org/createaccount.cgi | 18:05 |
| pedro_ | in most of the bug trackers out here the only requirement to create an account is provide a valid email account | 18:05 |
| pedro_ | and the GNOME Bugzilla is not an exception | 18:06 |
| pedro_ | so just provide your email account and you'll receive a confirmation email | 18:06 |
| pedro_ | just follow the steps described on that and your account will be ready to rock | 18:06 |
| pedro_ | Ok now you created your account so you're ready to start opening bugs upstream | 18:07 |
| pedro_ | but first! | 18:07 |
| pedro_ | it's important to search for already reported bugs | 18:08 |
| pedro_ | we don't want to start flooding upstream with duplicates | 18:08 |
| pedro_ | it creates a lot of more work for the maintainers and the bugsquad | 18:08 |
| pedro_ | alright for searching you need to go to | 18:09 |
| pedro_ | https://bugzilla.gnome.org/query.cgi | 18:09 |
| pedro_ | and put any text you'd like to search for , for example 'love' | 18:09 |
| pedro_ | if you did what i did you'll get a bug report | 18:11 |
| pedro_ | like this one: https://bugzilla.gnome.org/show_bug.cgi?id=438847 | 18:11 |
| ubot2 | Gnome bug 438847 in gnome "i love you" [Normal,Resolved: incomplete] | 18:11 |
| pedro_ | such of nice report isn't ? | 18:11 |
| pedro_ | that's how it looks a report on the GNOME Bugzilla ,will go a bit deeper in to that in a bit | 18:12 |
| pedro_ | now if you didn't find the report you're were looking for | 18:12 |
| pedro_ | what do to? | 18:12 |
| pedro_ | well an extra hint would be to search on the list of most frequently reported bugs | 18:13 |
| pedro_ | which is available here: https://bugzilla.gnome.org/duplicates.cgi | 18:13 |
| pedro_ | is your report there or not? | 18:13 |
| pedro_ | let's say : yes | 18:13 |
| pedro_ | now how can i know if that report is already being tracked on Launchpad? | 18:14 |
| pedro_ | there's a little trick for doing that | 18:14 |
| pedro_ | (don't tell anyone!) | 18:14 |
| pedro_ | for example if we want to know if bug https://bugzilla.gnome.org/show_bug.cgi?id=479979 | 18:14 |
| ubot2 | Gnome bug 479979 in window selector "Crash in wnck_task_button_glow()/cairo_translate()" [Critical,Resolved: incomplete] | 18:15 |
| pedro_ | is being tracked we need to pass something like this to launchpad | 18:15 |
| pedro_ | https://bugs.launchpad.net/bugs/bugtrackers/gnome-bugs/479979 | 18:15 |
| pedro_ | click on that url | 18:15 |
| pedro_ | it will take you to a report in launchpad which is watching that upstream report | 18:15 |
| ClassBot | charlie-tca asked: that is a great report! | 18:16 |
| pedro_ | indeed charlie-tca ;-) | 18:16 |
| pedro_ | btw you can do that for all the bug trackers which are listed here: https://bugs.launchpad.net/bugs/bugtrackers | 18:16 |
| pedro_ | it helps a lot when you're searching for upstream reports | 18:17 |
| pedro_ | 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:17 |
| pedro_ | 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 |
| pedro_ | bugzilla is going to show a long list , like the one here: | 18:18 |
| pedro_ | https://bugzilla.gnome.org/enter_bug.cgi?classification=__all | 18:18 |
| === ZachK_ is now known as zkriesse | ||
| ClassBot | devildante67 asked: Can't we do that nice secret trick directly in the site? | 18:19 |
| pedro_ | not really in launchpad, there's no search box for those, but yeah would a neat wishlist | 18:19 |
| pedro_ | what i did for my workflow was to create a keyword on firefox so everytime i enter something like: gnome #123456 | 18:20 |
| ubot2 | Gnome bug 123456 in general "ItemFactory.create_items and <ImageItem> bug" [Normal,Resolved: fixed] http://bugzilla.gnome.org/show_bug.cgi?id=123456 | 18:20 |
| === Jack is now known as Guest49040 | ||
| pedro_ | it will search automatically for that bugs for me instead of entering the whole url over and over again | 18:20 |
| pedro_ | ok if you click on the nautilus product you'll see something like this: | 18:21 |
| pedro_ | http://people.canonical.com/~pedro/new_bug1.jpg | 18:21 |
| pedro_ | where you have something similar to what we have in launchpad | 18:21 |
| pedro_ | a field to enter a Summary | 18:21 |
| pedro_ | Description , add an Attachment etc | 18:21 |
| pedro_ | now if you click on the "Show Advanced Fields" you'll see something like this: | 18:22 |
| pedro_ | http://people.canonical.com/~pedro/new_bug2.jpg | 18:22 |
| pedro_ | You can use either of those to open a new bug | 18:23 |
| pedro_ | most of the information which is requested there is already available in our bugs at Ubuntu | 18:23 |
| pedro_ | like the version of GNOME used, the version of the program, the summary etc | 18:23 |
| pedro_ | Now paste the title of the bug in launchpad and improve it if that title isn't good enough | 18:24 |
| pedro_ | it's always better to use something like "nautilus search freeze when searching for odp files" then "nautilus freezes" | 18:24 |
| pedro_ | 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:24 |
| pedro_ | And if applicable add a keyword | 18:25 |
| pedro_ | a keyword is similar to what we call 'tags' on launchpad | 18:26 |
| pedro_ | you can see those used on GNOME at https://bugzilla.gnome.org/describekeywords.cgi | 18:26 |
| pedro_ | for example: use STACKTRACE for crashes with full debug backtrace | 18:26 |
| pedro_ | usability for well usability issues | 18:26 |
| pedro_ | documentation for bugs in the docs, etc etc | 18:27 |
| pedro_ | ok how a report forwarded from Ubuntu looks like | 18:27 |
| pedro_ | please have a look to https://bugzilla.gnome.org/show_bug.cgi?id=589386 | 18:28 |
| ubot2 | Gnome bug 589386 in general "Reverting changes when submenus are created make the submenus appear as alacarte-made-#" [Normal,New] | 18:28 |
| pedro_ | as you can see there, the format we use is to add a Link to the launchpad report | 18:28 |
| pedro_ | a description of the issue and if we have more information we add it as well like the logs on that particular report | 18:28 |
| ClassBot | 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 |
| pedro_ | yes that works for freedesktop too, let me give you the link | 18:29 |
| pedro_ | https://bugs.edge.launchpad.net/bugs/bugtrackers/freedesktop-bugs/21614 | 18:30 |
| pedro_ | those are the bugs that are watching that upstream report | 18:30 |
| pedro_ | maybe they could be marked as duplicate if they aren't yet ;-) | 18:30 |
| pedro_ | Ok If you saw that alacarte report | 18:31 |
| pedro_ | you'll see that the status are different than in launchpad | 18:31 |
| pedro_ | for example that bug was confirmed but the status is New | 18:31 |
| pedro_ | the New status in the GNOME bugzilla is similar to our Triaged status | 18:32 |
| pedro_ | and our New status there is UNCONFIRMED | 18:32 |
| pedro_ | there's a few status on bugzilla that you might not familiar with , you can read about those at | 18:33 |
| pedro_ | https://bugzilla.gnome.org/page.cgi?id=fields.html | 18:33 |
| pedro_ | so don't change the status to New if you just filed the report and nobody else confirmed it :-P | 18:33 |
| ClassBot | 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:33 |
| pedro_ | simar_mohaar, I can teach you how to do it after the talk ;-) | 18:34 |
| pedro_ | Alright let's assume you have your bug filed upstream | 18:35 |
| pedro_ | a shine and new upstream report | 18:35 |
| pedro_ | what to do now? | 18:35 |
| pedro_ | well what you need to do is to create a Bug Watch in Launchpad for that upstream report you just filed | 18:36 |
| pedro_ | how to do it? easy, you need to click on the Also affects project link which is available in every report at launchpad | 18:36 |
| pedro_ | you'll get something like this: http://people.canonical.com/~pedro/also-affects.jpg | 18:37 |
| pedro_ | where you can paste the link that bugzilla gives you | 18:37 |
| pedro_ | then just click on Add to Bug Report | 18:38 |
| === abhi_nav__ is now known as abhi_nav | ||
| pedro_ | and your report will look like this one https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/510322 | 18:38 |
| ubot2 | 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 |
| pedro_ | a new field is going to appear | 18:38 |
| pedro_ | with the name of the project, status, importance and a link to that upstream report on the assigned to field | 18:39 |
| pedro_ | ok we're almost done! | 18:39 |
| pedro_ | what you need to do now, is to comment on the bug report in launchpad with something as: | 18:39 |
| pedro_ | 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 |
| pedro_ | where URL is of course the link bugzilla returns you previously | 18:40 |
| pedro_ | 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 |
| pedro_ | this same second part of the workflow applies to mostly all of the projects in Ubuntu with upstream projects | 18:41 |
| pedro_ | what only changes is the how the upstream projects manage their bugs, with more keywords, some different status or severities etc | 18:42 |
| pedro_ | 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 |
| pedro_ | nigelb, stage is all yours! | 18:43 |
| nigelb | thanks pedro_ | 18:43 |
| nigelb | He conviniently has a call right now, so he's passed the batton to me | 18:43 |
| nigelb | 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 |
| nigelb | I intended to give pedro the task of explaining the "how to forward" patches, but I see its come to me. | 18:44 |
| nigelb | ;) | 18:44 |
| nigelb | so, you've seen the gnome bugzilla and seen how it works and how to report a bug | 18:45 |
| nigelb | if you scroll down a bugzilla bug, you'll see a table that lists the patches available (empty if no patches yet) | 18:45 |
| nigelb | It looks like this http://imagebin.ca/view/GBIh_i5.html | 18:46 |
| nigelb | if you click on the button, you'll go to another page | 18:47 |
| nigelb | it looks like this http://imagebin.ca/view/GtvMF1.html | 18:47 |
| nigelb | initially, it asks that you select a file to upload and give a description for it | 18:48 |
| === mab is now known as Guest87736 | ||
| nigelb | its a good idea to give the description as whatever it fixes, like "Fixes the crash that happens when you do $foo" | 18:48 |
| nigelb | you can either force bugzilla to consider it as a patch or let it automatically decide whether it was a patch | 18:49 |
| nigelb | then, enter a comment and press submit | 18:49 |
| nigelb | viola! your patch is submitted upstream | 18:49 |
| nigelb | you'll notice there is a field called "obsolete" | 18:50 |
| ClassBot | There are are 10 minutes remaining in the current session. | 18:50 |
| nigelb | thats for when you've rewritten a patch (which was initially written by you) and you upload the new patch | 18:50 |
| nigelb | you can mark the old one as obsolte | 18:50 |
| nigelb | but they're smart people, they don't let you mark your patch obsolteling someone else's ;) | 18:51 |
| ClassBot | 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:51 |
| nigelb | Well, personally a lot of us start the bug with "This bug was orginally reported in Launchpad, bug# 123" | 18:52 |
| nigelb | that way other triagers know which one its linked to | 18:52 |
| ClassBot | mgamal asked: How should we forward patches to upstream projects that follow a different patch submission procedure (e.g. Linux Kernel)? | 18:52 |
| nigelb | very good question | 18:52 |
| nigelb | Each project has different specifications and rules, its very importannt that you read their guidelines if any | 18:53 |
| nigelb | 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 |
| nigelb | the freedesktop project also uses bugzilla and their patch submission interface looks very similar to gnome bugzilla | 18:54 |
| nigelb | (well, its after all bugzilla with different themes) | 18:54 |
| nigelb | here's how that looks http://imagebin.ca/view/BsKUieS.html | 18:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 18:55 |
| nigelb | http://imagebin.ca/view/X0Fpl-pn.html | 18:55 |
| ClassBot | 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 |
| nigelb | a patch is essentially a diff file. Its a diff of current source vs new source | 18:56 |
| nigelb | And a patch is not what updates your system during update | 18:56 |
| nigelb | I have one more bug tracker to talk about | 18:56 |
| nigelb | this tracker deserves a session of its own | 18:57 |
| nigelb | 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 |
| nigelb | but it doesn't let you file a bug from a webform | 18:57 |
| nigelb | you have to either send a mail in a particular format or use a commandline tool | 18:57 |
| nigelb | any guesses? | 18:57 |
| nigelb | c'mon, no guesses? | 18:58 |
| nigelb | yep, jacob | 18:58 |
| nigelb | Its the Debian BTS | 18:58 |
| nigelb | Its the tracker we all love to hate. | 18:58 |
| nigelb | 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 |
| nigelb | http://www.debian.org/Bugs/Reporting | 18:59 |
| nigelb | you can use that debian page to know more about reporting bugs on debian or use reportbug | 19:00 |
| nigelb | reportbug is a commandline tool that helps you do it provided you can send email from your system | 19:00 |
| nigelb | And with that, my time is done :) | 19:00 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Daily Builds And You - Instructor: jcastro | ||
| nigelb | Thanks folks for listening in! | 19:00 |
| jcastro | alright! | 19:01 |
| dholbach | hello everybody :) | 19:01 |
| jcastro | welcome to our class | 19:01 |
| jcastro | this session will be about daily builds, I'm Jorge Castro ... | 19:01 |
| dholbach | and I'm Daniel Holbach | 19:01 |
| jcastro | and we're working with the launchpad team to make daily builds a reality | 19:01 |
| jcastro | before I start | 19:02 |
| jcastro | let me give you some information that you need to follow along in this class | 19:02 |
| jcastro | https://help.launchpad.net/Packaging/SourceBuilds | 19:02 |
| jcastro | and all the pages in that section of the wiki will help you out | 19:02 |
| jcastro | so first off, what the heck is a daily build? | 19:02 |
| dholbach | Yes, https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted is the page you should probably bookmark :) | 19:02 |
| jcastro | simply put | 19:02 |
| jcastro | a daily build is a PPA that contains software from a project that is updated every day | 19:03 |
| jcastro | 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 |
| jcastro | so why would we do this? | 19:03 |
| jcastro | First of all, the main reason is testing | 19:03 |
| jcastro | if you're writing a program, you want to be able to test it | 19:03 |
| jcastro | however because ubuntu releases are stable (meaning we don't update to new versions generally) | 19:04 |
| jcastro | then this can be hard to get people to test. | 19:04 |
| jcastro | 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 |
| jcastro | and we plan to do this by offering the latest builds of things | 19:04 |
| jcastro | it can be annoying when a developer tells you "try it with this patch, let me know if it works!" | 19:05 |
| jcastro | with daily builds we can now easily test that software | 19:05 |
| jcastro | and enable the upstream developer to get those fixes out to their users | 19:05 |
| jcastro | which is what it's all about | 19:05 |
| jcastro | however, there can be badness too, it's not all cupcakes and unicorns | 19:05 |
| jcastro | if you commit broken code, it shows up in the daily build | 19:06 |
| jcastro | since dailies are automated, if you break your code, this can break the software | 19:06 |
| jcastro | some well run projects use things like distributed version control and unit testing to make sure that trunk always builds | 19:06 |
| jcastro | this is a Good Thing(tm) | 19:06 |
| jcastro | also, if your project is starting out and you're not ready for feedback then dailies can be a waste for you while you make major changes | 19:07 |
| jcastro | or if you rewrite entire chunks and don't have a good way for users to move back and forth between versions | 19:07 |
| jcastro | and lastly, the world is full of people who love crack, and might use daily builds for day-to-day usage instead of testing | 19:07 |
| jcastro | so you might get some bad feedback from people complaining that the software is broken half the time | 19:08 |
| jcastro | but whatever. :D | 19:08 |
| jcastro | ok so now that's daily builds | 19:08 |
| jcastro | now Daniel is going to show you how they work. | 19:08 |
| dholbach | and with a PPA it's incredibly easy to get users to test software, if they're interested in that particular package, it's just a "sudo add-apt-repository …" away (or well they use the GUI option :-)), so for an upstream or somebody who "adopted an upstream" it couldn't be easier to get willing testers :) | 19:08 |
| dholbach | I wanted to add a note on "warning users", etc. because I think it's very important that you as an upstream or you as somebody who wants to test a particular piece of software tell people very carefully what's going to happen :) | 19:09 |
| dholbach | in https://help.launchpad.net/Packaging/SourceBuilds/KnowledgeBase we have a bunch of good information on how to tell people what's happening, which cases it makes sense to have daily builds etc | 19:10 |
| dholbach | https://help.launchpad.net/Packaging/SourceBuilds/GoingBack for example explains in a visual way how to "go back to an old version" | 19:10 |
| dholbach | are there any questions up until now? | 19:10 |
| dholbach | alright, seems what Jorge and I said made at least a bit of sense :-) | 19:11 |
| dholbach | first of all: this feature is BETA and we have already found a few bugs that still need to be ironed out | 19:11 |
| dholbach | https://help.launchpad.net/Packaging/SourceBuilds/KnownLimitations is what's on our list right now | 19:11 |
| dholbach | ok, so how does this work | 19:11 |
| dholbach | first of all: all the code needs to be in launchpad | 19:12 |
| dholbach | so if you're interested in some project that is hosted somewhere in a cvs repository somewhere, you need to import it into launchpad | 19:12 |
| dholbach | luckily, that's very easy | 19:12 |
| dholbach | we have links in the knowledge base about how to do exactly that | 19:12 |
| jcastro | (... we also support svn and git imports) | 19:12 |
| dholbach | yes, that's all explained in there :) | 19:13 |
| dholbach | ah, we have the first few questions | 19:13 |
| dholbach | <joaopinto> QUESTION: Are daily builds targeted for every supported release ? | 19:13 |
| dholbach | joaopinto: you can target them to releases as you like it | 19:13 |
| dholbach | <simar_mohaar> QUESTION: Whats a PPA? | 19:13 |
| dholbach | simar_mohaar: it's a Personal Package Archive | 19:13 |
| dholbach | in addition to the ubuntu archive people or teams can set up their own archives in Launchpad | 19:14 |
| dholbach | https://help.launchpad.net/PPA has more detail about this | 19:14 |
| dholbach | it's the best thing since sliced bread | 19:14 |
| dholbach | ok, now that we have the code in Launchpad, what's next | 19:14 |
| dholbach | there's the "recipe" | 19:14 |
| dholbach | this gets a little bit more complicated, so hold tight and relax - we'll get to the actual builds in a bit :) | 19:15 |
| dholbach | a recipe is instructions how launchpad is going to assemble the source package on its own | 19:15 |
| dholbach | (from which source branch, how does the version numbering work, etc.) | 19:15 |
| dholbach | it's crucial that you write up that recipe (we have a few nice examples) and TEST it locally | 19:16 |
| dholbach | and when I mean test | 19:16 |
| dholbach | I mean | 19:16 |
| dholbach | _____ _____ ____ _____ _ | 19:16 |
| dholbach | |_ _| ____/ ___|_ _| | | 19:16 |
| dholbach | | | | _| \___ \ | | | | | 19:16 |
| dholbach | | | | |___ ___) || | |_| | 19:16 |
| dholbach | |_| |_____|____/ |_| (_) | 19:16 |
| dholbach | 19:16 | |
| dholbach | luckily we have tools for that and we'll cover that in a bit | 19:16 |
| jcastro | ok so let's start with a simple recipe | 19:17 |
| jcastro | # bzr-builder format 0.2 deb-version {debupstream}+{revno} | 19:17 |
| jcastro | lp:gtg | 19:17 |
| jcastro | nest packaging lp:~gtg/gtg/debian debian | 19:17 |
| jcastro | 3 lines! | 19:17 |
| jcastro | let's go over each | 19:17 |
| jcastro | the first one defines the recipe | 19:17 |
| jcastro | the 0.2 is the version you want the package to be | 19:17 |
| jcastro | I usually derive this from the upstream version | 19:17 |
| jcastro | (remember that you need the version numbers to be close to what upstream is | 19:18 |
| jcastro | actually, wait | 19:18 |
| jcastro | I totally messed that up | 19:18 |
| jcastro | let's start with line 1 again | 19:18 |
| jcastro | "bzt-builder format" is needed to start the recipe | 19:18 |
| jcastro | 0.2 is the version of the recipe formate | 19:19 |
| jcastro | so for those you can just leave those the same | 19:19 |
| dholbach | deb-version describes what the resulting package in the PPA will have as version number | 19:19 |
| dholbach | you need to be a bit careful there | 19:20 |
| dholbach | {debupstream} will be replaced with the version number in the packaging (debian/changelog - more on that in a sec) | 19:20 |
| dholbach | {revno} is the revision number of the upstream branch | 19:20 |
| jcastro | the second line is easy | 19:21 |
| jcastro | it's where in launchpad the upstream source is | 19:21 |
| jcastro | so in this example, since gtg is hosted in launchpad, we can use lp:gtg | 19:21 |
| jcastro | for imports it might be more comples | 19:21 |
| jcastro | complex I mean | 19:21 |
| jcastro | then the last line is where the packaging is | 19:21 |
| jcastro | so we're basically telling launchpad "grab the code from lp:gtg, and nest the packaging from lp:~gtg/gtg/debian which is a debian directory, and spit it out." | 19:22 |
| dholbach | so in this case we have the following case | 19:22 |
| dholbach | lp:gtg contains no packaging at all | 19:22 |
| dholbach | it's just the upstream source | 19:23 |
| dholbach | usually if you get the source of a source package, you can see a debian/ directory in there which contains all the packaging information | 19:23 |
| dholbach | so on its own lp:gtg would not build | 19:23 |
| dholbach | so what we do here is: check out a branch that contains the current packaging and stick it in to a debian/ directory in what we checked out as trunk | 19:24 |
| dholbach | the second branch does ONLY contain packaging, nothing else | 19:24 |
| dholbach | so "nest" is the keyword that means "ok, check out this second branch and just put it where I tell you" | 19:25 |
| dholbach | ok, that was case one and what we think is a very common one | 19:25 |
| dholbach | for case two, I'd like to highlight fabrice_sp's question :) | 19:25 |
| dholbach | <fabrice_sp> QUESTION: what if upstream ships a debian directory? | 19:25 |
| dholbach | that case is simple: you just drop the third line, you have a two line recipe then :-D | 19:26 |
| dholbach | and now we have case three which is a bit more complicated - I hope you're a little bit familiar with distributed revision control, so I don't look stupid | 19:27 |
| dholbach | let's recap: case 1) pristine trunk, does not have packaging, so "nest" packaging branch into debian/ dir | 19:27 |
| dholbach | case 2) upstream has packaging already, so you get a simple recipe | 19:27 |
| dholbach | case 3) | 19:27 |
| dholbach | you have two branches you're going to merge | 19:27 |
| dholbach | so for example you have the upstream trunk that does not have any packaging included | 19:28 |
| dholbach | and the other branch was branched off of upstream and you added packaging in there, maybe you just wanted to ship a particular release | 19:29 |
| dholbach | as you can see the third one is a bit more complicated, but as I said we have tools to test and see if it works :-) | 19:29 |
| jcastro | hey wait a minute! | 19:29 |
| jcastro | so let's say I have my upstream | 19:29 |
| jcastro | and the packaging | 19:29 |
| jcastro | but someone out there made bug fixes in a branch | 19:29 |
| jcastro | I want to be able to try those fixes in a build | 19:30 |
| jcastro | so can I merge in branches with fixes from launchpad? | 19:30 |
| jcastro | like say .... | 19:30 |
| jcastro | merge fix-build lp:~bzr/bzr/fix-build | 19:30 |
| dholbach | exactement - that's exactly what you can do now :) | 19:30 |
| jcastro | so we can combine stuff! | 19:30 |
| dholbach | yeah :-) | 19:31 |
| jcastro | so let's check out a more convoluted example | 19:31 |
| jcastro | # bzr-builder format 0.2 deb-version 1.0+{time} | 19:31 |
| jcastro | lp:bzr | 19:31 |
| jcastro | merge fix-build lp:~bzr/bzr/fix-build | 19:31 |
| jcastro | nest pyfoo lp:pyfoo foo | 19:31 |
| jcastro | merge branding lp:~bob/pyfoo/ubuntu-branding | 19:31 |
| jcastro | merge packaging lp:~bzr/bzr/packaging | 19:31 |
| dholbach | wow :) | 19:31 |
| jcastro | I can even specify revisions! | 19:31 |
| jcastro | merge packaging lp:~bzr/bzr/packaging revno:2355 | 19:31 |
| jcastro | whoa, now I see why this is so powerful! :) | 19:31 |
| dholbach | yeah, that takes a bit to understand, but if you do it step by step, it'll all be nice and easy | 19:32 |
| dholbach | as an added bonus you get an email if the fixed branch does not apply any more in trunk :) | 19:32 |
| dholbach | <joaopinto> QUESTION: Is there some middle ground official project, technically similar to daily builds but providing stable releases instead ? | 19:32 |
| dholbach | joaopinto: good question: sometimes upstream will have a stable branch, so you could have multiple PPAs: one for beta, one for stable, one for crack of the day, etc. | 19:33 |
| dholbach | in the other cases, you could supply revision numbers, etc. | 19:33 |
| dholbach | this technology is still quite new, but we'll figure out over time how to make the best use of it | 19:33 |
| jcastro | so if we have the packaging, the upstream, and PPAs ... then really it's up to me if I want to publish it daily | 19:33 |
| dholbach | right now we still have to do it carefully | 19:33 |
| jcastro | or just follow stable branches | 19:33 |
| dholbach | jcastro: exactly :) | 19:33 |
| jcastro | ok so before we go off and flood lp | 19:34 |
| jcastro | can you tell me why it's so important to test locally? | 19:34 |
| jcastro | and then show me how? | 19:34 |
| dholbach | sure, will do :) | 19:34 |
| dholbach | there's still a couple of bugs the Soyuz team (which does the building and PPA part of things), the bazaar team (who deals with all the branch goodness) and the launchpad-code team (the folks who work on merge proposals, code import, etc.) and lots of others are working on | 19:35 |
| dholbach | plus, there's currently a bunch of builds in PPAs piled up | 19:35 |
| jcastro | (I hear they're sprinting right now to fix these bugs!) | 19:36 |
| dholbach | so if you know the build is not really important or you don't know it works, it's unfair to others if this hammers launchpad | 19:36 |
| jcastro | you mean I can't just set up 50 of them and then just fire and forget? | 19:36 |
| dholbach | I don't know if there's any limit hardcoded in LP, but we should all bear in mind that it's BETA, that it's a service that other folks use and that we should all take it nice and easy :) | 19:37 |
| dholbach | matttbe37 asked a question about this too | 19:37 |
| dholbach | <matttbe37> QUESTION: Hello! Do you know when the version of 'bzr-builder' will be updated in launchpad? => because it seems there is a bug with the current version (Bug #604837) and also because I need the new {date} variable :) ? | 19:37 |
| dholbach | matttbe37: honestly I don't know right now, but I'll make sure to get some feedback on it and make sure that it's addressed somehow | 19:38 |
| dholbach | alright | 19:38 |
| dholbach | let's get to testing it | 19:38 |
| dholbach | this is not a demo or packaging session, so we'll just give you the quick instructions here and you can go and try this out later on | 19:38 |
| dholbach | basically you write your recipe based on the instructions | 19:39 |
| dholbach | then you save it locally | 19:39 |
| dholbach | then install bzr-builder | 19:39 |
| jcastro | https://launchpad.net/builders has build stats (and yes there are more resources coming) | 19:39 |
| dholbach | and then you just run "bzr dailydeb package.recipe working-dir" | 19:39 |
| dholbach | which will try out just what launchpad is going to do for you | 19:39 |
| dholbach | (it'll get the branches you specified and assemble the source package for you) | 19:40 |
| jcastro | (this way you can also build the packages locally and make sure they work before asking launchpad to do it for you) | 19:40 |
| dholbach | there's one particular big guy in the launchpad team (bigjools) who'll be unhappy if you don't try this out first | 19:40 |
| dholbach | so don't say I didn't warn you :) | 19:40 |
| dholbach | then you can use pbuilder to test build the package locally | 19:40 |
| dholbach | and that's a good exercise as well :) | 19:41 |
| dholbach | and it's easy to do | 19:41 |
| dholbach | sudo apt-get install pbuilder | 19:41 |
| dholbach | add COMPONENTS="main universe multiverse restricted" to ~/.pbuilderrc | 19:41 |
| dholbach | sudo pbuilder create; sudo pbuilder build <working-dir>/<project>_<version>.dsc | 19:41 |
| dholbach | done | 19:41 |
| dholbach | If the build succeeds, you can test-install the resulting package from /var/cache/pbuilder/result/. | 19:42 |
| dholbach | but that means that you need to have the packaging sorted out before, the tools won't "make that happen for you" | 19:42 |
| dholbach | on the plus side we have good info on how to get that done :) | 19:42 |
| dholbach | in the knowledge base | 19:42 |
| dholbach | <joaopinto> QUESTION: Do daily builds, PPAs, and official archives share the same infrastructure resources ? | 19:42 |
| dholbach | joaopinto: yes, it's all the same infrastructure, but build machines are assigned specific tasks | 19:42 |
| dholbach | and some builds have a higher priority than others | 19:43 |
| jcastro | ok so one last example | 19:43 |
| jcastro | (this is the OOOOH moment. | 19:43 |
| jcastro | so, in case you didn't know, some teams in ubuntu are already putting their packaging in bzr | 19:44 |
| jcastro | and eventually the entire distro will be in there | 19:44 |
| jcastro | so if we know where upstream is | 19:44 |
| jcastro | and where the packaging is ... | 19:44 |
| jcastro | we /should/ be able to make dailies out of almost anything! | 19:44 |
| jcastro | so ... I tried this: | 19:44 |
| jcastro | https://code.edge.launchpad.net/~jorge/+recipe/shotwell-daily | 19:44 |
| jcastro | (note the +recipe in the url, this is how we'll keep track of the recipes) | 19:45 |
| jcastro | shotwell is a photo editor | 19:45 |
| jcastro | I knew where upstream SVN is | 19:45 |
| jcastro | so I imported it into launchpad | 19:45 |
| jcastro | and I knew the ubuntu desktop team kept the packaging in bzr. So I tried to mush it together. | 19:45 |
| jcastro | and this is also where you see the "not finished" bits yet | 19:46 |
| jcastro | right now we don't have an easy way to do this, but it's a goal | 19:46 |
| jcastro | but from looking at that page you can get an idea of where we're going with this | 19:46 |
| jcastro | and yes, we're going to need more hardware. :) | 19:46 |
| dholbach | are there any more questions up until now? | 19:46 |
| jcastro | also, some tips here | 19:47 |
| jcastro | first off, we can't work in a vaccum, so while it may be fun to set up 50 dialy builds for your favorite project | 19:47 |
| jcastro | remember that they're not as useful if the upstream projects themselves don't know about it | 19:47 |
| jcastro | or know how to deal with it | 19:47 |
| jcastro | imagine if you were a developer and someone on the internet made daily builds available, and your bug tracker started getting alot of traffic | 19:48 |
| jcastro | and you weren't ready for it! | 19:48 |
| jcastro | so I encourage you not to just set these up, but work with app developers | 19:48 |
| jcastro | so that they can use these tools to make better releases and better software | 19:49 |
| dholbach | yeah, good thinking, plan with upstream | 19:49 |
| jcastro | more questions? | 19:49 |
| dholbach | talk to them, and go adopt-an-upstream | 19:49 |
| jcastro | yes, I personally plan on perfecting a few recipes locally | 19:49 |
| jcastro | and then mailing someone upstream | 19:49 |
| dholbach | (more info on that on Friday 16th, 18 UTC, same place :-D) | 19:49 |
| jcastro | and then have them set up their own based on my initial work, so that they can use them as they see fit | 19:49 |
| ClassBot | There are are 10 minutes remaining in the current session. | 19:50 |
| dholbach | more questions? or anything else you're wondering about? | 19:50 |
| jcastro | and of course, if you know projects interested in dailies, please let me know! | 19:50 |
| jcastro | I'm looking forward to seeing all the recipes people come up with | 19:51 |
| dholbach | yeah, me too | 19:52 |
| jcastro | we're working on listing some dailies here: https://wiki.ubuntu.com/DailyBuilds/AvailableDailyBuilds | 19:52 |
| jcastro | Since right now launchpad doesn't have a way of just showing them all at once | 19:52 |
| dholbach | maybe you have some suggestions or crazy ideas what you want to do with daily builds? | 19:52 |
| dholbach | and please: if you find bugs, file them, talk to the people in #launchpad about them, so we can iron all of them out | 19:53 |
| jcastro | oh, I forgot to mention | 19:53 |
| jcastro | this isn't just for desktop stuff | 19:53 |
| jcastro | chuck short has been offering dailies of mysql, puppet, and a ton of other server stuff | 19:53 |
| dholbach | <penguin42> QUESTION: Ah, there's a good question - if you find a bug in a daily, do you file it in the normal way? | 19:53 |
| jcastro | this is great for testing the entire platform you deploy on! | 19:53 |
| dholbach | penguin42: I think you can start with the launchpad-code project, but if bzr gives you an error message, or bzr-builder acts up, file the bug there | 19:54 |
| dholbach | if you're unsure, talk to the folks in #launchpad | 19:54 |
| dholbach | sorry, one thing we missed: you need to be part of the ubuntu beta testers team | 19:55 |
| dholbach | it's currently only available on edge | 19:55 |
| jcastro | https://edge.launchpad.net/~launchpad-beta-testers | 19:55 |
| jcastro | join that team if you want to test this feature! | 19:55 |
| dholbach | <penguin42> dholbach: I meant a bug in a particular daily built package, not in the daily-build mechanism | 19:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 19:55 |
| dholbach | sorry I misunderstood penguin42's question | 19:55 |
| dholbach | in that case it makes sense to file the bug upstream and let them know about it | 19:55 |
| jcastro | this is why it's important to talk to them | 19:56 |
| dholbach | apport for example will tell you that it's not an ubuntu package, but something else | 19:56 |
| jcastro | they might say "yeah, I know that's broken, don't file bugs" | 19:56 |
| jcastro | or they might appreciate a bunch of testing | 19:56 |
| dholbach | if you give out daily build packages to users, let them know what to do with bugs they found, give them detailed instructions | 19:56 |
| dholbach | if you haven't, bookmark https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted :-) | 19:56 |
| dholbach | jcastro: I'm done - what about you? | 19:57 |
| jcastro | awesome, thanks for the tour daniel | 19:57 |
| jcastro | I am looking forward to seeing how app developers use this! | 19:57 |
| dholbach | thanks jcastro - these daily builds ROCK and will make life a lot more fun :) | 19:57 |
| jcastro | I think it'll go a long ways to getting fixes out to people much quicker! | 19:57 |
| jcastro | thanks everyone for participating! | 19:57 |
| jcastro | who is next? | 19:57 |
| dholbach | you have 3 minutes break until tedg talks to you about indicators :) | 19:57 |
| dholbach | thanks a lot everybody | 19:57 |
| jcastro | app indicators are great | 19:58 |
| * dholbach hugs you all | 19:58 | |
| jcastro | did you know that the KDE folks kicked it off with KStatusNotifierItem? | 19:58 |
| jcastro | (it's the reason app indicators are so wonderfully crossdesktop) | 19:58 |
| tedg | jcastro, Hey, you stealing my material? ;) | 19:59 |
| === 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: Making Your Application Shine With Application Indicators - Instructor: tedg | ||
| tedg | I'm not sure if I'm comfortable being an "Instructor" (sounds so official), but hello everyone! | 20:01 |
| tedg | So this session is about Application Indicators. | 20:01 |
| tedg | For those who aren't familiar with them they're basically the small custom menus that are put in the panel by applications. | 20:02 |
| tedg | These provide extra functionality that is persistent. Things like your music player, where you'll keep it running, but not want the full window all the time. | 20:02 |
| tedg | While we'd all love to have 40" screens, that's rarely practical, so we allow an easy way to do minimized status. | 20:03 |
| tedg | That doesn't mean that every application under the sun should have an application indicator. | 20:03 |
| tedg | For most it really doesn't make any sense what so ever. | 20:03 |
| tedg | It's rare that you'd want continuous status on your word processor for instance. | 20:04 |
| tedg | mpt has written up some practical guidelines on what should and shouldn't be an application indicator. | 20:04 |
| tedg | https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines | 20:05 |
| tedg | That page goes into a lot more, but it starts off talking about how to think about the application indicators. | 20:05 |
| tedg | Our long term goal with Application Indicators is to replace the Notification Area. | 20:05 |
| tedg | Which, has become a usability ghetto. Everything behaves differently, which makes them difficult to use overall. Sure you can learn them, but really you shouldn't have to. | 20:06 |
| tedg | For a discussion on the notification area and application indicators there a good post on the Canonical Design Blog. | 20:06 |
| tedg | http://design.canonical.com/2010/04/notification-area/ | 20:06 |
| tedg | So to get to more predictability on how the icons behave, we took an opinionated tact to say that all of them are menus. | 20:07 |
| tedg | This provides some limitations, but it also can be a very flexible interfaces for providing rich functionality to users. | 20:07 |
| tedg | I just realized I wasn't in the chat room. | 20:09 |
| tedg | Sorry about that. | 20:09 |
| tedg | If people have posted questions please repost them. | 20:09 |
| tedg | Okay, back on track :) | 20:09 |
| tedg | So, how does all of this work? | 20:10 |
| tedg | The basis is the KDE Status Notifier Item specification. | 20:10 |
| tedg | http://www.notmart.org/misc/statusnotifieritem/index.html | 20:10 |
| tedg | KSNI provides an interface for status notifier items that is independent of how they can be displayed. | 20:11 |
| tedg | While we have a particular ideas on how that display should work, KNSI doesn't provide anything on that. | 20:11 |
| tedg | So it is possible to link KSNI supporting applications in a variety of displays, but we're not currently using any of those. | 20:12 |
| tedg | There are some available on KDE for Plasma. | 20:12 |
| tedg | On top of that we added the ability to export a menu across dbus. | 20:12 |
| tedg | That is implemented using the Dbusmenu protocol and librarly. | 20:12 |
| tedg | If you're interested in dbusmenu you can start on Launchpad at http://launchpad.net/dbusmenu | 20:12 |
| tedg | For the most part, application developers don't need to know anything about either of these protocols because they're hidden behind libappindicator which provides a pretty simple interface to both. | 20:13 |
| tedg | That interface is the AppIndicator object who's C Language documentation is available here: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html | 20:14 |
| tedg | Muscovy, Working windicators are on the todo list, but with the shorted development time in the Maverick cycle they probably won't make the Feature Freeze cutoff. | 20:15 |
| tedg | So if you're wanting to implement Application indicators there are a few guides available. | 20:16 |
| tedg | There is the reference documentation above, but you probably want one of the guides. | 20:16 |
| tedg | https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Porting%20Guide%20for%20Applications | 20:16 |
| tedg | The Wiki goes through examples in a variety of languages. | 20:16 |
| tedg | There are Mono, Python and Vala bindings in Maverick. Including GObject Introspection support. | 20:17 |
| tedg | So I haven't heard of anyone doing it, but Javascript should work too :) | 20:17 |
| tedg | matttbe, I believe that we are using the same address as KSNI names, so KDE applications do work with the application indicators. | 20:18 |
| tedg | matttbe, We do register with dbus for two names, one for dbus activations purposes and the other to connect with the KSNI protocol. | 20:18 |
| tedg | On the topic of application work, I want to again mention the design guidelines. | 20:19 |
| tedg | https://wiki.ubuntu.com/CustomStatusMenuDesignGuidelines | 20:19 |
| tedg | The reason being is that many times an Application Indicator isn't what you need. | 20:19 |
| tedg | We don't want to end up in a situation where people need a 40" screen just to show all the app indicators! | 20:19 |
| tedg | It's also important to not that the category indicators like the Messaging Menu and/or the Sound Menu might be a better solution for your particular application. | 20:20 |
| tedg | matttbe, I'm not sure about Cairo Dock in particular, but if the address has changed we'd change too. We're not intentionally using a different name. I haven't switched to Maverick yet *blush* :) | 20:21 |
| tedg | So I wanted to talk a little about an issue that comes up a lot and that's falling back to the notification area. | 20:22 |
| tedg | Of course the default Ubuntu/UNE desktop isn't what everyone on the planet uses (we're working on it, not there yet :) ) | 20:23 |
| tedg | So it's important that we can fallback to using something compatible in the end. | 20:23 |
| tedg | So libappindicator by default provides a fallback to a GtkStatusIcon that behaves very similar to the Application Indicators. | 20:23 |
| tedg | Some people don't necessarily want to make the same opinionated choices on the design when they're falling back. | 20:24 |
| tedg | Which is fine, but we don't take in enough information to do anything else. | 20:24 |
| tedg | So what we instead provide is a way to change how the fallback is handled via subclassing. | 20:25 |
| tedg | There is two virtual functions fallback and unfallback that can be used to handle the fallback differently. | 20:25 |
| tedg | This could include anything you possibly want, it's just a function call. | 20:25 |
| tedg | If you'd like to see an example of that there is a fallback test included in the test suite of libappindicator. | 20:25 |
| tedg | http://bazaar.launchpad.net/~indicator-applet-developers/indicator-application/trunk/annotate/head:/tests/test-libappindicator-fallback-item.c | 20:26 |
| tedg | For those who aren't C/GObject programmers there is a lot there that you dont' need to understand. | 20:26 |
| tedg | You're probably just most interested in the two functions. | 20:26 |
| tedg | In this case it marks the test as passed/failed based on the calls to the fallback/unfallback functions. | 20:26 |
| tedg | So, if you're using those functions, you know that they're tested as the test suite uses this feature as well :) | 20:27 |
| tedg | There is also a signal when a fallback occurs. | 20:27 |
| tedg | I don't think that this is as useful for implementing a fallback, but it could be used in other parts of your code. | 20:27 |
| tedg | That signal is "connection-changed" which will give you a boolean on the status. | 20:28 |
| tedg | Again, I don't really recommend that route for fallback, but you *could* do it if you wanted :) | 20:29 |
| tedg | When jcastro was asking me about doing this session he said "talk about what's new". I want to stress, there is nothing new -- we're polishing at this point. | 20:30 |
| tedg | But that does introduce some change, but there shouldn't be any API breakage, just extensions. | 20:30 |
| tedg | One of the things that we're planning on supporting is KNSI's support for mouse scroll wheels. | 20:31 |
| tedg | We'll be adding signals to the object for the scroll event. | 20:31 |
| tedg | And then when the mouse is over your icon users can have a "power user" function with the scroll wheel. | 20:31 |
| tedg | The important thing to realize is that this isn't something most folks will find on their own, so don't make that a critical feature of the app. | 20:32 |
| tedg | Try to keep it something that your advanced users can use as they become more comfortable with it. | 20:32 |
| tedg | We're also working on adding label into the interface. | 20:33 |
| tedg | The reason for this is that some applications need custom icons with some text on this. | 20:33 |
| tedg | them | 20:33 |
| tedg | Things like the temperature or the batter percentage. | 20:33 |
| tedg | battery | 20:33 |
| tedg | (typing too much) | 20:33 |
| tedg | There is no reasonable way for them to really make these icons as they don't know the theme that the panel is rendering with. | 20:34 |
| tedg | So if they make an icon that has black text, they could end up on a dark panel and be unreadable. | 20:34 |
| tedg | You can see this today with the keyboard selector in gnome-settings-daemon. | 20:34 |
| tedg | We hope to fix that by rendering the test panel side. | 20:35 |
| tedg | jacob, That is basically the icon policy that GNOME and Ubuntu would like to get to. Unfortunately we're not close to that overall. | 20:36 |
| tedg | jacob, So hopefully all applications, even with icons on, will end up with something similar. | 20:36 |
| tedg | matttbe, We try to release version every week for Maverick on Thursdays. | 20:37 |
| tedg | matttbe, Those in general are pretty stable as we use a Continuous Integration server to make sure they all pass the test suite on every commit. | 20:37 |
| tedg | matttbe, But, I'm sure there's bugs -- it's software :) | 20:37 |
| tedg | Back to talking about new things we want to provide a way for applications to control some of their ordering, and also allowing users to override this. | 20:38 |
| tedg | The idea being that if you have two applications, say Getting Things GNOME! and Hamster, you probably want those two next to each other. | 20:39 |
| tedg | It makes a lot of sense. | 20:39 |
| tedg | For the first pass we'll probably just provide the mechanisms without any UI or real configurability, but we want to grow that in the future. | 20:40 |
| tedg | As currently the order is dependent on the users system, so even from Ubuntu machine to Ubuntu machine they could be different. | 20:40 |
| tedg | This increases "support costs" as if someone calls you on the phone you get to describe the icon instead of saying the "third one" | 20:40 |
| tedg | Last up we want to provide a way to associate the AppIndicator item with the desktop file. | 20:42 |
| tedg | So we're working with the KDE folks to come up with a key in the desktop file to hold the AppIndicator IDs. | 20:42 |
| tedg | This will give us a static way to determine which applications we can expect application indicators from. | 20:42 |
| tedg | We hope to use this to provide better user experiences in the future. | 20:43 |
| tedg | I think the Unity guys might try to get things into Maverick, but I doubt we'll use it for anything in Desktop for Maverick. | 20:43 |
| tedg | Okay, so that's all the material that I wanted to go through. | 20:43 |
| tedg | Is there any other questions? | 20:44 |
| tedg | sao, I believe that the Weather Indicator is being written in Vala. jcastro do you have a link? | 20:45 |
| tedg | jacob, There is currently an applet that you can install called "indicator-applet-complete" that brings all the indicators into a single menu bar. I doubt that we'll use that by default in Maverick, but that's the call of the Ubuntu Desktop Team. The main issue being that the clock indicator doesn't provide all the functionality of the GNOME Applet yet. | 20:46 |
| tedg | jacob, Though, personally, I've switched as I think the tradeoff is worth it. | 20:46 |
| tedg | Okay, thanks everyone for attending. | 20:48 |
| tedg | I'm usually in #ayatana or #ubuntu-desktop if you have further questions. | 20:48 |
| tedg | Or you can join the Ayatana mailing list at http://launchpad.net/ayatana | 20:48 |
| tedg | Sorry, that should have been http://launchpad.net/~ayatana | 20:48 |
| tedg | One is the projects, the "~" is the mailing list. | 20:49 |
| ClassBot | There are are 10 minutes remaining in the current session. | 20:50 |
| ClassBot | There are are 5 minutes remaining in the current session. | 20:55 |
| === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu Developer Week - Current Session: Kernel Triage - Instructor: JFo | ||
| JFo | Hi folks, I'm JFo (Jeremy Foshee) and I am the Kernel Bug Triager | 21:01 |
| JFo | Today we are going to discuss a bit about triaging kernel package bugs. | 21:01 |
| JFo | this class is going to be something of a follow along for the chat from Saturday's Ubuntu User days | 21:02 |
| JFo | logs can be found here for that talk: https://wiki.ubuntu.com/UserDays/07102010/What%20is%20a%20kernel,%20and%20why%20do%20i%20need%20it | 21:02 |
| JFo | so several of the things I'd like to cover are: | 21:02 |
| JFo | 1) duplicate bugs and the Ubuntu Kernel | 21:02 |
| JFo | 2) The subsystem tagging of kernel bugs | 21:03 |
| JFo | 3) triage statuses and the kernel bugs | 21:03 |
| JFo | and 4) The Kernel Triage Summit | 21:03 |
| JFo | please feel free to ask questions as you see fit by prefacing them with QUESTION: | 21:03 |
| JFo | those of you using Lernid will not need to enter that | 21:03 |
| JFo | ok, duplicates :) | 21:04 |
| JFo | For those of you who may not be aware, the Ubuntu kernel team have decided not to continue using duplicates in the current way | 21:04 |
| JFo | this means that, where you would normally have marked bugs that were on the same laptop model, we'd now ask that you do not | 21:05 |
| JFo | this is due to several things, most notably, the fact that not all of the same laptop models carry the exact same chipsets | 21:05 |
| JFo | in some cases bus chips and minor board processors could be from different manufacturers etc. | 21:06 |
| JFo | we have found that minor differences such as these cause us issues when solving bugs | 21:06 |
| JFo | as we have many cases where a fix for one user did not solve other affected users | 21:06 |
| JFo | it was decided that we prefer for anyone affected by a bug to file a ticket for their own issue. | 21:07 |
| JFo | as such we have asked the launchpad team to provide us a way to turn off the ability to mark duplicates | 21:07 |
| JFo | and we are working on ways to preclude apport from recommending apparently related tickets | 21:08 |
| JFo | while this will add a heavy load to myself and the team, we feel it is imperative that we are able to work seemingly related issues differently | 21:09 |
| JFo | this will also allow us to get a better picture of who is affected by a bug and in what way | 21:09 |
| JFo | any questions on the change to the policy on dupes? | 21:09 |
| JFo | ok, moving on to item 2 :-) | 21:10 |
| JFo | subsystem tagging | 21:10 |
| ClassBot | penguin42 asked: OK, so what do you do when you think you have 50 related bugs - do you hae some common bug to attach them all to? | 21:10 |
| JFo | penguin42, no, in that case we would take a look at all of the bugs to identify underlying similarities | 21:10 |
| JFo | we'd then try to fix the underlying problem versus trying to fix symptoms | 21:11 |
| JFo | this would allow us to narrow our work to address the issue in a better manner. | 21:11 |
| JFo | It is also important to note that it is not the primary goal of the team to solve issues upstream | 21:12 |
| JFo | but this has the added benefit of helping us identify what upstream bugs could be related to a particular group of issues | 21:12 |
| ClassBot | simar asked: Regarding your duplicate policy, if we have duplicate bugs still the developers can have bugs grouped so they can work on like workable bugs in one go? | 21:12 |
| JFo | simar, we'd prefer not to use the duplicate feature in that way | 21:13 |
| JFo | in a perfect world, we could identify which bugs are actually duplicates and mark them such, but that takes a lot of overhead | 21:13 |
| JFo | in my perfect world, each of our bugs has an upstream bug watch :-) | 21:14 |
| JFo | and we would use those to identify related bugs | 21:14 |
| JFo | now, let me get back to subsystem tagging :) | 21:14 |
| JFo | https://wiki.ubuntu.com/Kernel/Tagging is the exhaustive listing of tags currently used by the team | 21:15 |
| JFo | there are tags listed from Bugs/Tags/ that have been used for some time | 21:15 |
| JFo | and you will also see that there are subsystem specific tags | 21:15 |
| JFo | this is an effort for us to break down kernel bugs in to a few subsystem categories | 21:16 |
| JFo | this will allow us to triage specific sections that triagers have knowledge in | 21:16 |
| JFo | while also enhancing our documentation of those subsystems | 21:16 |
| JFo | this will have the added benefit of helping those individuals interested in a particular subsystem to focus their energy and move their knowledge forward as they learn more about the kernel | 21:17 |
| JFo | i hope for this to empower community members to learn more about the bugs they file too | 21:18 |
| JFo | Please keep in mind that we are currently refining our wiki documentation, so these links I am giving you are probably going to change in the near future | 21:19 |
| JFo | the content on them, that is | 21:19 |
| JFo | any questions on the subsystem tags? | 21:19 |
| JFo | ok, we will move on to statuses in that case. | 21:20 |
| JFo | most of you are familiar with the bug status, "NEW", "INCOMPLETE", etc. | 21:20 |
| JFo | what you may not be aware of, is how I use those to process kernel bugs programmatically | 21:21 |
| JFo | given that at any particular time we currently have over 6000 bugs open against the kernel, it is not realy possible for me to provide a focused answer to each. | 21:22 |
| JFo | this is where the arsenal scripts i use come in handy | 21:22 |
| JFo | and also, in some cases, cause me headaches ;-) | 21:22 |
| === ext2 is now known as ext3 | ||
| JFo | the scripts are meant as a method to keep information current in bugs as to testing based on updates we pull in from upstream stable and Debian | 21:23 |
| JFo | as well as determining what information is missing from a bug and requesting that | 21:23 |
| JFo | some people get annoyed with me for sending them an automated response, and I'd prefer not to have to, but this is just not possible. | 21:24 |
| JFo | i am working on a definitive page identifying the benefits of using the scripts, but i have not yet made it available | 21:25 |
| JFo | I hope to do so and link to it from the automated response as soon as next week. | 21:25 |
| JFo | this page should also provide some further information on the scripts themselves and what they do | 21:25 |
| JFo | any questions on the statuses? | 21:26 |
| ClassBot | charlie-tca asked: should we as triagers be using triaged, or leave that one for you to set? | 21:27 |
| JFo | charlie-tca, I am perfectly happy for you to set bugs to triaged | 21:28 |
| JFo | the only thing i want for them is that they have all the logs, have checked upstream kernels and latest development | 21:28 |
| JFo | :) | 21:28 |
| JFo | my goal is for most of the bugs to be in a triaged state so that they can be pinged when there are relevant updates to the kernel that may affect the specific issues encountered. | 21:29 |
| JFo | ok, Kernel triage summit | 21:29 |
| JFo | This will be like an ubuntu user day session in the -classroom channel here | 21:30 |
| JFo | but it will be geared toward the subsystems, and providing those of you interested with a deeper understanding of what information is helpful for what subsystems | 21:30 |
| JFo | my goal is to provide a bit of professional development for those of you interested in a specific piece of the kernel | 21:31 |
| JFo | we will have sessions much like these on bugs in graphics, sound etc. | 21:31 |
| JFo | and there will be representatives from the kernel team, and hopefully some upstreams so that there will be greater coverage for Q&A | 21:32 |
| JFo | one of the main focuses of this summit will be knowledge and documentation | 21:32 |
| JFo | I want the interested parties to broaden their understanding, while at the same time fleshing out or subsystem wiki pages. | 21:33 |
| JFo | This will most likely be held at the end of August or the first part of September | 21:33 |
| JFo | any questions on that? :) | 21:33 |
| JFo | ok, I'm going to add a point that I missed earlier | 21:34 |
| JFo | the Live ISO testing images | 21:34 |
| === ext2 is now known as ext3 | ||
| JFo | It has been my goal for a while now to provide a testing ISO based off of the daily LiveISO image | 21:34 |
| JFo | this ISO will boot straight into the desktop as the ubuntu user | 21:35 |
| JFo | and will provide a series of tests against the most common kernel issues we see | 21:35 |
| JFo | it will enable LoCo teams to do localized testing of the machines available at meetings and Global days | 21:36 |
| JFo | while at the same time providing the ubuntu kernel team with much needed information on failures | 21:36 |
| JFo | my goal, thanks in very large part to the efforts of bjf | 21:36 |
| JFo | is to have these building daily by the end of next week so that we can test them out and start making them available | 21:37 |
| JFo | whether or not that happens... we shall see :-) | 21:37 |
| JFo | any questions on the Triage Summit? | 21:37 |
| JFo | or the Live ISO testing images | 21:37 |
| JFo | I'll take that to mean I have covered these topics thoroughly :-D | 21:38 |
| ClassBot | simar asked: good work for Live ISO testing images. Great Idea. will this be available on internet. | 21:39 |
| JFo | they will be available via the kernel PPA | 21:39 |
| JFo | I will also have a wiki page describing them and how to create and submit tests for inclusion in the test suite | 21:39 |
| JFo | there will also be a description of the current tests that are available | 21:40 |
| ClassBot | simar asked: we will be really happy to test !!! | 21:40 |
| ClassBot | charlie-tca asked: they will include a daily kernel ? | 21:40 |
| JFo | simar, :-) | 21:40 |
| JFo | charlie-tca, they will have what is available to the Live ISO, so it will be the most current development kernel | 21:41 |
| JFo | along with all other available development packages, with the notable exception of Open Office | 21:41 |
| JFo | and a few others | 21:41 |
| JFo | this is mainly to allow us to add the testing stuff and not go over our space allowance | 21:42 |
| JFo | a brief idea of the tests we have currently are: suspend/resume | 21:42 |
| JFo | video modesetting | 21:42 |
| JFo | sound | 21:42 |
| JFo | recording | 21:43 |
| JFo | among others | 21:43 |
| JFo | all things that are built on the kernel or have kernelspace items | 21:43 |
| JFo | any other things you want to talk about? | 21:43 |
| JFo | ok, well, thanks for listening and asking questions. It is a lot of information to parse :) | 21:44 |
| ClassBot | penguin42 asked: Which X version is on those disks? Latest for the distro or an edgers? | 21:44 |
| JFo | penguin42, it will be whatever is rolled for the daily ISO | 21:45 |
| JFo | I couldn't say for sure | 21:45 |
| JFo | I'll hang around until the end of the session if you have further questions. | 21:45 |
| JFo | after this, i am always available in the #ubuntu-kernel channel along with the rest of the team | 21:45 |
| JFo | thanks everyone :-) | 21:46 |
| JFo | I should also mention, the Triage Summit idea came from sconklin :) | 21:50 |
| ClassBot | There are are 10 minutes remaining in the current session. | 21:50 |
| JFo | Thanks folks! I really appreciate all of your questions! :-) | 21:55 |
| JFo | see you next time. | 21:55 |
| ClassBot | There are are 5 minutes remaining in the current session. | 21:55 |
| === 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 | ||
| === pgraner is now known as pgraner-afk | ||
| === bauerj is now known as bauerj|away | ||
| === dave is now known as Guest98544 | ||
| === Guest98544 is now known as arbleow | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
