=== Resistance is now known as EvilResistance === bulldog98_ is now known as bulldog98 === jbicha1 is now known as jbicha === Effenberg0x0 is now known as EffenbergTroll === EffenbergTroll is now known as I === I is now known as Effenberg0x0 === Effenberg0x0 is now known as Trollenberg [02:29] Tr0113n63rg !s m!n3 n0w === jbicha is now known as Guest10768 === imbrandon2 is now known as imbrandon === gstobo_ is now known as gstobo === gustavobrunetto_ is now known as gustavobrunetto [11:10] quit [11:10] exit [13:00] hey all [13:00] how's everyone doing? === 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 Open Week - Current Session: Submitting your apps to the Ubuntu Software Centre - Instructors: dpm [13:01] Logs for this session will be available at http://irclogs.ubuntu.com/2012/05/03/%23ubuntu-classroom.html following the conclusion of the session. [13:02] so I hope everyone is doing well, and ready for the second day of Ubuntu Open Week! [13:03] let's wait a minute for stragglers to come in and then we can start === muthusuba_ is now known as muthusuba [13:04] I hope you all are enjoying Ubuntu Open Week so far... [13:05] great day of sessions yesterday, I especially enjoyed the omgubuntu story by marcoceppi and imbrandon [13:05] anyway, let's get started, shall we? [13:05] Hi everyone and welcome to the first session of Ubuntu Open Week Day 2! [13:06] My name is David Planella, and I work in the Community team at Canonical [13:06] During the next hour I'll be talking about how to submit your apps to Ubuntu, [13:06] so that they get published in the Software Centre [13:07] to be distributed to millions of users that will surely enjoy your cool software :) [13:07] But it will not be just a talk: I'll make sure that there is plenty of time for everyone [13:08] to participate and ask their questions at the end. However, feel free to interrupt me [13:08] during the rest of the session if you've got any questions. [13:10] sorry for the delay [13:10] ok, I was saying [13:10] Just remember to prepend them with QUESTION: on the #ubuntu-classroom-chat channel [13:10] Throughout the talk I will be referring to different places in the Ubuntu App Developer site, [13:11] which is the central place for anyone wanting to create and publish their apps in Ubuntu. [13:11] Here's where it lives: [13:11] http://developer.ubuntu.com === Andy_ is now known as Guest57401 [13:11] ... and without further ado ... [13:11] let's get rolling! [13:11] [13:12] Creating your app [13:12] ----------------- [13:12] [13:12] Well, the first step is obvious, you have to create your app, [13:12] which is basically the time when you materialise that cool idea into beautiful software. [13:12] I will not dwell too much on this subject, as it's beyond the scope of the session, [13:13] however, I'll just add a couple of tips for new app authors. [13:13] If you're considering writing a new application for Ubuntu, I'd recommend [13:13] to use the standard set of development tools available from the Ubuntu Software Centre [13:14] They are an extremely powerful and versatile bunch of utilities [13:14] which will not only put everything you need to write software at your fingertips, [13:14] but also will help you following good development practices. [13:15] And they're all Free Software and also free as in free beer! [13:15] You've got an overview of our recommendations to write new apps here: [13:15] http://developer.ubuntu.com/get-started/quickly-workflow/ [13:15] What we've also got is a tool called Quickly, which puts all those technologies together [13:15] You can learn more about it here, it's got a nice and short video tutorial [13:16] to show you how to write a basic functional template for your app in 3 minutes: [13:16] http://developer.ubuntu.com/get-started/ [13:16] However, if you've already written an application with another set of tools, [13:16] or if you do prefer another choice of toolkit, that's also ok! [13:16] We're providing these recommendations to make it easy for app authors to get started === yofel_ is now known as yofel [13:16] and provide a smooth path for publishing their apps. [13:16] However, we acknowledge the diversity of the whole Open Source ecosystem, [13:17] so you can basically submit your apps using your weapon of choice. [13:17] Just remember that our recommendations will make things easier, though! [13:17] ok, moving along [13:17] oh, any questions so far? [13:18] if so, remember to ask them on the #ubuntu-classroom-chat channel, prepending them with QUESTION [13:18] ok, if there aren's any, let's move on... [13:18] [13:18] Which types of apps qualify [13:18] --------------------------- [13:18] [13:19] There are thousands of apps available in the Ubuntu archive already, which usually get in there through other means. [13:19] Many of these fall into the category of system software, or big applications that are part of the Ubuntu platform. [13:19] They are also subject to strict policies to ensure the security and quality of the software, [13:19] as well as to ensure that they are indeed Free Software and can be distributed with Ubuntu. [13:19] So in order to differentiate from these archive applications, I'll call the process we'll be talking about today, "the app developer process". === jakub is now known as Guest95480 [13:20] Ultimately though, all software is published through the Software Centre [13:21] There are are 3 broad categories under which apps to be submitted through the app developer process fall: [13:21] * Paid-for apps [13:21] * Gratis apps with proprietary licenses === muthusuba_ is now known as muthusuba [13:21] * Gratis apps with Open Source licenses [13:22] Notice that as well as open source, we're also embracing commercial applications [13:23] to give the opportunity to app authors and Canonical to make revenue of application sales. [13:23] This should give you a rough idea, but ultimately you will need to know [13:23] the whole details to see if your app qualifies for the app developer process. [13:24] - For paid-for and gratis+proprietary apps: [13:24] http://developer.ubuntu.com/publish/commercial-software-faqs/ [13:24] - For gratis+open source apps: [13:24] https://wiki.ubuntu.com/AppReviewBoard/Review/Guidelines [13:25] ok, I see there are some questions, so I'll stop for a minute to take the opportunity to answer them [13:25] rks063 asked: i want to know that which language to opt for development? [13:26] we're currently recommending Python as a language of choice [13:26] in conjunction with a set of other tools to make you more productive when you're developing: [13:26] http://developer.ubuntu.com/get-started/quickly-workflow/ [13:27] This are the recommendations if you're a new developer, but as I was saying earlier on, if you've already started writing an app in another language, that's also welcome [13:27] eosorio asked: is there an app requirement desing? [13:28] That's a really good question [13:28] We do not have any design requirements at the moment - it's up to the app developer to choose consistent design standards [13:29] We do have documentation on how to better integrate with Ubuntu and Unity, though, which I would personally recommend to follow [13:29] check this out: http://developer.ubuntu.com/resources/platform/unity/ [13:29] Syd23 asked: How does a beginner ensure top quality code and where to find help? [13:31] for this one, I'd recommend browsing through the Resources section on the Ubuntu App Developer site, where you'll find the info you need and pointers to external resources too: [13:31] http://developer.ubuntu.com/resources/ [13:32] as per getting help, Askubuntu or the other support and discussion resources will direct you to the places where your questions can be answered: [13:32] http://developer.ubuntu.com/community/ [13:32] rks063 asked: which is thr basic part of ubuntu from where to start? [13:33] that's a very broad question, I'd recommend starting with the Ubuntu Platform diagram to understand the basics: http://developer.ubuntu.com/resources/platform/documentation/platform-diagram/ [13:33] ok, moving on... [13:34] Next is where it gets interesting: how to actually submit your app! [13:34] 1. Submitting your app [13:34] ---------------------- [13:34] [13:34] Ok, so all that cleared up, by this point you've already have a working app you'd [13:34] like the world to see and enjoy ;) [13:34] The good news is that we've got an easy, streamlined and web-based process [13:35] to make it easy for you to to publish, keep track of, monitor and update your apps. [13:35] For this, we've developed a tool especially for app developers. [13:35] It's called My Apps and you'll find it on the app developer site: [13:35] https://myapps.developer.ubuntu.com [13:35] You'll see that it's easy and intuitive to use, and the first thing you'll want to do is to sign up for it [13:35] so you can to enter the Ubuntu app developer programme and start using it straight away :-) [13:36] Signing up it's free, and again, it's a matter of a couple of minutes. [13:36] The process is based on Ubuntu's single login, [13:36] so if you've got an Ubuntu SSO account already, it will be even quicker. [13:36] Simply go to https://myapps.developer.ubuntu.com, either click on the "Sign in or register" link at the top right hand side [13:36] or the "Submit a new application" button, and the website will guide you through the process. [13:37] Before you continue the process of submitting the app though, you might want to read the quickstart guide on: [13:37] http://developer.ubuntu.com/publish/ [13:37] It will show you the basic steps you will be following and give you some useful tips along the way. [13:37] So let's go quickly through them: [13:38] 1 - Set up your My Apps account - you've already done that :) [13:38] 2 - Prepare your app's icons and screenshots - you will want your app to be [13:38] appealing to users, so make sure you've got nice screenshots and icons, in all recommended sizes [13:38] 3 - Add your application details - here you'll be describing your app and making it easily [13:38] discoverable in the Software Centre. Make sure the description is clear and use a spell-checker to avoid typos [13:39] 4 - Choose your price - if your app is paid for, you'll have to decide the price in USD at this point [13:39] The minimum price is $2.99 [13:39] 5 - Have an archive of your application ready to upload - here's where you upload your actual app to MyApps. More on this in a minute [13:39] 6 - Your app will be reviewed - before it gets into the wild, your app needs to be reviewed and QAd. More on this in a minute too. [13:39] So pretty easy, right? Now, going back on the step of uploading your app ... [13:40] Ideally, you should submit a Debian source package. A Debian source package consists of 3 files (with extensions .dsc, diff.gz, orig.tar.gz), which you should put in a compressed archive (a tarball, zip file, rar...) and upload into My Apps. [13:40] This will allow reviewers to easily test and publish your app. [13:40] *However*, there are some important caveats: [13:40] * If your app is commercial or proprietary software: we still recommend uploading a Debian source package, but if you are not experienced in packaging you can also upload either [13:40] - Sources or binaries – Your application’s source or binary files, bundled in an archive file (.tar.gz, .zip, etc) [13:41] - Debian source package – A Debian source package (.dsc, diff.gz, orig.tar.gz files, if you are already familiar with packaging), bundled in an archive file (.tar.gz, .zip, etc) [13:41] and the commercial packagers will package and publish it for you. [13:41] Very soon we'll have automatic packaging in place, but more details on that when it's all deployed and working [13:41] Also, as a wrap-up, check out this article on packaging commercial or proprietary software: [13:42] http://developer.ubuntu.com/2012/02/how-to-prepare-a-compiled-application-for-ubuntu-software-center/ [13:42] * If your app is Free Software and gratis: we recommend using a Personal Packaging Archive (PPA). [13:42] You can specify the location of your PPA in the 'Any additional notes for the application reviewer' text box in the Overview tab of your app's entry in My Apps. [13:42] You can also learn more about PPAs in the packaging section of the Ubuntu App Developer Site [13:42] http://developer.ubuntu.com/packaging [13:43] And finally, you'll find all the information related to submissions and packaging on http://developer.ubuntu.com/publish/my-apps-packages/ [13:43] Any questions on submissions? [13:45] PaoloRotolo asked: Hi, sorry, if my app is free I put the PPA link in "Any additional notes for the application reviewer" but I can't submit it if the "Source" field is empty... [13:46] good point. You need to upload something until this bug is fixed -> https://bugs.launchpad.net/developer-portal/+bug/920428 - so my recommendation would be just to upload a file to complete the process, even if it's just a text file to indicate the url of your PPA [13:46] eosorio asked: which percentage is for canonical vs developer? [13:47] That info is public on http://developer.ubuntu.com/publish/ - it's 80% for the app author and 20% for Canonical [13:48] ok, let's continue [13:48] [13:48] 2. Reviewing your app [13:48] --------------------- [13:48] [13:48] After your application has been submitted, and depending of the type of app, one of two things will happen: [13:48] * If it's a paid for or a gratis+proprietary app, it will be reviewed by the Canonical reviewers team. If necessary, they will package it for you and QA it. Very soon, though, we'll be able to automatically package those. [13:49] * If it's a Free Software+gratis app, it will generally be reviewed by a team of volunteers called the Ubuntu App Review Board (ARB) [13:49] In any case, reviewers will get in touch with you as soon as they start reviewing [13:49] your app, and you will be notified of any app state changes by e-mail. [13:49] For all the exact details of an application's lifecycle in My Apps, check out: [13:49] http://developer.ubuntu.com/publish/application-states/ [13:49] And if you've submitted a Free Software app and you want to contact the ARB, [13:50] you can jump into the #ubuntu-arb channel and ask how to help, or you can contact the ARB through e-mail [13:50] https://wiki.ubuntu.com/AppReviewBoard [13:50] you'll find all the details there [13:50] [13:50] There are 10 minutes remaining in the current session. [13:50] Ok, we're getting near the end, so time to wrap up... [13:50] [13:50] Getting help [13:50] ------------ [13:50] [13:51] If you need any help or if you've got any questions, be it during or before the [13:51] publishing step, there is an awesome, awesome community of app developers out [13:51] there just like you, willing to lend a hand [13:51] Check out: [13:51] http://developer.ubuntu.com/community/ [13:51] From there, I'd like to highlight: [13:51] * Real-time chat: http://webchat.freenode.net/?channels=ubuntu-app-devel [13:51] i.e. the #ubuntu-app-devel IRC channel on Freenode [13:51] * Askubuntu: http://www.askubuntu.com/questions/ask?tags=application-development [13:51] For all your app development related questions [13:52] and that was all for the talk :) [13:52] I hope you've enjoyed, and let's see if there are any questions [13:52] Hari85 asked: are scientific softwares reviewed by the people associated with the field [13:53] it is up to the app developer to ensure their apps work as expected, [13:54] so there is no review to ensure that scientific software (or in general of any other particular kind) are working up to the specs [13:54] more questions? === gau1991__ is now known as gau1991 [13:55] There are 5 minutes remaining in the current session. [13:56] ok, so if there aren't any more questions, the only thing left is to thank you all for listening in and your questions. I hope you enjoyed the session, you learnt something new, and see you on the next one! :-) [13:58] So time to leave the floor to dholbach, the man who epitomizes Ubuntu development and fun, with this "Ubuntu Development - how it all works" session! [14:00] thanks a lot dpm [14:00] Welcome to Ubuntu Open Week everyone! === 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 Open Week - Current Session: Ubuntu Development - how it all works - Instructors: dholbach [14:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/05/03/%23ubuntu-classroom.html following the conclusion of the session. [14:01] My name is Daniel Holbach, I work for Canonical, but have been involved in Ubuntu development beforehand already - at Canonical I work with these fine young gentlemen: https://launchpad.net/~canonical-community/+mugshots [14:01] (dpm is one of them :-)) [14:01] so if you have any questions, please please please ask - also if I'm being unclear or should confuse you :) [14:02] but please prefix it with QUESTION: [14:02] ie: QUESTION: Which band do jono and jcastro argue most about? [14:02] alright [14:02] in this first session I'd like to give you an overview over Ubuntu development - so how a typical release cycle works out, what we work on, who we interact with and what general considerations are [14:03] in the second session, depending on how much time we have, I'll show you some practical examples of how we fix bugs and work on packages [14:03] 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. [14:04] 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. [14:04] Once this source package is compiled, the build process provides binary packages, which are the .deb files users can install. [14:04] 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. The resulting binary packages then are distributed to the archive and its mirrors in different countries. [14:04] The URLs in /etc/apt/sources.list point to an archive or mirror. [14:04] Every 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. [14:05] I hope this illustrates how we work on the source and the source only. Every now and then we get .deb packages submitted for review and inclusion - but it doesn't work that way. :-) [14:06] Any questions up until now? [14:06] sagaci asked: when can one start developing/testing for the next ubuntu release? [14:06] sagaci, Usually the next development release is opened within a week after the last release got out. [14:07] So https://lists.ubuntu.com/archives/ubuntu-devel-announce/2012-April/000955.html for example announced that 'quantal' (12.10) was opened on the 30th April. [14:07] The release was on 26th April IIRC, so this was very well executed by toolchain, Ubuntu archive and Launchpad developers. :) [14:08] rks063 asked: i am beginner in the developement of ubuntu. I want to know how to set up the environment for developing ? [14:08] rks063, I'll get to that in part 2 of the session :) [14:08] sorry - I should have mentioned it earlier: please ask your questions in #ubuntu-classroom-chat [14:09] eagles0513875_ asked: if you have a new program which isnt available in debian but you want to compile it and get it into the ubuntu repositories what is the best way to go about doign that? get it in upstream debian? [14:09] eagles0513875_, that's certainly a good way to do it - the advantage of getting it into Debian is obviously that you reach many many more users, but also that many other developers can help out with it as well [14:10] https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages has more information about how to go about that [14:10] moving on - let me talk a bit about the typical Ubuntu release cycle [14:10] Ubuntu’s development is very much dependent on the current stage of the release cycle. We release a new version of Ubuntu every six months, which is only possible because we have established strict freeze dates. [14:11] With every freeze date that is reached developers are expected to make fewer, less intrusive changes. [14:11] 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. The rest of the cycle is supposed to be focused on fixing bugs. [14:11] 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. 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. [14:11] bobweaver asked: metadata is like control file in debian package ? [14:11] bobweaver, exactly, or debian/copyright or debian/changelog, etc. [14:12] if this doesn't make sense to anybody else yet, don't worry - we'll get to it in Part 2 [14:12] eagles0513875_ asked: are there guidelines where exceptions could and are made in regards to those freeze dates [14:13] eagles0513875_, yes - https://wiki.ubuntu.com/FreezeExceptionProcess lists a few them, but generally - if you're unsure - you can always ask in #ubuntu-devel or #ubuntu-motu for advice [14:13] you can only document so much, sometimes you have to simply learn by osmosis - by talking to fellow developers by talking to them [14:14] 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. [14:14] 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. 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. [14:14] 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. [14:15] If you go to http://uds.ubuntu.com/ you can see that the next UDS is going to happen in Oakland, California on 7–11 May 2012. [14:15] http://uds.ubuntu.com/community/remote-participation/ explains how to participate remotely [14:15] eagles0513875_ asked: who can attend UDS? is it just canonical staff and full time employees only? [14:16] eagles0513875_, anybody - if you're in the area and have time, make sure you drop by, say Hi, go into sessions and discuss things [14:16] Ubuntu is such a great place precisely because we have so many bright people who can easily contribute ideas, code and help in all kinds of other forms [14:17] if you're not in Oakland next week, you can still participate remotely [14:17] Any more questions about the release cycle or release planning? [14:18] eagles0513875_ asked: in regards to kubuntu. is that now community run project still going to be a part of UDS and follow the same release cycle as ubuntu? [14:18] eagles0513875_, yes [14:19] at UDS we have always had many meetings of all kinds of Ubuntu flavours, sometimes other communities chose to let their meetings coincide with UDS to discuss things there and get more people involved [14:19] so I don't expect things to change in this regard - it's a concept which has proven to work well :) [14:19] eagles0513875_ asked: so basically it means there are no longer full time canonical employees involved in the project? [14:20] eagles0513875_, if you talk about Kubuntu, then that question can't be really answered with 'yes' or 'no' [14:20] Kubuntu gets a lot of its foundations from Ubuntu (just like Ubuntu Desktop does), it still uses the same infrastructure [14:20] and there are people working on other Qt-related bits [14:21] so I don't think it would be fair to say "nobody works on Kubuntu" [14:21] but the goals of the Kubuntu distribution are not driven by Canonical [14:21] eagles0513875_ asked: This might be a bit off topic but could you explain what canonical is doing in regards to kubuntu, cuz for me that is a great concern as well as other kubuntu users as well [14:22] it is a bit off-topic and I'm probably not the best person to answer the question - I hope what I said above at least gave some additional information [14:22] alright, moving on :) [14:22] Not every single change can be discussed in a meeting though, particularly because Ubuntu relies on changes that are done in other projects. [14:22] That is why contributors to Ubuntu constantly stay in touch. Most teams or projects use dedicated mailing lists to avoid too much unrelated noise. [14:23] For more immediate coordination, developers and contributors use Internet Relay Chat (IRC). All discussions are open and public. [14:23] 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. [14:23] All information is collected in that report and its importance, status and assignee updated when necessary. [14:23] This makes it an effective tool to stay on top of bugs in a package or project and organise the workload. [14:24] Let's talk about the projects Ubuntu interacts with. [14:24] 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. These projects are called “Upstreams”, because their source code flows into Ubuntu, where we “merely” integrate it. [14:25] 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). [14:25] 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. [14:25] Traditionally, Debian has always had dedicated maintainers for every single package or dedicated maintenance teams. [14:25] 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. [14:26] bmoez asked: if any body want to discus about an idea or project in progress for the next version of ubuntu in UDS but he is not in Oakland next week, what can he do? is there any place to post his ideas (opinions)? [14:26] bmoez, first of all it makes sense to scan the list of sessions at UDS and make sure you can (remotely) attend them and add your thoughts via IRC [14:27] also I'd make sure to bring it up on a mailing list for a related team [14:27] ie: you want to improve documentation, then mail the ubuntu-server team mailing list with your proposal [14:28] but even if it doesn't get discussed at UDS, you can still write up a proposal with a dedicated implementation plan and bring it up for discussion with a relevant team [14:30] Question: in the future is there anything that LP is goig to have to submit upstream packages to Ubuntu motu team I central hub that users can give simple info about upstream [14:30] bobweaver, can you give some additional information about what you're looking for? A place to submit packages for inclusion in Ubuntu? [14:31] if it is, I'd suggest to have a look at https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages [14:32] Question: Sure just say I find some source or "upsteeam" package that I want to hand off because I can not build my-self [14:32] bobweaver, yes, in that case have a look at the page I mentioned -it should describe what to do :) [14:32] Let's talk a bit about getting changes into Ubuntu. This is where you come in. :-) [14:32] Getting a change into Ubuntu as a new contributor is not as daunting as it seems and can be a very rewarding experience. [14:33] 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. [14:33] Open Source Development happens in a distributed world with different goals and different areas of focus. 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. That is why we make use of “Distributed Development”, where code is being worked on in variou [14:33] s branches that are merged with each other after code reviews and sufficient discussion. [14:35] In this example 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. [14:36] Any questions about Upstreams, bug fixes and how to get fixes in? [14:37] Great, moving on then. :) [14:38] 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. [14:38] And the last bit is super important. We have a lot of automated tools to build, run some checks and people who review code, but with millions of users out there, it is important that you test your fixes. [14:39] 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. [14:39] eagles0513875_ asked: when you say build im guessing you mean on ones local machine? [14:39] eagles0513875_, yes - I usually find it a lot easier to build a package locally than to upload it to a PPA (which of course is also an option) [14:40] there are tools, which I'll introduce in the next session, which make the task of building it locally very easy [14:40] especially during busy times you sometimes have to wait a few hours until your package is built in a PPA [14:40] so building locally is more convenient - also if you are working on the fix and go through many iterations of fixing, building, testing [14:40] eagles0513875_ asked: is there a place beginning bug fixers can turn for mentoring so that they can learn about how to debug as well as getting new bug fixers used to the vast array of tools at their disposal [14:41] eagles0513875_, yes, I'll share some links later on [14:41] unfortunately we don't have dedicated 1-to-1 mentoring, because it turned out to be very very time-consuming, but we still have good documentation, very friendly people who can help you out on IRC and will have bug fixing initiatives to get involved in this cycle :) [14:42] more links and info later on [14:42] The process I mentioned above (propose fix for inclusion, get it reviewed and uploaded by somebody with upload rights) is what we call 'sponsoring' [14:43] after you have worked with sponsors for a while and gained their trust, you can apply for upload rights yourself [14:43] When trying to find a solution for a bug, 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. [14:44] This way we don't waste efforts and you'll get to learn from many other developers and make friends across projects. [14:44] If you are fixing bugs, additional steps might involve getting the change backported to an older, still supported version of Ubuntu and forwarding it to Upstream. [14:44] Any more questions about fixing bugs, upload rights, other projects, etc.? [14:45] eagles0513875_ asked: What exactly does bug triaging mean and does it involve? [14:45] eagles0513875_, great question! [14:46] Triaging is a term that stems from the hospital world. It means that you try to understand the problem, categorise and classify it, so whoever works on the solution has all the relevant information in their hands. [14:47] so if you triage a bug, you want to make sure you understand which exact circumstances lead to the problem, how to reproduce it and maybe even where in the code to look for the problem [14:47] so bug triage and bug fixing goes hand in hand [14:48] the more you know in the beginning and the easier to find the bug (use tags and good title/description, links to upstream bug or bugs in other distributions), the easier to fix it [14:48] eagles0513875_ asked: If a bug is for an end of life release of ubuntu is it safe to say that that bug can be closed? [14:49] yes, if an Ubuntu release reaches its end of life and it is not present in currently supported releases, we can safely close it [14:50] I usually get asked which requirements there are for getting involved in Ubuntu development [14:50] I'm surprised nobody asked up until now. :-) [14:50] So, 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. [14:50] Good places to ask your questions are ubuntu-motu@lists.ubuntu.com and #ubuntu-motu on irc.freenode.net. You will easily find a lot of new friends and people with the same passion that you have: making the world a better place by making better Open Source software. [14:50] There are 10 minutes remaining in the current session. [14:51] Any more general questions about Ubuntu development? Anything which wasn't clear enough before? [14:51] eagles0513875_ asked: What exactly is the MOTU and what do they do? what is their purpose? [14:51] MOTU stands for "Masters of the Universe". :) === eagles0513875_ is now known as eagles0513875 [14:52] Developers with MOTU upload rights can upload packages to Universe and Multiverse [14:52] But MOTU is much much more than that [14:53] MOTU is not only people who are interested in *verse packages, but also a great place to get started with Ubuntu development - as I mentioned before: you can ask all kinds of questions there, with always somebody around to answer them [14:53] eagles0513875 asked: if they are the ones that push the packages to the repos. Could you clarify exactly what the developers channels are there for [14:54] erm [14:54] so anybody can propose new packages or fixes to packages to go into Ubuntu [14:54] you don't need upload rights for that [14:55] MOTU grants you specific upload rights, whereas core-dev would grant you upload rights to the whole archive, and you can get upload rights for specific packages or package sets as well [14:55] There are 5 minutes remaining in the current session. [14:56] if there are no more immediate questions, I would suggest taking a 5 minute break before get our hands dirty [14:56] I need to get another cup of tea :) [14:57] QUESTION: what would classify a package for universe or multiverse repository? also would it be a good place to start in regards to upload rights for one once sufficient experience is gained, would it be good to start as an MOTU then progress to core-dev? [14:58] eagles0513875, all packages start in universe or multiverse, to get them into main or restricted, they need to get a special review, because being in main means they are supported for 18 months (or 5 years for LTS releases) [14:58] and yes, you can always apply for the upload rights you need and apply for more afterwards :) [14:59] gau1991 asked: Being a developer is only task in Ubuntu? [14:59] good question :) [14:59] gau1991, No, development is not the only task in Ubuntu [14:59] for example can you contribute translations, artwork, help with documentation, advertise Ubuntu, give user support, help with bug reports, and so on [15:00] there are many many things to do in Ubuntu, you don't need to be a developer, if that's not your interest [15:00] eagles0513875 asked: when you say advertise ubuntu is there material for those to put on their website or give out etc? === 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 Open Week - Current Session: Ubuntu Development - fixing bugs - Instructors: dholbach [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2012/05/03/%23ubuntu-classroom.html following the conclusion of the session. [15:01] eagles0513875, yes, there's http://spreadubuntu.org/ [15:01] alright - session 2 [15:01] for everyone who just joined [15:01] in this channel we only have the presentation itself, if you have questions or want to chat a bit, please join #ubuntu-classroom-chat [15:02] if you have questions and want them answered in the session, please make sure you prefix them with QUESTION: [15:02] (in #ubuntu-classroom-chat) [15:02] For Session 2, I'll try to squeeze quite a bit of content in, so please let me know if I go too fast [15:03] in any case I'll share links to documentation later on, so you can read about everything in a bit more detail [15:03] Ok, first let's get set up for Ubuntu development [15:04] It is advisable to do packaging work using the current development version of Ubuntu. Doing so will allow you to test changes in the same environment where those changes will actually be applied and used. [15:04] Don’t worry though, the Ubuntu development release wiki page shows a variety of ways to safely use the development release: https://wiki.ubuntu.com/UsingDevelopmentReleases [15:05] even if you don't run 'quantal' (12.10) right now, you will still be able to follow the instructions here :-) [15:05] There are a number of tools that will make your life as an Ubuntu developer much easier. You will encounter these tools later in this guide. To install most of the tools you will need run this command: [15:05] sudo apt-get install packaging-dev [15:06] This might take a while, but don't worry - you can always go back to the instructions [15:06] This command will install the following software: [15:06] - gnupg – GNU Privacy Guard contains tools you will need to create a cryptographic key with which you will sign files you want to upload to Launchpad. [15:06] - pbuilder – a tool to do a reproducible builds of a package in a clean and isolated environment. [15:06] - ubuntu-dev-tools (and devscripts, a direct dependency) – a collection of tools that make many packaging tasks easier. [15:06] - bzr-builddeb (and bzr, a dependency) – distributed version control with Bazaar, a new way of working with packages for Ubuntu that will make it easy for many developers to collaborate and work on the same code while keeping it trivial to merge each others work. [15:06] - apt-file provides an easy way to find the binary package that contains a given file. [15:06] - apt-cache (part of the apt package) provides even more information about packages on Ubuntu. [15:07] Any questions up until this point? [15:08] gau1991 asked: can we use GIT or SVN? [15:08] gau1991, sure, and if you work with some upstream projects you will have to use whatever revision control system they use [15:08] bear in mind though that most of the Ubuntu development is done using Bazaar [15:09] Usually I include "how to set up your GPG key" and "how to set up your SSH key" and "how to set up your Launchpad account", but we don't immediately need them for the session, so I'll just give you some links instead [15:09] this way we should have a bit more time for questions and actually looking at fixing a bug [15:11] eagles0513875 asked: even though we are packaging are there any dbg packages that we would want to install before hand or do we install them depending on what we are working on? [15:11] eagles0513875, sure, we could install them, but I won't have time to discuss debugging program crashes for example in this session [15:11] you have a point though [15:12] if you work as a developer, you rarely just do "packaging", sometimes you will do "debugging" as well, or "fixing the build system" or "writing C code", etc [15:13] ok, here are the links for [15:13] - setting up your Launchpad account: https://help.launchpad.net/YourAccount/NewAccount [15:13] - LP and your GPG key: https://help.launchpad.net/YourAccount/ImportingYourPGPKey [15:14] - LP and your SSH key: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair [15:14] but as I said earlier, you don't need to do this *right now* - later is fine :) [15:14] ok, moving on [15:14] if the package installation above succeeded, please run: [15:15] pbuilder-dist create [15:15] in our case, that'd be: [15:15] pbuilder-dist quantal create [15:15] so we can work on the upcoming 12.10 release together [15:15] again running this command will take its time [15:15] it will set up a minimal environment in which builds are done [15:16] for that it will download a whole lot of packages, but the good thing is: everything is going to be cached [15:16] meanwhile, you can open another terminal and edit your ~/.bashrc file in there [15:16] somewhere around the end of it, please add something like this to it: [15:16] export DEBFULLNAME="Bob Dobbs" [15:16] export DEBEMAIL="subgenius@example.com" [15:17] and please only use "Bob Dobbs" if that's your name :) [15:17] once you've done that, please save the file, leave the editor and run [15:17] source ~/.bashrc [15:17] (or simply restart your terminal) [15:18]