Ubuntu Wiki

   1 [20:00] <tumbleweed> thanks jcastro and DBO
   2 === 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: Getting your fixes into Ubuntu , how to make sponsors happy - Instructors: tumbleweed
   3 [20:01] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html following the conclusion of the session.
   4 [20:01] <tumbleweed> Hi, and welcome everyone.
   5 [20:01] <tumbleweed> I know it's been a long evening (in my timezone),
   6 [20:01] <tumbleweed> let's bring it to a close with something that helps you get things done in Ubuntu.
   7 [20:01] <tumbleweed> Please ask questions in #ubuntu-classroom-chat, I'll answer them regularly, they'll make this discussion much more interesting.
   8 [20:02] <tumbleweed> darkdevil56: yeah, 10pm here
   9 [20:02] <tumbleweed> I'm Stefano Rivera. I live in sunny Cape Town, South Africa, and am an Ubuntu MOTU and Debian Developer.
  10 [20:02] <tumbleweed> My main interests are Python-related packages, and helping people with Ubuntu Development.
  11 [20:02] <tumbleweed> Tonight I'm talking abut the Ubuntu Sponsorship Queue.
  12 [20:03] <tumbleweed> This talk will be less practical examples like dholbach and barry's excellent talks earlier, and more discussion.
  13 [20:03] <tumbleweed> There's simply no way I can cover examples on how to do everything :)
  14 [20:03] <tumbleweed> The sponsorship queue is how you get things uploaded when you don't have upload rights yourself.
  15 [20:03] <tumbleweed> https://wiki.ubuntu.com/SponsorshipProcess
  16 [20:04] <tumbleweed> All new Ubuntu developers use it, it's how we learned and showed our skills, that led to us becoming Ubuntu developers.
  17 [20:04] <tumbleweed> so, what, why?
  18 [20:04] <tumbleweed> Let's say there's a bug in an Ubuntu package you want to fix. You have a patch for it.
  19 [20:04] <tumbleweed> You could file a bug in Launchpad, with the patch, but as I'm sure you've seen, the bug may go without any feedback for a long time...
  20 [20:05] <tumbleweed> Ubuntu has ~100 000 open bugs, and ~2 000 bugs with patches. That's a lot, far too many for us to ever get around to fixing them all.
  21 [20:05] <tumbleweed> So, instead of waiting for someone else to test & integrate your patch, you could do the next step, and prepare the upload for the Ubuntu archive.
  22 [20:05] <tumbleweed> You do this, request sponsorship, and an Ubuntu Developer who has the necessary rights will then come along, review your work, and if it's ready, sign it and upload it to the archive for you.
  23 [20:05] <tumbleweed> This is more work for you, than filing a bug with a patch, but you'll learn more, and eventually can earn yourself Ubuntu upload rights.
  24 [20:06] <tumbleweed> Someone has to prepare every upload, so if you want something desperately, it might as well be you who does the work.
  25 [20:06] <tumbleweed> For example, I'm a MOTU, but before I was, I used the sponsorship queue to do work on universe packages.
  26 [20:06] <tumbleweed> To fix bugs, upload new versions, and do SRUs (updates to stable releases).
  27 [20:06] <tumbleweed> As a MOTU, I can upload to universe, but not to Ubuntu "main" or "restricted" packages.
  28 [20:07] <tumbleweed> For those, I have to go through the sponsorship queue.
  29 [20:07] <tumbleweed> Of course, because I *can* upload to universe, I review universe things on sponsorship queue, and sponsor the uploads.
  30 [20:07] <tumbleweed> I'm not the only one. We have "Patch Pilot"s every day, who sit down for a few hours, reviewing things in the queue
  31 [20:07] <tumbleweed> Now, I can't tell you how to go from every patch out there, to an upload ready for sponsorship, there are just too many possibilities.
  32 [20:07] <tumbleweed> However, if you followed barry's talk earlier, you will have already got as far as posting something into the sponsorship queue.
  33 [20:08] <tumbleweed> http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html#t18:22
  34 [20:08] <tumbleweed> Beyond that, you need to read up more generally about Debian packaging:
  35 [20:08] <tumbleweed> https://wiki.ubuntu.com/PackagingGuide http://www.debian.org/doc/maint-guide/
  36 [20:08] <tumbleweed> And our sponsors are awesome. When they review your work, you'll get good feedback, that should improve your knowledge and abilities.
  37 [20:09] <tumbleweed> When you propose a bzr merge against an Ubuntu branch, it'll be picked up by the sponsorship queue.
  38 [20:09] <tumbleweed> http://reports.qa.ubuntu.com/reports/sponsoring/index.html (this page is generated every half hour or so)
  39 [20:09] <tumbleweed> You can see a few I proposed earlier today (near the bottom), two samba SRUs: ntlm-auth-623342.
  40 [20:10] <tumbleweed> There's another way to get things into the queue, if you attach a "debdiff" patch to a bug, and subscribe "ubuntu-sponsors" to the bug.
  41 [20:10] <tumbleweed> You create a debdiff by running the "debdiff" command from devscripts on two source packages (.dsc files). debdiff will give you the diff between them.
  42 [20:10] <tumbleweed> It's up to you which approach you find more comfortable.
  43 [20:10] <tumbleweed> I find UDD (bzr) more flexible, e.g. it handles new upstream versions quite well, but not all developers prefer it.
  44 [20:10] <tumbleweed> When you are doing merging, for example, it can be quite confusing to read the diffs, in UDD.
  45 [20:11] <tumbleweed> ok, that's a broad overview of the sponsors, what we do, and how
  46 [20:11] <tumbleweed> (any questions?)
  47 [20:12] <tumbleweed> right, let's go on to the meat of this, how to make sponsors happy:
  48 [20:12] <tumbleweed> I'm just going to list some stuff here, I hope to get some decent questions on them:
  49 [20:12] <tumbleweed> * Read the debdiff / bzr diff that you propose
  50 [20:12] <tumbleweed>   - The sponsor is going to be reading it, so you should as well. You might find mistakes you made.
  51 [20:13] <tumbleweed>   - Does the changelog entry accurately describe the changes?
  52 [20:13] <tumbleweed>      + There's a mailing list, natty-changes, where the changelog entries of all natty uploads get mailed (same for other releases)
  53 [20:14] <tumbleweed> people read these, wanting to understand how things are changing
  54 [20:14] <tumbleweed> the changelog is the how you communicate what you've done
  55 [20:14] <tumbleweed> it also helps future mergers to understand what's necessary, and what isn't
  56 [20:14] <tumbleweed>     + "Fixed FTBFS" is a poor description, rather say "explicitly linked to libfoo to fix FTBFS with ld --as-needed"
  57 [20:15] <tumbleweed> * Was your fix the right fix?
  58 [20:15] <tumbleweed>   - Does it work, and fix the issue?
  59 [20:16] <tumbleweed>   - Does it belong in Ubuntu, or in Debian, or upstream?
  60 [20:16] <tumbleweed>     (of course, the debian session is tommorrow night)
  61 [20:16] <tumbleweed>   - Is it minimal? We try to change as little as possible in Ubuntu, the closer it is to Debian, the less work we have to do.
  62 [20:16] <tumbleweed> that's something that's worth going into:
  63 [20:17] <tumbleweed> Whenever we make a change in Ubuntu, we have to carry it until we can pass it upstream
  64 [20:17] <tumbleweed> The majority of our packages, we import directly from Debian, with no changes
  65 [20:17] <tumbleweed> these happen automatically
  66 [20:17] <tumbleweed> however, when we have changes, whenever we want a new version from Debian, we have to manually re-add the changes to the new version
  67 [20:18] <tumbleweed> this is Merging https://wiki.ubuntu.com/UbuntuDevelopment/Merging
  68 [20:19] <tumbleweed> so, if a package is currently unmodified in Ubuntu, it may be a bad idea to change it, just to correct a spelling mistake like barry did earlier
  69 [20:19] <tumbleweed> we should rather report the spelling mistake to the upstream, and we'll get the benefit of the fix, without extra effort, when the upstram releases a new version
  70 [20:19] <barry> tumbleweed: there are ways to do it.  i did not have time to talk about how to integrate udd with patch systems, but that's laid out in the wiki pages
  71 [20:19] <barry> tumbleweed: yes, that's always ideal
  72 [20:20] <tumbleweed> barry: thanks :)
  73 [20:20] <barry> :)
  74 [20:20] <tumbleweed> chadadavis: Yes, it probably will be accepted upstream easily
  75 [20:21] <tumbleweed> chadadavis: but if it's not a major issue, why waste development time on it in Ubuntu, and Debian, and upstream
  76 [20:21] <tumbleweed> why not just get it straight upstream
  77 [20:21] <tumbleweed> (err, that qustion was)
  78 [20:21] <tumbleweed> 22:20 < chadadavis> But if the change is so trivial, wouldn't it also be more likely to be accepted upstream? How  is the review process in that direction. Can any of that be 'seen' from Launchpad?
  79 === palhmbs is now known as palhmbs_
  80 [20:21] <tumbleweed> So, yes Debian developers can chose to see the changes Ubuntu makes
  81 [20:22] <tumbleweed> some do, some don't
  82 [20:22] <tumbleweed> in general, if you want to get their attention, you should file a bug in Debian, with a patch
  83 [20:22] <tumbleweed> upstreams can also chose to follow their bugs in Ubuntu, by subscribing to their package
  84 [20:23] <tumbleweed> but some packages have thousands of bugs filed against them in Ubuntu, and nobody can sift through them easily
  85 [20:24] <tumbleweed> 22:23 < chadadavis> But bugs against ubuntu stay in Launchpad until they are fixed upstream then? Assuming one  would prefer to fix a certain bug upstream than make the change in Ubuntu?
  86 [20:24] <tumbleweed> correct. And maybe nobody will notice and close the bug. That happens a lot. Ubuntu has too many bugs for them to be kept well up to date
  87 [20:24] <ClassBot> 36DAA71NS asked: The problem sometimes is that a bug discovered in ubuntu leads to an orphaned upstream package. Therefore the fix in Ubuntu seems to be easier although it's more expensive on the long run. Right?
  88 [20:25] <tumbleweed> I don't know if bugs in Ubuntu *lead* to packages being orphaned upstream, but yes, we certainly have packages in Ubuntu that no upstream cares about any more
  89 [20:25] <tumbleweed> and yes, in that case, fixing it in Ubuntu is the only option
  90 [20:26] <tumbleweed> when I said "Does it belong in Ubuntu, or in Debian, or upstream?", that requires some context to judge it
  91 [20:26] <tumbleweed> if you feel unsure, ask in #ubuntu-motu, there are almost alwysa people around who'll help
  92 [20:27] <tumbleweed> < 36DAA71NS> The problem seems that there's no easy way to get the bugs fixed upstream
  93 [20:27] <tumbleweed> that's unfortunatly true in many places
  94 [20:27] <tumbleweed> however there are also upstreams who merge patches I send them within the hour
  95 [20:28] <tumbleweed> Ubuntu is big, we have a bit of everything :)
  96 [20:28] <tumbleweed> continuing with my recommendations, if there are no more questions:
  97 [20:28] <tumbleweed> * Test your fix:
  98 [20:28] <tumbleweed>   - Test-build it in pbuilder / sbuild / a PPA
  99 [20:29] <tumbleweed>   - read what lintian has to say. Many packages arrive from Debian, with loud lintian warnings. Don't worry about that, worry about new ones that you are responsible for.
 100 [20:29] <tumbleweed>   - Does it install / upgrade correctly (if you touched maintainer scripts)
 101 [20:29] <tumbleweed> these are pretty common sense, but we all slip up :)
 102 [20:29] <tumbleweed> * Should the bug / patch be forwarded to Debian?
 103 [20:30] <tumbleweed>   - If you do this, link the Debian bug back to the launchpad bug (also affects project), that way the sponsor knows you did your homework.
 104 [20:30] <tumbleweed> it's not just to say you did your homework, it'll help future mergers (quite possibly you) to remember
 105 [20:31] <tumbleweed> ok, I've run out of pre-typed recommendations, and am hoping for some more questions
 106 [20:32] <tumbleweed> other things I can suggest for people wanting to get into ubuntu devolpment:
 107 [20:32] <tumbleweed> - take a look at how other people are solving problems. Read natty-changes or install apt-listchanges
 108 [20:33] <tumbleweed> < 36DAA71NS> So basically a good way is to find the corresponging bugtracker to see whether the upstream project is alive or not
 109 [20:33] <tumbleweed> most upstreams are alive
 110 [20:34] <tumbleweed> and many bugs that we fix day to day are about taking patches from upstream bugtrackers and pulling them into Ubuntu
 111 [20:34] <tumbleweed> or fixing bugs in our packaging
 112 [20:34] <tumbleweed> these things obviously don't involve any fowarding upstream (although possibly to Debian, for packaging issues)
 113 [20:34] <tumbleweed> < 36DAA71NS> after that contact MOTUs via IRC and proceed afterwards?
 114 [20:35] <tumbleweed> Yeah #ubuntu-motu is very friendly to beginner ubuntu contributors. I waste way too many evenings there :)
 115 [20:35] <tumbleweed> < chadadavis> Does Launchpad's tracker for a package generally link to the corresponding upstream tracker? I.e. does Launchpad have a facility like that built in?
 116 [20:36] <tumbleweed> yes it does. Most small packages aren't linked to an upstream tracker (this requires registering a launchpad project in th ename of the upstraem package)
 117 [20:36] <tumbleweed> but most big ones are
 118 [20:36] <tumbleweed> of course Rhonda will be covering a fair portion of this in her talk tomorrow night, on getting things into Debian
 119 [20:38] <tumbleweed> anything else? or are we all falling asleep :)
 120 [20:38] <tumbleweed> < chadadavis> General newbie question: would you recommend browsing bugs across all packages (i.e. the most critical/newest) to get a feel for all of ubuntu, or do newbies contribute more by becoming more familiar with the innards of just a few packages?
 121 [20:38] <tumbleweed> I'll be honest, I don't browse new bugs on launchpad very much
 122 [20:39] <tumbleweed> there are pretty awesome people out there who do that, and triage them
 123 [20:39] <tumbleweed> I'm subscribed to the bugs of packages I care about, and I try to deal with all of them
 124 [20:39] <tumbleweed> (this does mean my bug inbox gets pretty full when I've been busy with other things)
 125 [20:40] <tumbleweed> but there's a new site out there to help you find things to fix in Ubuntu (I'm suprised I didn't see dholbach mention it yet)
 126 [20:40] <tumbleweed> http://harvest.ubuntu.com/
 127 [20:41] <tumbleweed> that tries to pick out th einteresting things from launchpad, that are ready to deal with
 128 [20:41] <tumbleweed> < Endanwender> What is with bug-fixes submitted in Debian? How long it need to find the way in Ubuntu?
 129 [20:41] <tumbleweed> So, Ubuntu releases once every 6 months
 130 [20:42] <tumbleweed> from about a week after the release, until Debian Import Freeze, we automatically pull new versions of packages from Debian into Ubuntu
 131 [20:43] <tumbleweed> Debian Import Freeze was around new year, in natty http://wiki.ubuntu.com/NattyReleaseSchedule
 132 [20:43] <tumbleweed> during that time, any uploads to debian get pulled over pretty quickly (assuming we haven't deviated from Debian)
 133 [20:44] <tumbleweed> how long between submitting a bug fix to debian and, and the debian maintainer of th epackage uploading th efix, well that varies
 134 [20:44] <tumbleweed> debian is like any other upsteram in that respect
 135 [20:44] <tumbleweed> some debian packages are small, actively maintained and have 0 bugs, others are fighting under the deluge of hundreds of bugs. And there's a lot inbetween.
 136 [20:46] <tumbleweed> anything else?
 137 [20:50] <ClassBot> Endanwender asked: Have I understood the correctly? Between the release cycles of Ubuntu and Debian no further exchange between bug-fixes and so on takes place?
 138 [20:50] <tumbleweed> Endanwender: so, there are Debian Developers who take active care of their packages in Ubuntu
 139 [20:50] <ClassBot> There are 10 minutes remaining in the current session.
 140 [20:50] <tumbleweed> you could say I'm one of them
 141 [20:51] <tumbleweed> if I see a serious bug reported in Debian, I'll make sure the fix gets into Ubuntu soon
 142 [20:51] <tumbleweed> and if I see a bug reported in Ubuntu, I'll fix it in Debian, and sync it across to Ubuntu
 143 [20:51] <tumbleweed> but there are no formal bug exchanges
 144 [20:52] <tumbleweed> if you want to forward a bug from Ubuntu to Debian or vice-versa, you need to do it manually
 145 [20:52] <tumbleweed> (we have tools to automate this in ubuntu-dev-tools)
 146 [20:52] <tumbleweed> and Rhonda in sure to go into deal on it tomorrow night
 147 [20:52] <tumbleweed> detail
 148 [20:53] <tumbleweed> the reason for this is that not all Ubuntu bug reports are of interest, or even relevant to Upstream / Debian
 149 [20:53] <tumbleweed> the upstreams need to decide for themselves, if they want to spend the time reading and understanding them.
 150 [20:55] <ClassBot> There are 5 minutes remaining in the current session.
 151 [20:57] <ClassBot> Endanwender asked: Ah ok. Thx for the info. I'm a little bit surprised about this. I thought both distrubution have a direct exchange concerning this.
 152 [20:57] <tumbleweed> Endanwender: we keep things that can't be automated perfectly manual
 153 [20:58] <tumbleweed> but you'll find most Ubuntu developers should know thier way around th Debian and Redhat bugtrackers, quite well
 154 === 36DAA71NS is now known as hugohirsch
 155 [20:59]  * tumbleweed guesses that's that
 156 [20:59] <tumbleweed> thanks for listening everyone, hope you enjoyed th efirst day of Ubuntu Developer Week, and will be back for more, tomorrow
 157 [20:59] <tumbleweed> good night :)
 158 [21:00] <ClassBot> Logs for this session will be available at http://irclogs.ubuntu.com/2011/02/28/%23ubuntu-classroom.html