Ubuntu Wiki

Dev Week -- Adopt-An-Upstream -- JorgeCastro -- Fri, Jul 16th, 2010

(02:00:52 PM) jcastro: Hi everyone!
(02:01:05 PM) jcastro: This class will be about Adopt an Upstream
(02:01:23 PM) jcastro: thanks for coming, let's get started!
(02:01:36 PM) jcastro: First of all, what is an upstream
(02:01:43 PM) jcastro: and why should we adopt them?
(02:02:01 PM) jcastro: Imagine that "Ubuntu" as a distribution sits on a river
(02:02:20 PM) jcastro: we take software from large projects, GNOME, KDE, Linux, Xorg, etc.
(02:02:39 PM) jcastro: imagine that those projects are "upstream" along the river
(02:02:51 PM) jcastro: because their software flows down to us
(02:03:00 PM) jcastro: inbetween us an upstreams on this river is Debian
(02:03:23 PM) jcastro: and further "downstream" from Ubuntu you have things that are derivatives from Ubuntu
(02:03:29 PM) jcastro: Things like Linux Mint, etc.
(02:04:23 PM) jcastro: (sorry my linode disconnected me)
(02:04:38 PM) jcastro: ok so on this big "Free Software river" we have all these projects
(02:05:01 PM) jcastro: so when you hear people talking about "upstreams", they're usually referring to a project that we ship in Ubuntu
(02:05:28 PM) jcastro: so for example, the rhythmbox folks, Mozilla, Miro, couchdb, etc. are all examples of upstream projects
(02:05:45 PM) jcastro: since the software flows downstream (like a boat)
(02:05:52 PM) jcastro: things need to flow upstream.
(02:06:02 PM) jcastro: Bugs about the software
(02:06:12 PM) jcastro: patches that potentially fix the software
(02:06:18 PM) jcastro: feedback on the software
(02:06:20 PM) jcastro: things like that
(02:06:41 PM) jcastro: and like swimming upstream, it takes effort, patches and bugs don't magically flow upstream
(02:07:01 PM) jcastro: so like on rivers with dams, we can build little fish elevators so stuff can flow back.
(02:07:25 PM) jcastro: this "flow", "circle of life", or whatever you want to call it needs to be efficient, or bad things can happen
(02:07:47 PM) jcastro: For example, when we started actually measuring the amount of patches sitting in Launchpad waiting for review
(02:07:54 PM) jcastro: we found /over 2500/ patches.
(02:08:11 PM) jcastro: https://wiki.ubuntu.com/OperationCleansweep
(02:08:14 PM) jcastro: so we started this
(02:08:25 PM) jcastro: to start getting those fixes and patches reviewed, and upstream.
(02:08:38 PM) jcastro: Any questions so far?
(02:09:22 PM) jcastro: (bah one sec)
(02:09:46 PM) jcastro: < simar> QUESTION: Are there projects that are created on launchpad with no upstreams..
(02:09:59 PM) jcastro: in those cases the project themselves are the upstream
(02:10:05 PM) jcastro: not everything is in Debian and/or Ubuntu
(02:10:16 PM) jcastro: and even in the case of software that we make for ubuntu, the same flow applies
(02:10:35 PM) jcastro: so for example, the software-center is an upstream
(02:11:07 PM) jcastro: ok, so now that you know about the river, let's talk about some of the things you can do to make this flow be more efficiently
(02:11:57 PM) jcastro: as I talk about some of these things you're going to think it's all common sense
(02:12:10 PM) jcastro: and "wow, how come people just aren't doing that every day?"
(02:12:40 PM) jcastro: So, with over 20k packages in our archive, it can be tough to keep track of all this stuff
(02:12:50 PM) jcastro: so, we know we have users who care about stuff
(02:13:04 PM) jcastro: and we know we have upstreams who always wouldn't mind extra help
(02:13:22 PM) jcastro: so, what if we connected people who are passionate about software with the upstream?
(02:13:43 PM) jcastro: so, we created adopt-an-upstream
(02:14:30 PM) jcastro: which is basically explained here: https://wiki.ubuntu.com/Upstream/Adopt
(02:15:04 PM) jcastro: the idea being "I care about my favorite mp3 player, so I am going to work with upstream and ubuntu developers to get things sorted"
(02:15:18 PM) jcastro: larger projects, like our amazing MozillaTeam are larger
(02:15:48 PM) jcastro: however, poor Joe Smith who started a quickly project last month might not be so lucky.
(02:16:41 PM) jcastro: So, let me talk to you about some examples on what I do with my personal favorite piece of desktop software, Banshee
(02:17:02 PM) jcastro: I idle in their IRC
(02:17:08 PM) jcastro: I subscribe to their mailing lists
(02:17:11 PM) jcastro: I read their roadmaps
(02:17:21 PM) jcastro: and I do these sorts of things on the distro side as well
(02:17:32 PM) jcastro: I try to be the "ubuntu guy" for them.
(02:17:52 PM) jcastro: So if they have a fix that they want out to users, I help getting them talk to the packager, etc.
(02:18:10 PM) jcastro: And I just don't it myself, we have people from the Debian and Ubuntu Mono teams who chip in
(02:18:28 PM) jcastro: so overall we try to basically "be there" for the upstream project.
(02:18:57 PM) jcastro: Another place where upstreams appreciate help is bug reporting
(02:19:15 PM) jcastro: http://castrojo.tumblr.com/post/785661804/papercutter-profile-marcus-carlson
(02:19:31 PM) jcastro: I just blogged about a guy who not only was working on the ubuntu problems, but also helping the upstream clean up their bugs
(02:19:36 PM) jcastro: and generally Being Awesome.
(02:19:57 PM) jcastro: So what we have is a list: https://wiki.ubuntu.com/BugSquad/AdoptPackage
(02:20:12 PM) jcastro: and basically you kind of take ownership of that package
(02:20:18 PM) jcastro: you go through the bug reports
(02:20:32 PM) jcastro: Launchpad makes it real easy for people to link to upstream bugs
(02:20:42 PM) jcastro: unfortunately sometimes people don't know how to make good bugs
(02:20:48 PM) jcastro: it might be missing good information, etc.
(02:21:17 PM) jcastro: And to be honest, who wants developers reading bugs all day? We want them fixing bugs!
(02:21:27 PM) jcastro: So what we try to do is act as a quality filter on bugs
(02:21:38 PM) jcastro: we weed out the junk bugs (or try to get reporters to add information)
(02:22:01 PM) jcastro: and then only forward the best bugs we can
(02:22:20 PM) jcastro: So really, you don't have to be a rocket scientist
(02:22:52 PM) jcastro: all it really takes is someone who is willing to put one foot in each project and connect people, bugs, and patches.
(02:22:59 PM) jcastro: Any questions so far?
(02:23:51 PM) jcastro: Ok, another area of things you can talk to upstreams about are some of the great tools we've made for upstream developers to use.
(02:24:01 PM) jcastro: Maybe they need help setting up a daily build PPA.
(02:24:12 PM) jcastro: Or a stable release PPA for older Ubuntu releases.
(02:24:34 PM) jcastro: maybe they're not in Ubuntu yet, and want to know how to get into Ubuntu.
(02:24:49 PM) jcastro: or maybe they don't understand the workflow with Debian.
(02:25:10 PM) jcastro: So since I got sick of explaining it to projects over and over again ... I just wrote them all down
(02:25:14 PM) jcastro: https://wiki.ubuntu.com/Upstream
(02:25:36 PM) jcastro: The goal of this page is to give upstreams a "everything you need to know about Ubuntu in one page"
(02:25:47 PM) jcastro: it's not really new content, it just points people to existing pages.
(02:25:57 PM) jcastro: You might be looking at this and saying "well, duh."
(02:26:19 PM) jcastro: but remember every upstream project is different, so we can't expect them to know what a PPA, and SRU, or Notify-OSD is, for example.
(02:26:52 PM) jcastro: one of my FAVORITE things we can do for upstreams is hook them up with apport hooks.
(02:27:14 PM) jcastro: So you've all seen when an application crashes
(02:27:35 PM) jcastro: and we gather this info, and attach it to the bug report
(02:27:55 PM) jcastro: https://wiki.ubuntu.com/Apport/DeveloperHowTo
(02:28:17 PM) jcastro: we can write these to get more information
(02:28:52 PM) jcastro: So for example, the Banshee guys are currently moving over from HAL (the old device stuff), to udev/gio/libgpod (all the new sexy bits)
(02:29:02 PM) jcastro: and they want to test this
(02:29:07 PM) jcastro: but in order to be truly useful
(02:29:20 PM) jcastro: we need things like the firmware version and all this kind of stuff
(02:29:25 PM) jcastro: in the past we would make a huge wiki page
(02:29:36 PM) jcastro: and say "fill in your ipod info here and link it to your bug"
(02:29:48 PM) jcastro: but with apport hooks we can make that automatically
(02:29:58 PM) jcastro: so today I asked didrocks to whip up one for Banshee ipod testing
(02:30:13 PM) jcastro: so now users can plug stuff in, click stuff, and auto submit data.
(02:30:28 PM) jcastro: So what I did today was talk to one of the Banshee developers
(02:30:46 PM) jcastro: and asked him how we could help. What fields of information did he need from the debug tools?
(02:30:53 PM) jcastro: where should we send the data?
(02:31:07 PM) jcastro: is the data we send you good enough to help you add support for that model?
(02:31:23 PM) jcastro: where do we send data that is so new that we need to submit that data to his upstream, libgpod?
(02:31:47 PM) jcastro: those are the kinds of things adopters think about, and try to fix.
(02:31:50 PM) jcastro: < umang> QUESTION: I know there should be enough projects out there who could be helped. But I was still wondering whether there is a place (e.g. wiki page) where upstreams can register themselves for "we want someone familar with
(02:31:54 PM) jcastro:                Debian/Ubuntu to help us work with them"
(02:31:58 PM) jcastro: that is an excellent question
(02:32:10 PM) jcastro: so ideally, every upstream would have a person to do this
(02:32:41 PM) jcastro: however we always have limited time and volunteers
(02:32:49 PM) jcastro: (which is why we always run sessions looking for more)
(02:33:26 PM) jcastro: right now the best thing to do if you need to be adopted is to add yourself to the wiki page, or ask for help on a mailing list.
(02:33:35 PM) jcastro: https://wiki.ubuntu.com/BugSquad/AdoptPackage
(02:33:45 PM) jcastro: so under "Packages that should really be adopted"
(02:34:04 PM) jcastro: I would just add your project there, and perhaps a note "Get in contact with me and I'll help get you started" or something like that
(02:34:36 PM) jcastro: the people in #ubuntu-bugs and the BugSquad can help you as well
(02:34:57 PM) jcastro: and we can always do our best to help find you a person
(02:35:09 PM) jcastro: < umang> jcastro, I was asking more in terms of finding upstreams that could do with help.
(02:35:19 PM) jcastro: ah, so really, that is a great question because it's all of them
(02:35:25 PM) jcastro: I know that sounds like a lame answer
(02:35:41 PM) jcastro: What I recommend to people is to do something you're familiar with
(02:35:44 PM) jcastro: and passionate about
(02:35:53 PM) jcastro: no one wants to spend all day working on software they hate
(02:36:11 PM) jcastro: The big projects always need a hand (Mozilla, OOo)
(02:36:24 PM) jcastro: but I personally prefer to pick something more in the middle. Not too big, not too small.
(02:36:39 PM) jcastro: It's also important to remember that you are part of a larger team
(02:36:58 PM) jcastro: so don't think if you want to help OpenOffice with bugs that you're going to get swamped and killed.
(02:37:38 PM) jcastro: Another way you can help projects is by trying to find them new volunteers.
(02:37:53 PM) jcastro: I am notorious for doing this. I basically find people who aren't busy and convince them to help a project.
(02:38:21 PM) jcastro: http://castrojo.tumblr.com/post/656609843/someone-want-to-help-out-redshift
(02:38:24 PM) jcastro: Here's an example
(02:38:53 PM) jcastro: < simar> QUESTION: Say I have adopted a package and aren't enough bug triagers that help with that package, one possible reason for this is that the package is not properly documented anywhere, so some odd triagers will always ask
(02:38:57 PM) jcastro:                for irrelevent information from bug filers should someone, probably who know more consider adding a wiki page on information to ask while triaging and debug procedures,,
(02:39:02 PM) jcastro: aha! awesome, I was just going to get to that
(02:39:31 PM) jcastro: let's look at some examples
(02:40:16 PM) jcastro: https://wiki.ubuntu.com/Bugs/Upstream
(02:40:31 PM) jcastro: here's an example of some pages on where we talk about how to triage bugs in more detail
(02:40:36 PM) jcastro: (this includes forwarding)
(02:40:49 PM) jcastro: remember since every upstream is different they might have different workflows
(02:41:03 PM) jcastro: so for example, some upstreams want to see every bug, crap or not, they want them all
(02:41:11 PM) jcastro: some want us to filter
(02:41:33 PM) jcastro: some want patches in bugzilla, some want them in a git branch, some even (still!) want patches posted on mailing lists
(02:41:44 PM) jcastro: so here on these pages we try to document how to make that process suck less.
(02:42:01 PM) jcastro: so on these pages, the bugsquad took care of the big ones, like KDE and GNOME
(02:42:12 PM) jcastro: but let's look at this one: https://wiki.ubuntu.com/Bugs/Upstream/Listen
(02:42:20 PM) jcastro: someone who cared about the Listen media player made that page
(02:42:41 PM) jcastro: < NMinker> QUESTION: Would it be smart to join a team who only pushes every other new release to (let's say) the main Maverick repo? So that issues (like kernel/program incompatibility) are fixed pushed to the main repo.
(02:42:47 PM) jcastro: ABSOLUTELY
(02:43:02 PM) jcastro: let's say you're a generalist
(02:43:24 PM) jcastro: and you are interested in the desktop
(02:44:06 PM) jcastro: (actually hold on, their page is broken, let me find a more squared away team *cough*)
(02:45:12 PM) jcastro: (almost found it, smoke if you got em)
(02:46:03 PM) jcastro: https://wiki.ubuntu.com/BugSquad/TODO
(02:46:04 PM) jcastro: ok
(02:46:19 PM) jcastro: so in this example the BugSquad has a list of stuff that needs to get done
(02:46:30 PM) jcastro: each team should have a list of "low hanging fruit"
(02:47:00 PM) jcastro: for something like the kernel (which is large and has a large team), my recommendation is to just show up on IRC and ask someone for some things that need to get done
(02:47:20 PM) jcastro: https://wiki.ubuntu.com/DesktopTeam/GettingStarted
(02:47:29 PM) jcastro: here the desktop team has a list of where to sign up
(02:47:36 PM) jcastro: and links to bugs you can work on
(02:48:02 PM) jcastro: < NMinker> I asked because I'm currently testing Maverick on VMware, and packaging (for open-vm-tools) available in the repo don't compile properly.  And I had to go the bug report and grab the patches needed to make it compile
(02:48:06 PM) jcastro:                  properly in Maverick and push it to my PPA.
(02:48:19 PM) jcastro: so this is my favorite kind of situation
(02:48:35 PM) jcastro: can you link me to the bug?
(02:48:41 PM) jcastro: I'd like to take some time to talk about this
(02:48:52 PM) jcastro: because I'd like to close the loop on things like this
(02:50:08 PM) jcastro: so first off, this is also an example of a "service" that you can help with upstreams
(02:50:21 PM) jcastro: perhaps they have a certain patch that they are interested in, but need it tested
(02:50:34 PM) jcastro: throwing it in a PPA and letting them know about it lets them throw testers at it
(02:51:00 PM) jcastro: so in this case where you have a fix
(02:51:09 PM) jcastro: and you have it in a PPA
(02:51:41 PM) jcastro: the best thing to do is put it in Maverick, you can do that by generating a debdiff, posting it on the bug, and testing it, and then ask a sponsor to look at it
(02:52:03 PM) jcastro: https://wiki.ubuntu.com/SponsorshipProcess
(02:52:33 PM) jcastro: ok, any other questions? Is there an area you want me to go over again?
(02:53:16 PM) jcastro: one thing I find tremendously useful is to be the ubuntu factoid for an upstream
(02:53:31 PM) jcastro: so for example, I am mindful of when freezes are in our development process
(02:53:35 PM) jcastro: and how things might work
(02:54:06 PM) jcastro: sometimes I know an upstream will say "ah, their feature freeze is on 12 may, that means I can release on 11 may and still make it for lucid!" or whatever
(02:54:36 PM) jcastro: this is an excellent time to get them talking to a packager or a Debian Developer
(02:55:00 PM) jcastro: because there is always plumbing stuff going on in a distro that upstreams might not be aware of
(02:55:43 PM) jcastro: QUESTION: are there any minimal expectations from someone who adopted a package? I adopted the debian-installer packages a few months back but I think it's going to take some time to get everything really nice
(02:56:19 PM) jcastro: https://wiki.ubuntu.com/Upstream/Adopt
(02:56:24 PM) jcastro: I tried my best to list those at the bottom
(02:56:34 PM) jcastro: and asked some upstreams what they would expect someone like that to be
(02:56:58 PM) jcastro: from the upstreams I've talked to, they're happy to have someone who is willing to learn.
(02:57:12 PM) jcastro: it would suck if you signed up to help a project and ended up just getting in the way
(02:57:28 PM) jcastro: which is why I like to idle in IRC channels and read up on the mailing lists
(02:57:37 PM) jcastro: so I can educate myself when they're doing major changes
(02:57:56 PM) jcastro: I try to pay attention when they want to do a major feature
(02:58:18 PM) jcastro: I am always thinking "if we got that into a PPA and brought in the ubuntu hordes, we could get some great testing done."
(02:58:28 PM) jcastro: and upstreams /love/ when we can provide them with data.
(02:58:42 PM) jcastro: < NMinker> I hate when that happens, when I get in the way
(02:58:46 PM) jcastro: everyone messes up!
(02:59:00 PM) jcastro: it's how you learn and adapt that make it all Just Work(tm) in the end
(02:59:03 PM) jcastro: ok, that's it for me
(02:59:07 PM) jcastro: I hope you learned something!
(02:59:33 PM) jcastro: And I hope you help me provide our upstream projects with the tools they need to make people love their operating system!