| === yofel_ is now known as yofel | ||
| === cjohnston_ is now known as cjohnston | ||
| === bump is now known as Guest17710 | ||
| === yofel_ is now known as yofel | ||
| === linux_guru_mania is now known as linuxgurumaniac | ||
| === yofel_ is now known as yfoel | ||
| === yfoel is now known as yofel | ||
| === binarylooks_ is now known as binarylooks | ||
| === 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: qense || Questions in #ubuntu-classroom-chat | ||
| qense | Hello, I'm Sense Hofstede -- https://launchpad.net/~qense -- and the next hour I'll be telling you a bit about Adopt-an-Upstream. | 17:00 |
|---|---|---|
| qense | Hello, I'm Sense Hofstede -- https://launchpad.net/~qense -- and the next hour I'll be telling you a bit about Adopt-an-Upstream. | 17:00 |
| qense | A notice for those testing Ubuntu Lucid: please don't click links in XChat (GNOME), but copy them to your browser instead; apparently clicking links makes XChat crash. | 17:01 |
| qense | I know from experience! | 17:01 |
| qense | Today's session is about Adopt-an-Upstream. But what is Adopt-an-Upstream? | 17:02 |
| qense | We all know there are different ways of contributing to a distribution. You can cherry pick work items you like, or you can choose to focus on a specific subset of the tasks. | 17:03 |
| qense | Everyone has got a different best approach. However, when you focus on something you like you are more productive. | 17:04 |
| qense | Adopt-an-Upstream is just this: you focus on a project you like and make sure it rocks in Ubuntu! | 17:04 |
| qense | Now, it is quite some work to focus on all facets of a project's existence in Ubuntu -- I'd say you're no longer focusing then, but it depends on the amount of time you're willing to spend on Ubuntu -- so you split it up in different tasks. | 17:07 |
| qense | When you've chosen a project to adopt the next thing you need to do is making up your mind on what you're going to work on. | 17:07 |
| qense | Because adoption of an upstream encompasses the following points: | 17:08 |
| qense | Communication | 17:08 |
| qense | both communicating Ubuntu schedules and announcements of importance to the upstream project to the upstream project, and communicating the project's schedules and announcement to the developers in Ubuntu that should know about it. | 17:09 |
| qense | Bug triaging | 17:09 |
| qense | or Adopt-a-Package | 17:09 |
| qense | You work on triaging -- processing -- the bugs reported against the adopted project. More on this later. | 17:09 |
| qense | Packaging | 17:10 |
| qense | Making sure the latest version of the package is available in Ubuntu, either by merging or syncing it from Debian, or by packaging it yourself. | 17:10 |
| qense | Forwarding patches upstream | 17:10 |
| qense | For some bugs there are fixes available that Ubuntu maintains as patches. It's the best for everyone if those patches are also sent upstream so they can be included in the code. | 17:11 |
| qense | and finally | 17:11 |
| qense | Representing the project in Ubuntu and Ubuntu upstream | 17:12 |
| qense | This means being the contact person of that project in Ubuntu and the Ubuntu contact person upstream. | 17:12 |
| qense | You can also organise a BugDay for the project -- more information about that at the wiki: https://wiki.ubuntu.com/UbuntuBugDay | 17:14 |
| qense | That sure are many things to do! | 17:14 |
| qense | It can happen that someone else is already working on one or more of the tasks I mentioned. | 17:15 |
| qense | In this case it would be best to first talk to that person to make sure you're not going to do duplicate work. And working together is of course much more efficient and productive than working alongside each other! | 17:16 |
| qense | Some people have formed a team for adopting a project. | 17:16 |
| qense | An example of this is the MozillaTeam: https://wiki.ubuntu.com/MozillaTeam | 17:17 |
| qense | Although that team was created before Adopt-an-Upstream was started it is still a very good example for people that actually want to adopt a package. | 17:18 |
| qense | Any questions so far? | 17:18 |
| qense | OK, lets take a closer look at connecting with the upstream. | 17:20 |
| qense | Because that's the most important thing of it all and that's what Adopt-an-UPSTREAM is actually about. | 17:21 |
| qense | First of all, please keep in mind that the upstreams are very important to Ubuntu -- without them we'd barely have anything in the repositories and nothing to run what we would have -- so please try treat them respectfully. | 17:23 |
| qense | Although I'm sure most of you will. :) | 17:23 |
| qense | There are a few actions you can take to make sure you don't miss anything you need to know. | 17:24 |
| qense | First of all, if you're often on IRC, it is strongly advised to join the project's channel as well; this makes it easier for the upstream developers to contact you when they need to ask you something and allows you to quickly ask them your questions. | 17:25 |
| qense | It's also a good idea to subscribe to the project's mailing list, or -- when there are multiple -- to the list that you'll most likely find the discussions on you need/want to follow. | 17:26 |
| qense | Some projects also have mailing lists that are only used for sending release announcements, often with the release notes. | 17:26 |
| qense | This is a valuable source of information and something you should pass on to the affected Ubuntu developers if it is interesting for Ubuntu. | 17:27 |
| qense | If the upstream project chooses to make a radical change you should warn Ubuntu on time. | 17:28 |
| qense | Example given: during the Ubuntu Developer Summit a collaborative text editor called 'Gobby' is used. A release or so ago, before the UDS for Ubuntu Lucid, a new version was released which changed the protocol. | 17:29 |
| qense | In order to make sure that everyone, even those that don't use the latest release of Ubuntu, can participate Ubuntu decided to stick to the old protocol. | 17:30 |
| qense | The new release of Gobby was packaged separately and the previous Gobby release was left in the repositories. | 17:30 |
| qense | This is something upstream adopters should work on. | 17:31 |
| qense | if it affects their project. | 17:31 |
| qense | Of course, when large changes are made in Ubuntu -- like the Application Indicator that were added to Ubuntu Lucid -- it is the task of the adopter to notify upstream and cooperate with them in adding support for it to the project. | 17:32 |
| qense | This could be done by helping an upstream developers by pointing her or him to the right documentation, wiki pages, mailing lists and IRC channels, but also by helping an Ubuntu contributor with writing a patch and making sure that patch gets sent upstream. | 17:33 |
| qense | If you've got a question, please ask! | 17:34 |
| qense | What's also an important task of making sure no data valuable to the upstream project remains locked away in Ubuntu is forwarding bugs upstream. | 17:36 |
| qense | This brings us to our next stop: Adopt-a-Package. | 17:36 |
| qense | This is actually a bit separate from Adopt-an-Upstream because of the amount of work required for keeping the bugs clean and tidy. | 17:37 |
| qense | General information about Adopt-an-Upstream page can be found at https://wiki.ubuntu.com/Upstream/Adopt | 17:38 |
| qense | However, Adopt-a-Package has a wiki page of its own, at https://wiki.ubuntu.com/BugSquad/AdoptPackage | 17:38 |
| qense | As you can see on that page there are already quite a few packages adopted by bug triagers that aren't adopted 'in general'. | 17:39 |
| qense | This is possible as well, and something you should check when you decide to adopt an upstream; if the bugs are already adopted, please profit from this and try to cooperate as much as possible. | 17:40 |
| qense | Just as with Adopt-an-Upstream you can also divide the tasks for adopting the bugs. | 17:40 |
| qense | At https://wiki.ubuntu.com/BugSquad/AdoptionTeam you can see an example of an 'Adoption Team', a group of people working on the bugs of a specific package. | 17:41 |
| qense | When dealing with projects that have many bugs reported against them on Launchpad it's often wise to divide the tasks and let one go through the newly reported bugs, whereas the other is responsible for forwarding bugs upstream. | 17:42 |
| ClassBot | hggdh asked: do I need to be a developer to adopt a package? Or an upstream? How much experience should I have, and in what? | 17:43 |
| qense | Adopting an upstream isn't something you should take lightly. Adopting an upstream means you want to invest time in the project and people will start to see you as the contact person for that project in Ubuntu, and vice-versa upstream. | 17:44 |
| qense | Therefore it's wise to only adopt an upstream after you've gained experience, both with the tasks you want to work on and with the upstream in general. | 17:44 |
| qense | I would strongly suggest to gain some experience with bug triaging before adopting a project's bugs, just as it is wise to learn how to package before taking up the responsibility for packaging a project. | 17:46 |
| qense | Respectively a membership of Ubuntu Bug Control and the Ubuntu MOTU is a big plus when doing those tasks. | 17:46 |
| qense | It is also good to take into account that every project has got its own way. | 17:47 |
| qense | Before you start you should learn how the project works, what its habits are, its customs. | 17:47 |
| qense | To loosely quote the wiki page: "It's easier for an individual to adapt to a group than for a group to adapt to one individual." | 17:48 |
| ClassBot | enli asked: How do you exactly inform an up-steam and send bug fixes? (bug trackers i guess?) If forwarding patches, are there conventions to be followed for the topic title in upsteams bug tracker? | 17:48 |
| qense | enli: Nice question. | 17:49 |
| qense | The conventions differ per project. | 17:49 |
| qense | However, bugs and patches should be reported in the upstream bug tracker indeed. | 17:49 |
| qense | Patches should be attached to the bug report of the issue they're fixing. | 17:50 |
| qense | If the issue the patch is fixing isn't reported yet upstream, just report that bug and say someone provided a fix in Ubuntu and attach that patch. | 17:50 |
| qense | A good place to look for the conventions is the wiki of the upstream project, if they have any. | 17:51 |
| qense | GNOME has got its bug tracker at http://bugzilla.gnome.org/ and its developers wiki at http://live.gnome.org/ | 17:51 |
| qense | When you've gather some information it's a good idea to document it on the Ubuntu wiki. | 17:51 |
| qense | This way you make sure Ubuntu and the upstream project won't suffer too much when you (suddenly) leave -- the so-called "hit by the bus" problem -- and you make it easier for other people to help or even just contribute one patch or bug report upstream. | 17:52 |
| qense | You should add a link to this information at https://wiki.ubuntu.com/Upstream/Workspaces | 17:53 |
| qense | You can find there is already one workspace for Banshee | 17:53 |
| qense | As you can see it uses this template: https://wiki.ubuntu.com/Upstream/AdoptingTemplate | 17:53 |
| qense | Please use that template when creating your project's workspace so readers can quickly find the information they were looking for. | 17:54 |
| qense | You could also add e.g. an item about the conventions for bug titles of forwarded patches here. | 17:54 |
| qense | If you take a look at Banshee's workspace you can see that it includes many information already https://wiki.ubuntu.com/Upstream/Banshee | 17:55 |
| qense | It lists to the main website, the most important mailing list for the adopters -- to which you subscribed, of course! -- the IRC channel and the location of the source code. | 17:56 |
| qense | But it also links to certain pages in Launchpad, like a PPA, bug reports and the status of the package in Debian. | 17:56 |
| qense | This is also what adopting an upstream is about: making information about the project accessible for Ubuntu contributors. | 17:57 |
| qense | And, of course, making information about Ubuntu accessible to the upstream project. | 17:57 |
| qense | With that I would like to end this session. Are there any questions? | 17:57 |
| qense | No? OK, in that case, thank you for attending. If you've got any questions about Adopt-an-Upstream or Adopt-a-Package or if you want to adopt an upstream or a package, please don't hesitate to ping either me or jcastro in #ubuntu-bugs or #ubuntu-devel | 17:59 |
| jcastro | or just send me a mail at jorge@ubuntu.com! | 17:59 |
| * jcastro claps! Good job qense! | 17:59 | |
| * qense bows | 17:59 | |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!