=== mohi_away is now known as mohi1 === mohi1 is now known as mohi_away === kermiac_ is now known as kermiac === tarzeau_ is now known as tarzeau === mohi_away is now known as mohi1 === yofel_ is now known as yofel === mohi1 is now known as mohi_away === mohi_away is now known as mohi1 === mohi1 is now known as mohi_away === mohi_away is now known as mohi1 [20:58] * jcastro taps on the mike [20:58] 2 minutes! === mohi1 is now known as mohi_away === 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 || Current Session: Adopt an Upstream - Instructor: jcastro || Questions in #ubuntu-classroom-chat [21:01] ok, I'll give it a few more minutes for the last minute stragglers [21:01] wave if you plan on participating in this class please! [21:04] ok let's get started [21:05] this session is Adopt an Upstream/Package [21:05] I'm Jorge Castro [21:05] by day I work at Canonical on the Ubuntu community team [21:05] by night I fight crime. ( Just kidding ) [21:05] This session is going to be for people who are interested in strengthening our relationship with upstream projects by means of doing bug work [21:06] So let's start off with the basics, what exactly is an "upstream" [21:06] if you think about it like a river it makes sense [21:06] there are projects out there like GNOME, KDE, Firefox, gwibber, openoffice, etc. that are independent software projects [21:07] what a distribution does is put all those together, add some polish, and ship it as an os that we call "Ubuntu" [21:07] so, these projects are what we call upstreams [21:07] for many of these we derive the packaging from Debian, so in a way Debian is also an upstream to us. [21:08] and for derivatives that build off of ubuntu, they're downstream from us, and we're their upstream [21:08] so it's like a big river [21:08] sometimes these relationships get complicated, so for most users they might not understand where the software comes from [21:08] so when we get bugs they might not be something Ubuntu can fix [21:09] but since we distribute this software, it's our responsibility to make sure that user bugs and things are reported, especially if those bugs contain a patch. [21:09] For major projects we have instructions on how to "forward" these bug reports. [21:10] https://wiki.ubuntu.com/Bugs/Upstream [21:10] however, we have lots of users [21:10] and upstreams usually have finite resources [21:10] so what we need in abundance are people who are skilled enough to filter out the bad bugs, and ensure that upstreams are getting the high quality bug reports. [21:11] We purposely don't do anything like automatically forwarding bugs, because that would get out of control quickl;y [21:11] we need an actual human being to check each bug report and make sure it doesn't suck before considering forwarding it upstream [21:11] so, we created a program for people to be able to say "I want to do this!" [21:11] so we created Adopt a Package [21:11] https://wiki.ubuntu.com/BugSquad/AdoptPackage [21:12] This is basically when someone says "I care about this program, and I want to help fix it." [21:12] So on this page we list programs that could use the help [21:12] Let me show you an example of one. [21:12] https://bugs.edge.launchpad.net/ubuntu/+source/gwibber [21:12] this is a program that has been getting love lately [21:13] and yet there are still 61 bugs in the "new" state [21:13] that means there are 61 opportunities to either confirm a bug, mark it a duplicate, or maybe it's not a bug at all [21:13] http://status.qa.ubuntu.com/qapkgstatus/gwibber [21:13] now if we look at this graph [21:14] we can see that the amount of triaged bugs is going up [21:14] but we can probably do a better job taking care of the "new" bugs. [21:14] So as you can see here this is a package that people have started to take care. [21:14] So really, what's required to "adopt" a package [21:15] Well, the one fundamental thing you really need is to care about it [21:15] I usually tell people to pick a program they're passionate about [21:15] be it your pet mp3 player or something else [21:15] then really you can just dive in the open bug reports. === mohi_away is now known as mohi1 [21:15] many of these are low hanging fruit [21:15] for example as we get towards beta many people will start reporting bugs [21:15] but might not have enough information to be useful [21:16] so just by asking people to use apport or to add more detail in the bug report can be useful. [21:16] Remember that the more information we can have in a bug, the better [21:16] so if we can have people just adding more information that can save time later on when a developer is trying to solve the problem [21:17] also, as we get later in the betas people tend to report more duplicates [21:17] one can spend days just marking duplicates, so that is something you can do. [21:17] when you get a good quality bug report and it's been triaged [21:18] sometimes a developer will mention that it's probably a bug in the upstream software [21:18] but they might not link it to the upstream bug report [21:18] another possible place to help bugs is when they have patches attached [21:18] https://bugs.edge.launchpad.net/ubuntu/+source/gwibber/+patches [21:18] on any person, project, or package in launchpad you can add a +patches to the URL [21:19] and it will show you any patches that people might have attached to a bug. [21:19] many packages have tons of old patches that might be sitting there throughout the years or months [21:19] so keeping an eye on the +patches for a package is something that can be done [21:19] sometimes it might be old or doesn't apply [21:20] or sometimes it just needs some testing [21:20] and in some cases asking the person to push the patch upstream can be helpful [21:20] remember that while it's nice to fix it in ubuntu it needs to go back to the original project! [21:20] this is a good idea for a number of reasons [21:20] a) It's just the right thing to do to help improve their software [21:20] b) Less maintenance and delta from upstream is always a good thing [21:21] c) Sending it upstream fixes it for everyone long term instead of for one release of ubuntu [21:21] Any questions so far? [21:21] qense: anything to add? [21:22] one thing I like to do, when watching the +patches view [21:22] is taking note of that "age" column [21:22] if someone has taken the time to write a patch for something [21:22] and it's been sitting there for months and no one has responded, then that's pretty rude! [21:22] so I usually try to remind a maintainer if a patch has been rotting in lp [21:23] many maintainers have tons of things to do [21:24] so if someone does that filtering for them that gets the important things filtered from the chaff, then that's more time they can spend to help make ubuntu better, [21:24] any questions so far? That's basically it [21:25] as always, feel free to ask someone in #ubuntu-bugs if you have questions on how to be a better adopter [21:26] and thanks for your time! [21:28] Question: does this apply only to packages in main? [21:28] oh, I thought the questions were asked in the other room [21:28] damn [21:29] I don't think this went well [21:29] ah sorry [21:29] let's start over with the questions [21:29] they were [21:29] leftyfb | who do we get to push patches and how? [21:29] so usually this might be a maintainer [21:30] but it can also be a team [21:30] so for example, let's say you're looking at patches in gqibber [21:30] er, gwibber [21:30] https://bugs.edge.launchpad.net/ubuntu/+source/gwibber/+patches [21:30] so in this case I would ping the maintainer, ken-vandine [21:31] but, we know that gwibber is on the desktop by default now [21:31] so we can probably poke the team [21:31] so let's say ken get's hit by a bus and doesn't respond [21:31] (poor ken) [21:31] in that case we could ping someone on the ubuntu desktop team, by either using their mailing list or irc channel [21:31] charlie-tca | QUESTION: are we only applying this to packages in main? [21:31] this actually applies to everything in the archive [21:32] in fact, it's those odd packages in universe that not many people use that usually need the most help! [21:32] Okay [21:32] this happens to me sometimes [21:32] I'll meet someone and they'll say "no one cares about my cli mp3 player written in lisp!" [21:33] but when you show people how to forward bugs to the right place they usually figure it out [21:33] actually, now that you asked that it brings up another possible place to collaborate, debian. [21:33] when you push a patch upstream this benefits debian as well [21:33] however with certain fixes [21:34] like packaging fixes, it makes sense to ensure that that fix gets to debian [21:34] in fact you'll see many sponsors ask if the patch has been sent to debian as part of the sponsorship process. [21:34] which is a good thing [21:34] so we can use tools like "submittodebian" for things like this [21:35] http://udd.debian.org/cgi-bin/ubuntu_usertag.cgi [21:35] when we do that we tag the bugs [21:35] so in this report you can see that we've forwarded 1557 bugs to debian [21:35] 1265 have some form of patch attached [21:36] so as you can see we can do some good there by keeping debian in the loop for patches [21:36] however for some packages it may just be appropriate to send it upstream and debian/ubuntu just pick it up the next sync [21:36] any other questions? [21:37] thanks [21:38] sorry one more [21:38] hah, I've been looking for a reason to use the ultimate debian database for something [21:38] yes, I looked at claws-mail. There is a developer from claws-mail subscribed to the bugs. It is still a candidate for adoptapackage? [21:38] what if it's in Fenian and sourceforge? [21:38] don't be sorry I am here to please! [21:38] submit to both? [21:38] which project? [21:38] gstm [21:38] I submit to whichever one upstream uses most. [21:39] if you're unsure I fire off an email to a developer [21:39] because sometimes they have different requirements [21:39] for example, some want patches submitted a certain way [21:39] the sf project seems to be dead [21:39] some want patches in bugzilla, and some want them on a mailing list instead. [21:39] heh, no surprise there! [21:39] submit it to where upstream is looking the most. [21:40] this can change too, it's not totally uncommon when I might mail someone and ask [21:40] and it ends up they abandoned that bug tracker or something [21:40] Fenian being the upstream right ? [21:40] deviant sorry [21:40] iPhone and driving :) [21:40] hah, I am looking for it now [21:41] hmm, all the data in the package points to SF [21:42] right but emmet told me upstream is debian I think [21:42] so probably abandoned upstream? [21:42] no clue [21:43] yeah, the last release says 2006 on the tarball [21:43] heh, this appears to be one of those cases where you might wake up one day and be the upstream. :p [21:44] charlie-tca: yeah [21:44] charlie-tca: usually if an upstream cares enough to watch distro bugs then he probably needs help doing it [21:44] charlie-tca: usually just asking him for help can be fruitful there. [21:44] works for me, I guess I'll grab that one then [21:44] you can split up things, especially for large packages [21:45] or maybe you can tackle a certain class of bugs for him or something [21:45] charlie-tca: the "idea" I try to convey to upstreams is, when they have a problem that they have "our guy over at ubuntu" [21:45] charlie-tca: sometimes it could be as simple as just answering questions for them [21:46] It's just a handful of bugs for claws-mail. I will get with him on them. [21:46] about things like the release schedule [21:46] ok, now i'm on a real computer :) [21:46] or "I have a security fix I need to get out to my users, where do I go?" [21:46] and then you point them to the security page or something [21:47] A lot of the non-main packages seem to just sit, with the bugs getting missed completely [21:47] with alot of those smaller upstreams it's a good idea to remind them when freezes are [21:47] because sometimes they are in debian too [21:47] ok, so jcastro ... how would one find out who is the upsteam? By looking at apt-cache policy for the package? In gstm's case it says sourceforge. Should we then be just checking debian just in case? And in this case, hasn't been touched since 2006 so the upstream is??? Now part of ubuntu since all further development has been done with us? [21:47] so I tell them like "hey, freeze is on this date, so if you want to get a release in for Lucid you should probably target around this date" [21:48] leftyfb: ok, so this is what I do [21:48] apt-get source gstm [21:49] then cd into that dir [21:49] in there most programs have an AUTHORS file and a ChangeLog file [21:49] http://pastebin.com/DhQwaxy0 [21:49] is what I see in the authors [21:50] the ChangeLog file in the root is usually the upstream changelog [21:50] the debian/changelog will be the person that put it in debian/ubuntu [21:50] There are are 10 minutes remaining in the current session. [21:50] leftyfb: so, I've done this a bunch of times [21:51] and let me share with you what I think will happen [21:51] you'll email those two guys and they'll say "oh yeah, I remember when I worked on that, people still use that? awesome!" [21:51] and then you'll ask what's up with a new release or something [21:51] and next thing you know, you are the upstream maintainer for gstm! [21:52] Original-Maintainer: Ryan Niebur [21:52] what about that from apt-cache show [21:52] ? [21:52] how does he fit in? [21:52] that's likely the guy who put it in Debian and now maintains it [21:52] he probably contacted the two guys from AUTHORS [21:52] so I should be contacting him first? [21:52] yeah [21:52] I would say something like [21:52] ok [21:53] "hey I saw you in the maintainers field, are you just maintaining this in debian or are you doing upstream work?" [21:53] "and if so, is the SF project dead or what?" [21:53] ok, makes sense [21:54] there are plenty of packages maintained like that in debian [21:54] so in that case you could just file the bugs directly in the debian BTS [21:54] if he's not looking at the SF bugs then the homepage field in the package needs to be updated [21:55] There are are 5 minutes remaining in the current session. [21:56] charlie-tca: I see claws has a ppa too [21:56] nice [21:56] I'm learning [21:57] still a lot to learn with all this [21:57] yeah sometimes they need help setting up PPA [21:57] but i'd love to get the package all cleaned up and up to date [21:57] leftyfb: you can always just ask questions [21:58] but if you can have a good relationship with the debian guy that's always ideal [21:58] #ubuntu-bugs <~~ in there? [21:58] sure [21:58] when I am not around you can always ping qense [21:59] ok I need to eat dinner, any last questions! [21:59] thanks [21:59] good thing I looked in -chat, sorry about missing it the first time! [21:59] I was like "man bummer, no one came to my class", lol [22:00] heh, Thank you very much for doing this [22:00] jcastro, thanks for this session [22:00] still learning... [22:00] :-) [22:00] don't worry, with openweek coming up in a few weeks we'll do it again === 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