Dev Week -- Introduction to Ubuntu development -- dholbach -- Tue, Aug 28th, 2012

   1 [15:00] <dholbach>  H E L L O   M Y   F R I E N D S !
   2 [15:00] <obounaim> Hi
   3 [15:00] <dholbach> Welcome to another Ubuntu Developer Week!
   4 [15:00] <exodus> dholbach, o/
   5 [15:00] <sukyjary> hi
   6 [15:00] <conner_bw> Thanks nohtype!
   7 [15:00] <bilal> wait, isn't it moderated?
   8 [15:00] <conner_bw> Was just about to ask.
   9 [15:00] <roadmr> \o/
  10 === 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: Introduction to Ubuntu development - Instructors: dholbach
  11 [15:00] <dholbach> Here we go!
  12 [15:01] <dholbach> Before we start off, here just a few pointers which should generally help you through the event.
  13 [15:01] <dholbach> First of all: make sure you also join #ubuntu-classroom-chat
  14 [15:01] <dholbach> #ubuntu-classroom is just for the session itself, all the chat, discussion and questions happen in #ubuntu-classroom-chat
  15 [15:01] <dholbach> if you have a question you want to be answered in the session, please prefix it with QUESTION:
  16 [15:02] <dholbach> ie, QUESTION: Can you recommend any good music for a late-night hacking session?
  17 [15:02] <dholbach> also have a look at https://wiki.ubuntu.com/UbuntuDeveloperWeek because all the session information is on there
  18 [15:02] <dholbach> Two questions which come up frequently are: will there be logs?
  19 [15:03] <dholbach> yes, we will also put them up on https://wiki.ubuntu.com/UbuntuDeveloperWeek/
  20 [15:03] <dholbach> and the second one is "how can I ignore all the joins/parts of people?"
  21 [15:03] <dholbach> you can do that by typing "/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS" into the channel window
  22 [15:03] <dholbach> without the " obviously
  23 [15:04] <dholbach> some IRC clients might not support this though
  24 [15:04] <dholbach> alright - that's everything organisational from me for now
  25 [15:04] <dholbach> Let's start the first session!
  26 === zen is now known as Guest54747
  27 [15:04] <dholbach> My name is Daniel Holbach, I've been working on Ubuntu for almost all of its life and always loved our Developer community
  28 [15:05] <dholbach> for a years I've been working for Canonical now, first working on the Desktop, then moving on to work with our Developer community
  29 === prashanthsunder9 is now known as prashanth
  30 [15:05] <dholbach> in this first session I want to give you an overview over how Ubuntu development generally works
  31 [15:06] <dholbach> there are lots of people, lots of moving parts and it can all seem very confusing, but it's actually fine and quite easy to learn :)
  32 [15:06] <dholbach> in this first session I just want to give you a broad overview, so you at least heard all the most important things once
  33 [15:06] <dholbach> and to answer as many questions as we possibly can :)
  34 [15:07] <dholbach> If I'm too fast or don't make sense, please speak up. :)
  35 [15:07] <dholbach> Ubuntu is made up of thousands of different components, written in many different programming languages. Every component - be it a software library, a tool or a graphical application - is available as a source package.
  36 [15:07] <dholbach> Source packages in most cases consist of two parts: the actual source code and metadata. Metadata includes the dependencies of the package, copyright and licensing information, and instructions on how to build the package.
  37 [15:08] <dholbach> Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install.
  38 [15:08] <dholbach> Every time a new version of an application is released, or when someone makes a change to the source code that goes into Ubuntu, the source package must be uploaded to Launchpad’s build machines to be compiled.
  39 [15:09] <dholbach> The resulting binary packages then are distributed to the archive and its mirrors in different countries. The URLs in /etc/apt/sources.list point to an archive or mirror.
  40 [15:09] <dholbach> very day CD images are built for a selection of different Ubuntu flavours. Ubuntu Desktop, Ubuntu Server, Kubuntu and others specify a list of required packages that get on the CD. These CD images are then used for installation tests and provide the feedback for further release planning.
  41 [15:11] <dholbach> Also should I note that in the last 2-3 cycles we have been putting together a huge QA lab where tests on all kinds of packages are run, which obviously also help with the release planning. :)
  42 [15:11] <dholbach> Ubuntu’s development is very much dependent on the current stage of the release cycle.
  43 [15:11] <dholbach> We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates.
  44 [15:11] <dholbach> With every freeze date that is reached developers are expected to make fewer, less intrusive changes.
  45 [15:12] <dholbach> If you have a look at https://wiki.ubuntu.com/QuantalQuetzal/ReleaseSchedule you can see the release schedule for the current 12.10 release.
  46 [15:12] <dholbach> You can see that we just went past Feature Freeze.
  47 [15:12] <dholbach> Feature Freeze is the first big freeze date after the first half of the cycle has passed. At this stage features must be largely implemented.
  48 [15:12] <dholbach> The rest of the cycle is supposed to be focused on fixing bugs.
  49 === jeff_ is now known as Guest22207
  50 [15:13] <dholbach> After that the user interface, then the documentation, the kernel, etc. are frozen, then the beta release is put out which receives a lot of testing because many deem it stable enough to play around with it.
  51 [15:13] <dholbach> From the beta release onwards, only critical bugs get fixed and a release candidate release is made and if it does not contain any serious problems, it becomes the final release.
  52 [15:13] <dholbach> Any questions so far?
  53 [15:13] <dholbach> Come on, don't be shy. :)
  54 [15:14] <ClassBot> marcos asked: QA in this context is Question and Answer?
  55 [15:15] <dholbach> marcos, sorry, I could have made it clearer - no, QA in the sentence above meant "Quality Assurance"
  56 [15:15] <dholbach> everything that goes from pro-active testing (test suites run automatically and manual testing) to work on bug reports, testing CD images, etc.
  57 [15:16] <dholbach> QA is what makes Ubuntu not good, but great :)
  58 [15:16] <ClassBot> conner_bw asked: What is the criteria for " it does not contain any serious problems"
  59 [15:17] <dholbach> conner_bw, that's not always a clear-cut decision, but data-loss, critical program crashes and things like that certainly count as show-stoppers
  60 [15:17] <ClassBot> agmenor_ asked: As an app developer, which version should  I be running ? When ?
  61 [15:17] <dholbach> ClassBot, as an app developer it might be good enough to run the latest stable, which is 12.04, but as somebody who works on Ubuntu itself, it's necessary to run 12.10 - and if only in a virtual machine
  62 [15:18] <dholbach> you need to be able to test the changes you want to introduce into Ubuntu in a live environment
  63 [15:18] <ClassBot> paulo_gomes asked: say an application releases a new version of its software after the freeze in ubuntu do we have to wait for the next release?
  64 [15:18] <dholbach> ClassBot, that depends - if it's early in the cycle it can go in without problems - if it's a bug fix release you can still get it in after the freeze
  65 [15:18] <dholbach> but the later in the cycle, the harder it will be to get it past the release team
  66 [15:19] <dholbach> but for a good reason: we need to have time to test things
  67 [15:19] <dholbach> (I'll talk more about this later on.)
  68 [15:19] <ClassBot> conner_bw asked: What is the criteria for " it does not contain any serious problems", like i'm using 12.04 and am subscribed to a few bugs which were clearly released anyway (Libre Office Launcher Integration, for example)
  69 === nick is now known as Guest24273
  70 [15:20] <dholbach> conner_bw, sometimes a decision must be made to keep the release rolling out on the right day - it's not always easy
  71 [15:20] <ClassBot> Liverpudlian asked: Is developing apps different when it comes to LTS versions?
  72 === arvislacis is now known as Guest35542
  73 [15:21] <dholbach> Liverpudlian, LTS versions are of course interesting because many decide to stay on that particular version. So there is more interest of app authors to get their app on the LTS.
  74 [15:21] <ClassBot> obounaim asked: What is the URL of QA?
  75 [15:21] <dholbach> obounaim, https://wiki.ubuntu.com/QATeam/ might work as a good introduction into everything the team does.
  76 [15:21] <ClassBot> dsp__ asked: how to stop all these logs, i just wanna see your chat msgs.... its confusing
  77 [15:22] <dholbach> dsp__, type "/ignore #ubuntu-classroom CRAP NOTICES SNOTES CTCPS JOINS PARTS QUITS KICKS MODES WALLOPS NICKS DCC DCCMSGS CLIENTNOTICES CLIENTCRAP CLIENTERRORS HILIGHTS" into the chat window, but without the "
  78 [15:22] <ClassBot> C1sM0 asked: Are .deb files created automatically once the source code has been send up?
  79 [15:23] <dholbach> C1sM0, yes, they land in the queue because we don't have an infinite amount of build machines, but if the queue is largely empty you can expect your package to be built and ready in the archive within an hour
  80 [15:23] <ClassBot> nja asked: ​ Why does the Work Item Iteration on the Quantal Release Schedule show A-2 at the top instead of A-1?
  81 [15:24] <dholbach> nja, I assume you are talking about http://status.ubuntu.com/ubuntu-quantal/? I'm not quite sure about this to be honest.
  82 [15:24] <dholbach> Maybe because Alpha 2 was the last milestone?
  83 [15:24] <dholbach> Sorry, don't know.
  84 [15:24] <ClassBot> marcos asked: App Showdown accept closed source and pay applications too?
  85 [15:24] <dholbach> marcos, not as far as I know, no
  86 === piro is now known as Guest22304
  87 [15:25] <dholbach> maybe we can try to direct our focus away from apps for a little bit - in this session I will try to talk a bit more about the development of Ubuntu itself - although large parts apply for app development and packaging as well
  88 [15:25] <ClassBot> _et asked: Builds done using which C-I tool?
  89 [15:25] <dholbach> _et, I don't know C-I tool - all our packages are built on Launchpad, which is an Open Source platform built with Zope and Python - the build process itself uses sbuild
  90 [15:26] <ClassBot> ziviani asked: who defines the requirements for each GA release? what if some features are no able to be developed until the freezing date?
  91 [15:26] <dholbach> ziviani, if features can't get done in the cycle, they are dropped and left for next cycle to be implemented.
  92 [15:26] <dholbach> The decision is made by the release team and the respective team leads.
  93 [15:26] <ClassBot> nja asked: ​ Why does Lernid have a "Terminal" tab?
  94 [15:27] <dholbach> nja, when we get to a live demo part you can try out what the presenter is saying live on your system
  95 [15:27] <ClassBot> smartboyhw asked: Then what about software packaging?
  96 [15:28] <dholbach> smartboyhw, I'm not quite sure I understand your question. Ubuntu Development is a lot about Software Packaging and its integration with each other. Maybe you can ask another question?
  97 [15:28] <ClassBot> marcos asked: Update releases (like 12.04.1) accept new features?
  98 [15:28] <dholbach> marcos, no, it will largely "just" include security and stability fixes, updated translations and the like
  99 [15:29] <dholbach> it's just impossible to direct your attention to developing two releases (12.04 and 12.10 for example) at the same time
 100 [15:29] <ClassBot> Henrich asked: how many buildds are there? can we see the list?
 101 [15:29] <dholbach> Henrich, yes - it's available here: https://launchpad.net/builders/
 102 [15:30] <dholbach> Alright - that was a true avalanche of questions - thanks everyone! :)
 103 [15:30] <dholbach> My fingers are aching, but not bleeding yet, so let's keep going.
 104 [15:30] <dholbach> Thousands of source packages, billions of lines of code, hundreds of contributors require a lot of communication and planning to maintain high standards of quality.
 105 [15:30] <dholbach> At the beginning of each release cycle we have the Ubuntu Developer Summit where developers and contributors come together to plan the features of the next releases.
 106 [15:31] <dholbach> Every feature is discussed by its stakeholders and a specification is written that contains detailed information about its assumptions, implementation, the necessary changes in other places, how to test it and so on.
 107 [15:31] <dholbach> This is all done in an open and transparent fashion, so even if you can not attend the event in person, you can participate remotely and listen to a streamcast, chat with attendants and subscribe to changes of specifications, so you are always up to date.
 108 [15:31] <dholbach> As you can see on https://uds.ubuntu.com/ the next UDS is going to be in Copenhagen - if you're there, make sure you drop by.
 109 [15:32] <dholbach> Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects.
 110 === Zubozrout is now known as zubozrout
 111 [15:32] <dholbach> That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise.
 112 [15:32] <dholbach> For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public.
 113 [15:33] <dholbach> Another important tool regarding communication is bug reports. Whenever a defect is found in a package or piece of infrastructure, a bug report is filed in Launchpad.
 114 [15:33] <dholbach> All information is collected in that report and its importance, status and assignee updated when necessary. This makes it an effective tool to stay on top of bugs in a package or project and organise the workload.
 115 [15:33] <dholbach> Most of the software available through Ubuntu is not written by Ubuntu developers themselves. Most of it is written by developers of other Open Source projects and then integrated into Ubuntu.
 116 [15:33] <dholbach> These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “just” integrate it.
 117 [15:34] <dholbach> The relationship to Upstreams is critically important to Ubuntu. It is not just code that Ubuntu gets from Upstreams, but it is also that Upstreams get users, bug reports and patches from Ubuntu (and other distributions).
 118 [15:34] <dholbach> The most important Upstream for Ubuntu is Debian. Debian is the distribution that Ubuntu is based on and many of the design decisions regarding the packaging infrastructure are made there.
 119 [15:34] <dholbach> Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. In Ubuntu there are teams that have an interest in a subset of packages too, and naturally every developer has a special area of expertise, but participation (and upload rights) generally is open to everyone who demonstrates ability and willingness.
 120 [15:34] <ClassBot> average_drifter asked: I just forked someone's repo of HTOP 1.0.1 from  github, and made a patch, the person merged my patch. how can make sure that this patch gets into the Ubuntu repository together with all the stuff he added ? (he added support for thread monitoring). I'm sure a lot of people know what HTOP is.. it's a pretty good utilitary for monitoring processes(kind of like top)
 121 [15:35] <dholbach> average_drifter, Great. Just what I wanted to talk about next. :)
 122 [15:35] <ClassBot> NickE asked: Does Launchpad host everything to do with a given project (unless it is upstream)?
 123 [15:36] <dholbach> NickE, if you decide to use Launchpad to host your project, you can put all the code branches, the bug reports, translations, the specifications, the releases and support tracker into Launchpad
 124 [15:36] <dholbach> and if a project decides to not use Launchpad, you can easily set up a code mirror
 125 [15:36] <dholbach> and daily builds and the like
 126 [15:36] <ClassBot> raju asked: Whats the ground work have to do , to join in a current running project as  one of its the developer ?
 127 [15:37] <dholbach> raju, I would always recommend to have a look out (and ask for) some simple bugs you can start working on.
 128 [15:37] <dholbach> Luckily this week we'll have a session about fixing small bugs in Ubuntu and what to do about them.
 129 [15:37] <dholbach> Tomorrow, 17:00 UTC.
 130 [15:38] <dholbach> Alright, since there's so much interest in fixing bugs and getting stuff into Ubuntu, let's talk a bit about it.
 131 [15:38] <dholbach> Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. It is not only about learning something new and exciting, but also about sharing the solution and solving a problem for millions of users out there.
 132 [15:38] <dholbach> Open Source Development happens in a distributed world with different goals and different areas of focus.
 133 [15:38] <dholbach> For example there might be the case that a particular Upstream is interested in working on a new big feature while Ubuntu, because of the tight release schedule, is interested in shipping a solid version with just an additional bug fix.
 134 [15:39] <dholbach> hat is why we make use of “Distributed Development”, where code is being worked on in various branches that are merged with each other after code reviews and sufficient discussion.
 135 [15:39] <dholbach> In the example I just mentioned it would make sense to ship Ubuntu with the existing version of the project, add the bugfix, get it into Upstream for their next release and ship that (if suitable) in the next Ubuntu release. It would be the best possible compromise and a situation where everybody wins.
 136 [15:40] <dholbach> More specifically: To fix a bug in Ubuntu, you would first get the source code for the package, then work on the fix, document it so it is easy to understand for other developers and users, then build the package to test it.
 137 [15:40] <dholbach> After you have tested it, you can easily propose the change to be included in the current Ubuntu development release. A developer with upload rights will review it for you and then get it integrated into Ubuntu.
 138 [15:41] <dholbach> If that makes you curious, that's great - I'll give you some links to docs later on. The mechanics of fixing a bug are always the same and you learn the tools pretty quickly. It's sometimes just that you have a particularly tricky bug in front of you. But there's always people who can help you out. :)
 139 [15:41] <ClassBot> raju asked: Sorry if its sounds like silly doubt but i want to ask it . how a starting user can estimate the Bug strength as simple one or complex one ?
 140 [15:42] <dholbach> raju, it's sometimes not easy to estimate. It's quite common to think "hah, this one is going to be easy" and then you spend hours on fixing it.
 141 [15:42] <dholbach> It happens to me all the time. :)
 142 [15:42] <dholbach> The good thing is though that we picked a bunch of easy to fix tasks, which Stefano will talk about in his session tomorrow
 143 [15:42] <dholbach> and which are mentioned in the docs I'll point out later on
 144 [15:43] <dholbach> When trying to find a solution it is usually a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort.
 145 [15:43] <ClassBot> prashanth asked: Where do you usually get the source code?
 146 [15:44] <dholbach> prashanth: it's all in Launchpad - a quick "apt-get source <package>" or "bzr branch ubuntu:<package>" will get the source for you - but more on that specifically later on :)
 147 [15:44] <dholbach> When fixing bugs additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream.
 148 [15:44] <dholbach> The most important requirements for success in Ubuntu development are: having a knack for “making things work again,” not being afraid to read documentation and ask questions, being a team player and enjoying some detective work.
 149 [15:45] <dholbach> More questions? :)
 150 [15:45] <ClassBot> prashanth asked: where can we get a list of Upstreams?
 151 [15:46] <dholbach> prashanth: Good question.  To get a page with all info about a package in Ubuntu, you can for example go to https://launchpad.net/ubuntu/+source/gedit
 152 [15:47] <dholbach> If you go to https://launchpad.net/gedit though (note the missing "ubuntu/+source"), you get the information about Upstream
 153 [15:47] <ClassBot> geekette86 asked: i wanna know more about  apport-retrace
 154 [15:48] <dholbach> apport-retrace is a very nice tool - what it does for us is that if a program crashes and it saves a core dump with the current state of the program's used memory, apport-retrace can get us a human-readable output of the crash stacktrace, so the functions which were called in which part of the code, which line, which variables and so on
 155 [15:49] <dholbach> https://wiki.ubuntu.com/DebuggingProgramCrash has more info about this generally
 156 [15:49] <ClassBot> Henrich asked: If you find same problem in upstream (e.g. Debian), do you report it to upstream bug tracker? if not, why?
 157 [15:49] <dholbach> Henrich, yes, you do that if you can be reasonably sure that the problem happens there as well and not because Ubuntu has a modified version of it
 158 [15:49] <ClassBot> neoteric asked: If source can be mirrored into Launchpad would it then be possible that someone fixes a bug in the LaunchPad version that is not fixed in an Upstream package?  If so, what then?
 159 [15:50] <dholbach> neoteric, Unfortunately Launchpad can't push code to the Upstream project, so we need to forward patches 'manually'.
 160 [15:50] <ClassBot> raju asked: please explain more about this " a good idea to check with Upstream and see if the problem (or a possible solution) is known already and, if not, do your best to make the solution a concerted effort"
 161 [15:50] <ClassBot> There are 10 minutes remaining in the current session.
 162 [15:50] <dholbach> Ok, let's say you find a problem in gedit. It crashes for some reason.
 163 [15:51] <dholbach> First you might want to check if there's a new release available which fixes the issue, if not you could try to check the upstream commits if a recent change fixed the issue.
 164 [15:51] <dholbach> If that's not the case, you could have a look at upstream's bug tracker and see if somebody reported the issue already and if a fix is in progress.
 165 [15:51] <dholbach> In that case you can then help out to test the fix and give valuable feedback.
 166 [15:52] <dholbach> If the problem is not know, you'd report it with all the relevant info you have and try to help out as best as you can.
 167 [15:52] <ClassBot> eklok asked: whats the difference between the package management and how windows does it? i never got that right. And why would it be better to wrap stuff up in packages
 168 [15:53] <dholbach> The good thing with package management in a distro is that we have control over what gets in. If something is unstable we don't have to put it in or we can roll back to an old version. Also can we more easily integrate things with each other because we have all the source code.
 169 [15:53] <dholbach> On top of that we can more easily find security issues by scanning the entire archive or rebuilding all packages with new security features, etc.
 170 [15:53] <dholbach> Also is it easier for our users. They get all their updates from one place and don't have to update 64325823 programs individually.
 171 [15:53] <dholbach> If you ask me, it's best thing since sliced bread.
 172 [15:54] <ClassBot> ziviani asked: What are the next Ubuntu goals? Based on the huge efforts with Unity for a better user experience I believe Ubuntu is more focused in UX right now. Is it the focused area where developers could give the special attention?
 173 [15:55] <dholbach> A lot of attention indeed goes into UX, but there are many other teams, who for instance work on the server or make sure that everything works on all kinds of devices, etc. https://wiki.ubuntu.com/Teams might help you find something you're interested in.
 174 [15:55] <ClassBot> exodus asked: Daniel, have you and the Ubuntu Developers Team thought about doing a session in Google Hangout or a similar type of streaming?
 175 [15:55] <ClassBot> There are 5 minutes remaining in the current session.
 176 [15:55] <dholbach> exodus, yes - we've done a few of them and I plan to put on a few sessions soon again. If you follow @ubuntudev on Twitter, Identi.ca, Google+ or Facebook you should get a note. :)
 177 [15:56] <ClassBot> nja asked: Why are you not streaming this in a G+ hangout?
 178 [15:56] <dholbach> In the next session there will be more instructions which you can easily copy/paste from IRC, but not from a Google+ Hangout. Maybe in the future we'll have more video casts.
 179 [15:56] <dholbach> Another point of interest might be people who are at work and can't watch videos, but can easily read up an IRC logs.
 180 [15:56] <dholbach> Also an IRC log is searchable.
 181 [15:57] <dholbach> That said, I know that videos can be a bit more inviting and more personal than a text-based session.
 182 [15:57] <ClassBot> luisalvarado asked: what tools do you recommend to start working on a bug fix?
 183 [15:57] <dholbach> luisalvarado, more on that in the next session and Stefano's session tomorrow.
 184 [15:58] <dholbach> Let's take 3 minutes break so we can all get another glass of water, a cup of tea or something else.
 185 [15:58] <dholbach> Thanks everyone and see you in 3. :)

MeetingLogs/devweek1208/IntroductionUbuntuDev (last edited 2012-08-29 10:27:12 by dholbach)