[00:52] <jcastro> akgraner: my irc session was all messed up
[00:52] <jcastro> did everything go ok?
[00:55] <akgraner> yeppers
[00:56] <akgraner> we only ended 10 mins before the end of the session
[00:56] <akgraner> mhall119, did a great job!
[00:57] <jcastro> akgraner: awesome, so basically bueno owes mhall119 a beer!
[00:57] <akgraner> exactly!
[00:58] <akgraner> however if mhall119 isn't around - I'll proxy for him and drink it for him :-D
[01:03] <jcastro> I see you often enough to keep that promise, heh
[01:04] <akgraner> hehe
[01:48] <mhall119> akgraner: no stealing my drinks!
[01:49] <mhall119> ah, who am I kidding, unless it's coffee I really don't care
[01:49] <mhall119> but coffee I'll fight you for
[01:49] <akgraner> mhall119, dang you weren't supposed to notice that comment :-P
[01:49] <mhall119> irssi highlights are like the answering machine for IRC
[01:50] <mhall119> I can come back hours later and see who's talking about me
[15:57] <delcoyote> hi
[16:21] <maja87> hey
[16:50] <dholbach>  W E L C O M E   E V E R Y B O D Y
[16:50] <dholbach> … to the last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:50] <dholbach> I hope you all are having a great time
[16:51] <dholbach> if you weren't around in all of the sessions, just check out the logs on https://wiki.ubuntu.com/UbuntuDeveloperWeek
[16:51] <dholbach> thanks a lot to everybody who's participating to make this such a great event
[16:51] <dholbach> if you're here for the first time today, please also head to #ubuntu-classroom-chat (if you're not using lernid or in the channel already)
[16:51] <dholbach> because that's where all the chatter and questions for the presenter happen
[16:52] <dholbach> just make sure you prefix your questions with QUESTION: so they stand out
[16:52] <dholbach> first today is going to be Michael mhall119 Hall, who will talk a bit about Django, why it's awesome and why it should be a natural choice as a web framework if you want to avoid pain and instead enjoy what you're doing
[16:53] <dholbach> have a great day every one, you still have 7 minutes to relax a bit before mhall119 gets cracking
[16:56] <mhall119> While we're waiting, if anybody isn't familiar with Django, please take a quick look here: http://www.djangoproject.com/
[16:56] <mhall119> also, if you plan on following along with our actual code, you might want to go ahead and sudo apt-get install python-django
[17:01] <mhall119> alright, time to get things started
[17:01] <mhall119> First off, my name is Michael Hall, I'm a software developer for the Moffitt Cancer Research Center in central Florida
[17:02] <mhall119> We use Django extensively for internal applications that support our medical research studies
[17:02] <mhall119> I'm also one of the loco-directory hackers (http://loco.ubuntu.com), which is also based on Django
[17:03] <mhall119> Django is a web application framework for Python, it's a lot like J2EE is for Java, only much much easier
[17:04] <mhall119> You can get Django from http://www.djangoproject.com/ or apt-get install python-django if you're on Ubuntu
[17:04] <mhall119> today's class is going to be 2 hours long, which still isn't enough time to cover everything you can do with Django
[17:04] <mhall119> so we're going to be covering enough to get a very simple web app up and running
[17:05] <mhall119> there will be code involved, if you have django I'll help you get it up and running on your local box
[17:05] <mhall119> if you don't have Django, I still recommend getting the code with us, so you can follow along
[17:06] <mhall119> in the first hour, we'll just be getting django setup with a very simple "hello world" type app
[17:06] <mhall119> in the second hour we'll start creating data models, which is where django really makes programming fun and easy
[17:06] <mhall119> so if you can stick around for both session, I'd highly recommend it
[17:07] <mhall119> before we get started, any question on Django in general?
[17:07] <mhall119> < saji89> QUESTION:does a web framework differ from a CMS?
[17:07] <mhall119> yes, a web framework is more low-level than a CMS
[17:08] <mhall119> at it's most basic, it run redirects queries to a URL to come piece of code you've written to handle it and return a response
[17:08] <mhall119>  < abuazzam> QUESTION is there any alternative to django? why django is better? sorry for my  english
[17:09] <mhall119> Yes, there are alternatives.  Zope is another python web framework, it's what Launchpad is built on
[17:09] <mhall119> I don't have as much experience with Zope, so I won't go into which is better or why
[17:10] <mhall119> any other questions before we start working on code?
[17:10] <mhall119> okay
[17:11] <mhall119> if you have Django installed, it provided a command line tool to help you bootstrap your project
[17:11] <ClassBot> abhijit asked: i know about qunta plus. is django similar to it?
[17:11] <mhall119> I'm not familiar with qunta, sorry
[17:12] <mhall119> okay, so to start a django project, you run django-admin $projectname
[17:12] <mhall119> for these classes, we're going to make a cookbook app
[17:12] <mhall119> so I ran: django-admin startproject cookbook
[17:12] <mhall119> sorry, forgot the "startproject" command in the first example
[17:13] <mhall119> instead of doing that, I'd like everyone to run this: bzr branch -r tag:mkproject lp:~mhall119/+junk/cookbook
[17:13] <mhall119> that will get you a copy of my cookbook branch as it is after running startproject
[17:17] <mhall119> sorry for the confusion, it seems you need to have an ssh key registered with Launchpad to run the bzr command
[17:18] <mhall119> those who don't can view the code here: http://bazaar.launchpad.net/~mhall119/+junk/cookbook/revision/1
[17:18] <mhall119> as you'll see, Django creates a few files for you, I'll quickly go over each
[17:19] <mhall119> manage.py is going to be the script you use to work with your project
[17:19] <mhall119> you'll see more of that later
[17:19] <mhall119> settings.py is where you configure your project, giving it DB connection information, telling it which apps to include, etc
[17:20] <mhall119> A django project is comprised of multiple django applications, which means you can mix and match existing applications with your own custom ones to build your project
[17:21] <mhall119> finally, urls.py is where you map a url pattern to a python function that will handle requests to it
[17:21] <mhall119> okay, so next we need to create our custom application
[17:21] <mhall119> for that I ran "django-admin startapp recipes"
[17:22] <mhall119> but you don't have to do that
[17:22] <mhall119> if you have the bzr branch, just run bzr pull -r tag:mkapp
[17:22] <mhall119> that will update your local copy with the app's files
[17:22] <mhall119> this creates a "recipes" folder under your project folder
[17:23] <mhall119> ( I should have said to cd into the cookbook project folder first)
[17:23] <ClassBot> nite asked: what do you need to have to work withdjango?
[17:24] <mhall119> all you need is python and django
[17:24] <mhall119> you can also run Django behind apache, using mod_wsgi or mod_python
[17:24] <mhall119> but django has a built-in web server that is very useful for local development
[17:24] <mhall119> that's what we'll be using today
[17:24] <ClassBot> Nervengift95 asked: is there a difference between the bzr branch and the files created by the django commands?
[17:25] <mhall119> nope, I ran those command and commited the files they created directly into the branch
[17:25] <ClassBot> abhijit asked: do I need to know python to use django?
[17:25] <mhall119> yes, since you will be programming a web app, you will need to know the language
[17:25] <mhall119> this is another way a web framework differs from a CMS
[17:26] <mhall119> but python is very easy to learn, so don't let that discourage you
[17:26] <ClassBot> saji8973 asked: So, bzr is not an absolute requirement?
[17:26] <mhall119> correct, you don't need bzr to use django,  I'm just using it for this class
[17:26] <mhall119> okay, moving on
[17:27] <mhall119> you should now have your 'recipes' app folder, lets look at what's in there
[17:27] <mhall119> models.py you can ignore for now, we'll come back to that in the next hour
[17:27] <mhall119> test.py we're not going to touch on at all, that's a topic for another day
[17:27] <mhall119> so that only leaves us with views.py
[17:28] <mhall119> for those who can't get bzr working, you can look at the files here: http://bazaar.launchpad.net/~mhall119/+junk/cookbook/revision/2
[17:28] <mhall119> as you can see, views is currently empty
[17:29] <mhall119> Django follows a Model-View-Template model, which is analogous to MVC
[17:29] <mhall119> a Django view is nothing more than a Python function that takes an HttpRequest object as an argument
[17:30] <mhall119> so if you run: "bzr pull -r tag:welcome" we'll get our first view
[17:32] <mhall119> now if you look at views.py, you will see our first view
[17:32] <mhall119> it also made a couple changes to cookbook/settings.py and cookbook/urls.py
[17:33] <mhall119> in settings.py, we added our 'recipes' app to the INSTALLED_APPS array
[17:33] <mhall119> at the bottom of the file
[17:33] <mhall119> that tells Django that we want to include that app in our project
[17:34] <mhall119> above it you see some of Django's built in apps that are installed by default to give you the functionality you'd expect from a web framework
[17:34] <mhall119> next if you look at urls.py, you'll see we added a single entry at the bottom
[17:35] <mhall119> this tells django that any request to this server who's path matches '^welcome/', pass the request on to the welcome function
[17:35] <ClassBot> Error404NotFound asked: Is it really essential to have an application? We can host views.py urls.py models.py and other such in project directory and access them. Which is better and why? Also how does Django compare to its PHP alternates such as Zend, CakePHP?
[17:35] <mhall119> true, your views can exist outside of application directories
[17:36] <mhall119> but using applications helps keep your code separate and modular
[17:36] <mhall119> which helps reusability and readability
[17:36] <mhall119> I'm not familiar enough with PHP frameworks to make a comparison
[17:37] <mhall119> okay, now that we have our app and our view, it's time to see it in action
[17:37] <mhall119> from the project's directory, run: ./manage.py runserver
[17:38] <mhall119> this will start Django's built-in webserver on http://127.0.0.1:8000/
[17:38] <mhall119> if you go there in a browser, you will see a lovely 404 page like this: http://family.ubuntu-fl.org:8002/
[17:39] <mhall119> why the 404?
[17:39] <mhall119> because the only URL we have mapped is /welcome, Django doesn't know what to do with just /
[17:40] <mhall119> try it again with /welcome at the end
[17:40] <mhall119> you should see something more like http://family.ubuntu-fl.org:8002/welcome/
[17:40] <mhall119> which is nothing more than the text string we put into our HttpResponse object in our welcome view
[17:42] <mhall119> as Error404NotFound just mentioned, you will see that page a lot when writing your django app, as well as the 500 error page
[17:42] <mhall119> the 404 shows you what url patterns Django is looking for, so if you have a typo or something, it makes it easy to compare and find
[17:43] <mhall119> the 500 page will give you a stacktrace of the calls leading up to the error, as well as the values of local variables in those calls, it's very useful for tracking down the source of errors
[17:44] <mhall119> now, as easy as it is to throw a string into HttpResponse and return it, you don't really want to do that for an entire page of HTML
[17:44] <mhall119> so Django provides a built-in templating system
[17:44] <mhall119> if you now run: "bzr pull -r tag:addtemplate" you will see how that works
[17:45] <mhall119> that revision pulls in recipes/media and recipes/templates directories
[17:45] <mhall119> by default, Django will look for template files in $app/templates/ for any installed application
[17:46] <mhall119> (another good reason for using applications)
[17:46] <mhall119> if you take a look at templates/welcome.html, you'll notice it's not 100% HTML
[17:46] <mhall119> it contains markup for Django's custom template language
[17:47] <mhall119> you can't use straight Python in Django templates, which makes them a little less powerful by themselves compared to regular PHP
[17:47] <mhall119> but it does make them very fast
[17:47] <mhall119> and you can extend the template language with your own tags (which we won't cover today, sorry)
[17:48] <mhall119> right now the only tag we're using in welcome.html is {{MEDIA_URL}}
[17:49] <mhall119> Django templates use {{ }} for variable substitution
[17:49] <mhall119> which means MEDIA_URL is a variable name in teh templates context
[17:49] <mhall119> how did it get there?  take another look at your views.py
[17:49] <mhall119> now, instead of returning an HttpResponse object, we're calling render_to_response
[17:50] <mhall119> which itself is just a helper function that renders the template to an HttpResponse object for you
[17:50] <mhall119> the first parameter is the name of the template file to use
[17:50] <ClassBot> There are are 10 minutes remaining in the current session.
[17:50] <mhall119> the second is a python dictionary of name/value pairs, this is the template's context
[17:51] <mhall119> recipes.MEDIA_URL is defined in cookbook/recipes/__init__.py, it's just a base URL path for the recipes/media folder
[17:52] <mhall119> if you look again at cookbook/urls.py, you'll see that there is an extra line mapping urls with that base to Django's built-ind static.serve view
[17:52] <mhall119> if you are running behind Apache, you'll set your apache conf to serve those files basedon that url, bypassing Django all together, which is more efficient
[17:53] <mhall119> now if you go back to your welcome page you will see this: http://family.ubuntu-fl.org:8002/welcome
[17:53] <mhall119> and before anyone says it, I know my HTML is horrible, and my graphic is lame
[17:54] <mhall119> one last thing in this hour
[17:54] <mhall119> run: "bzr pull -r tag:showdebug"
[17:54] <mhall119> and refresh your browser
[17:55] <mhall119> you'll see now a red bar saying you're in debug mode
[17:55] <mhall119> look again at welcome.html to see how I did that
[17:55] <ClassBot> There are are 5 minutes remaining in the current session.
[17:56] <mhall119> notice the {% if settings.DEBUG %} {% endif %} tags
[17:56] <mhall119> if/else/endif lets you conditionally display blocks of your template depending on the values of context variables
[17:57] <mhall119> in this case, it's getting the value from our settings.py file
[17:57] <mhall119> and that's the end of this hour, any question on what we've covered so far?
[17:58] <ClassBot> ean5533 asked: Is there anything Django CAN'T do?
[17:58] <mhall119> At this point, I haven't figured out how to make it serve me coffee
[17:58] <mhall119> joking aside, since your views are in python, it can do pretty much anything you can do in python
[17:59] <ClassBot> lousygarua asked: how are the {% and %}'s quicker than <?php ?>?
[17:59] <mhall119> I don't know about quicker, it's just what Django uses
[17:59] <mhall119> {% %} denotes a tag, while {{ }} denotes variable substitution
[18:00] <mhall119> tags are bits of python code that operate on values passed to them, or wrapped in them
[18:00] <ClassBot> ubuntufreak16 asked: You mentioned about the red bar with debug mode but that didn't happen for me is it because i use chromium ?
[18:00] <mhall119> I'm using chromium, so that's not it
[18:00] <mhall119> did you do the last bzr pull?  Also, check that settings.py DEBUG == True
[18:01] <mhall119> should be on line 3
[18:01] <mhall119> ubuntufreak16: try restarting the django server then, you usually don't have to do that though
[18:02] <ClassBot> Nervengift95 asked: i get a 404 that /welcome doesn't match ^welcome$ whats wrong?
[18:02] <mhall119> make sure you don't have a / at the end of the url
[18:02] <mhall119> this is my mistake, I removed it from the original url pattern at some point
[18:03] <mhall119> okay, I'm going to take a 2 minute break, let everyone run to the restroom or refill their coffee
[18:04] <mhall119> because the next hour is going to be kind of fast, and you won't want to miss any of it
[18:07] <mhall119> okay, everybody back now?
[18:09] <mhall119> alright, I hope everyone is back by now
[18:09] <mhall119> so, if Django views are simple, Django models are magic
[18:10] <mhall119> models are really at the heard of most Django applications, they define the data records you're going to be working with throughout your app
[18:10] <mhall119> and Django provides a very nice ORM layer between your model definitions and your database tables
[18:11] <mhall119> run "bzr pull -r tag:addmodels"
[18:12] <mhall119> first, lets look at the changes this made in our settings.py
[18:12] <mhall119> on line 12, we specified that the DATABASE_ENGINE we'll be using is sqlite3
[18:12] <mhall119> Django should make it so you never have to care about what database you're using
[18:13] <mhall119> and sqlite is convenient for development
[18:13] <mhall119> at Moffitt, we use sqlite3 for development, and MySQL or Oracle in production
[18:13] <mhall119> on line 13, we specify the file name to use for our Sqlite3 database
[18:14] <mhall119> now let's look at recipes/models.py
[18:14] <mhall119> in it you'll see that I've defined 4 data models for our cookbook application
[18:15] <mhall119> Django models are Python classes that extend django.db.models.Model
[18:15] <mhall119> in them, you define the fields your model will have
[18:16] <mhall119> Django comes with many predefined field types that will most likely cover everything you need
[18:16] <mhall119> the full list can be found here: http://docs.djangoproject.com/en/1.2/ref/models/fields/#ref-models-fields
[18:17] <mhall119> but you can also make your own custom fields if you ever needed to
[18:17] <mhall119> the first 2 models, Category and Ingredient, are pretty basic, they just contain a character field called "name"
[18:17] <mhall119> most of what we're interested in is in the Recipe model
[18:18] <mhall119> here we can create links to other models with the ForeignKey and ManyToMany field types
[18:19] <mhall119> category links a Recipe record to one Category record (a Category record can be linked to zero or more Recipes)
[18:19] <mhall119> and ingredients links one or more recipes to one or more ingredients
[18:20] <mhall119> if you don't include the "through" parameter on the ManyToMany field, Django will create the necessary linkage for you
[18:20] <mhall119> but in this case, I wanted to add additional information to that linkage, so I created another Measurement class
[18:20] <mhall119> this lets me add a quanity and unit field to the relationship between recipes and ingredients
[18:21] <mhall119> notice also that I am giving the "unit" field a list of choices
[18:21] <mhall119> Django will automatically create HTML form elements for you, based on your model definitions, and the "choices" parameter will make this field a <select>, rather than an <input>
[18:22] <mhall119> now that we have our model definition, Django can use them to build out database tables
[18:22] <mhall119> so we don't need to write any SQL create statements, or thinking about table structure
[18:22] <mhall119> Django does that all for us, and in a surprisingly efficient manner
[18:23] <mhall119> so, from your cookbook/ project folder, run ./manage.py syncdb
[18:23] <mhall119> syncdb tells Django to update the database with tables for any new models
[18:23] <mhall119> since we're using sqlite3, it will also create the cookbook.db file in our project's folder
[18:24] <mhall119> any questions so far?
[18:25] <ClassBot> ean5533 asked: What if you want to change your model? Does Django gracefully change the database structure?
[18:25] <mhall119> the short answer is no, syncdb is only smart enough to create a table if it's missing
[18:25] <mhall119> if you add or remove fields from your model after the fact, it won't touch the tables
[18:25] <mhall119> the long answer is "yes", but with the help of a Django application called South
[18:26] <mhall119> http://south.aeracode.org/
[18:26] <mhall119> South takes snapshots of our model defintions as you change them, and lets you automatically "migrate" your table structures to add or remove columns
[18:27] <mhall119> we have recently started using South at Moffitt, and also in the loco-directory project, and I've been very impressed with it
[18:27] <ClassBot> lousygarua asked: can you elaborate more on the ManyToMany field? I don't understand what it does
[18:27] <mhall119> basically, it will create an intermediate table, with foreign key links to both the model tables
[18:28] <mhall119> since we provided the Measurement model, and it has foreign key fields to both Ingredient and Reciple, it will use that
[18:28] <mhall119> I hope than answers your question
[18:28] <ClassBot> ubuntufreak asked: when i tried the command it showed me the Django's auth system to define a superuser, what is its purpose ?
[18:29] <mhall119> ah yes, in settings.py we have django.contrib.auth as one of our INSTALLED_APPS
[18:29] <mhall119> this gives us a user/group system to use in our project
[18:29] <mhall119> and as part of the setup for that app's models, it's going to ask you to create a superuser
[18:29] <mhall119> for this demo, just use root/password
[18:30] <mhall119> we won't really go into using access controls, but the Auth system is what lets you require user accounts and logins
[18:30] <mhall119> < ubuntufreak> mhall119, is it a one-time process specific to the app
[18:30] <mhall119> yes, it'll only ask you for that when you syncdb for the first time with the Auth app
[18:31] <mhall119> another very useful app that comes with Django is the Admin app
[18:31] <mhall119> django.contrib.admin
[18:31] <mhall119> which gives you a very generic interface to add/modify/delete records based on your model definitions
[18:32] <mhall119> do use it, we need to add it to our INSTALLED_APPS, create a url pattern for it, and most importantly tell it about our models
[18:32] <mhall119> so run "bzr pull -r tag:addadmin" from your project folder
[18:33] <mhall119> in settings.py, we just added django.contrib.admin to our INSTALLED_APPS list
[18:33] <mhall119> and in urls.py we uncommented the lines to enable it
[18:33] <mhall119> finally, we added the file recipes/admin.py
[18:33] <mhall119> let's take a look at that real quick
[18:34] <mhall119> the first three are very simple, we just register the model with the admin site, and it will use the field definitions in them to build our interface
[18:34] <mhall119> but for Recipe, we want to add a little bit more
[18:34] <mhall119> we want to be able to add/remove Measurement items from the same form
[18:35] <mhall119> so we create an "Inline" form for them, and then create a custom Admin interface for Recipe, specifying that we want to inline forms for Measurements
[18:36] <mhall119> otherwise we'd have to go define all our measurements in one place, then the recipe in another
[18:36] <mhall119> next, we need to run ./manage.py syncdb again
[18:36] <mhall119> why again?
[18:37] <mhall119> well, because we added the Admin app to our project, so we need to create whatever tables it needs
[18:37] <mhall119> in this case, it's just a LogEntry table, for tracking changes you make from the admin app
[18:38] <ClassBot> Nervengift95 asked: how do I create a superuser when i said i didn't want one during syncdb?
[18:38] <mhall119> I'm not sure how to make one after the fact, since we're just getting started you can simply delete cookbook.db, and run syncdb again
[18:38] <mhall119> you will want a superuser account for the next step
[18:40] <mhall119> now if you point your browser to /admin/ you will see the login screen for the admin app
[18:40] <mhall119> like this: http://family.ubuntu-fl.org:8002/admin/
[18:40] <mhall119> once you log in, you'll see your models listed under the Recipes app
[18:41] <mhall119> from there you can add/change/delete your records
[18:41] <mhall119> for the sake of time, though, just download http://people.ubuntu.com/~mhall119/cookbook.db and copy it over your current cookbook.db
[18:43] <mhall119> then you can see that I've got all the fixing for a delicious plate of Spaghetti
[18:44] <mhall119> okay, gonna have to rush through the rest, so hang on
[18:44] <mhall119> run "bzr pull -r tag:recipeview"
[18:44] <mhall119> you will see that I added a new view function called show_recipe
[18:45] <mhall119> with a new line in urls.py, mapping the path /recipe/(\d*) to that view
[18:46] <mhall119> the (\d*) regular expression will match any number, and that number will be passed as the second argument to our view function
[18:46] <mhall119> in this case, it will be the internal recipe_id
[18:46] <mhall119> also, I am not a chef, this is the spaghetti I make when it's my turn to cook
[18:47] <mhall119> don't mock it
[18:47] <mhall119> now if you go back to your /welcome page, you will see our spaghetti entry listed as a link
[18:47] <mhall119> click that link, and you'll go to our new view page
[18:48] <mhall119> that view uses the recipes/templates/recipe.html template
[18:48] <mhall119> in there you see that we use the {{ }} substitution to put the values for our recipe's fields where we want them
[18:49] <mhall119> we can also loop over the ManyToMany field using the {% for value in list %} tag
[18:49] <mhall119> okay, one last step, let's add a search form
[18:49] <mhall119> bzr pull -r tag:searchform
[18:51] <mhall119> then look at recipes/forms.py
[18:51] <mhall119> we define forms in much the same way we defined models, they are a python class that extends django.forms.Form
[18:51] <mhall119> and contains fields of different types
[18:51] <mhall119> these are different from our model field types
[18:52] <mhall119> form fields can be found here: http://docs.djangoproject.com/en/1.2/ref/forms/fields/#ref-forms-fields
[18:52] <mhall119> and again you can make your own if you ever needed to
[18:52] <mhall119> Django forms are also magical
[18:53] <mhall119> they not only handle building the HTML elements to display our form, they also parse the values out of the submit request, and validate them against the field type
[18:53] <mhall119> you can also add your own clean_$fieldname methods to your form, to perform extra validation
[18:53] <mhall119> now if you go back to your /welcome page, you will have a search box at the top
[18:54] <mhall119> type in "taco" and hit search, and you'll get nothing
[18:54] <mhall119> type in "spa" and hit searh, you get Spaghetti
[18:54] <mhall119> the magic behind all that is recipes/views.py lines 13 to 17, only 4 lines!
[18:55] <mhall119> not covered here, but something you will use, is the ModelForm
[18:55] <mhall119> ModelForm takes a model definition, and automagically created a Form based on it's field definitions
[18:56] <mhall119> it also performs validation based on not only the field type, but any additional restrictions you have
[18:56] <mhall119> remember how Measurement.unit has an array of choices?  Not only will the ModelForm render that as a <select> field, but if the submitted value isn't in the choices list, it will fail validation and tell the user so
[18:57] <mhall119> any questions in our remaining few minutes?
[18:57] <mhall119> before I go, I want to mention again the loco-directory project: https://launchpad.net/loco-directory
[18:57] <mhall119> this is the code behind loco.ubuntu.com
[18:58] <mhall119> we are always looking for new contributors, and I just taught you everything you needed to know to get started
[18:59] <mhall119> we label quick and easy fixes as "bitesize" bugs, and they are perfect for getting started: https://bugs.launchpad.net/loco-directory/+bugs?field.tag=bitesize
[18:59] <mhall119> the developers hang out in #ubuntu-locoteams most of the time, so if you need help getting loco-directory setup just come in and ask
[18:59] <mhall119> but mostly if you follow the directions in the INSTALL file, you'll be up and running in no time
[19:00] <mhall119> any other questions?
[19:01] <jcastro> Hi everyone!
[19:01] <jcastro> This class will be about Adopt an Upstream
[19:01] <jcastro> thanks for coming, let's get started!
[19:01] <jcastro> First of all, what is an upstream
[19:02] <jcastro> and why should we adopt them?
[19:02] <jcastro> Imagine that "Ubuntu" as a distribution sits on a river
[19:02] <jcastro> we take software from large projects, GNOME, KDE, Linux, Xorg, etc.
[19:03] <jcastro> imagine that those projects are "upstream" along the river
[19:03] <jcastro> because their software flows down to us
[19:03] <jcastro> inbetween us an upstreams on this river is Debian
[19:03] <jcastro> and further "downstream" from Ubuntu you have things that are derivatives from Ubuntu
[19:03] <jcastro> Things like Linux Mint, etc.
[19:04] <jcastro> (sorry my linode disconnected me)
[19:05] <jcastro> ok so on this big "Free Software river" we have all these projects
[19:05] <jcastro> so when you hear people talking about "upstreams", they're usually referring to a project that we ship in Ubuntu
[19:05] <jcastro> so for example, the rhythmbox folks, Mozilla, Miro, couchdb, etc. are all examples of upstream projects
[19:06] <jcastro> since the software flows downstream (like a boat)
[19:06] <jcastro> things need to flow upstream.
[19:06] <jcastro> Bugs about the software
[19:06] <jcastro> patches that potentially fix the software
[19:06] <jcastro> feedback on the software
[19:06] <jcastro> things like that
[19:07] <jcastro> and like swimming upstream, it takes effort, patches and bugs don't magically flow upstream
[19:07] <jcastro> so like on rivers with dams, we can build little fish elevators so stuff can flow back.
[19:07] <jcastro> this "flow", "circle of life", or whatever you want to call it needs to be efficient, or bad things can happen
[19:08] <jcastro> For example, when we started actually measuring the amount of patches sitting in Launchpad waiting for review ...
[19:08] <jcastro> we found /over 2500/ patches.
[19:08] <jcastro> https://wiki.ubuntu.com/OperationCleansweep
[19:08] <jcastro> so we started this
[19:08] <jcastro> to start getting those fixes and patches reviewed, and upstream.
[19:09] <jcastro> Any questions so far?
[19:09] <jcastro> (bah one sec)
[19:10] <jcastro> < simar> QUESTION: Are there projects that are created on launchpad with no upstreams..
[19:10] <jcastro> in those cases the project themselves are the upstream
[19:10] <jcastro> not everything is in Debian and/or Ubuntu
[19:10] <jcastro> and even in the case of software that we make for ubuntu, the same flow applies
[19:10] <jcastro> so for example, the software-center is an upstream
[19:11] <jcastro> ok, so now that you know about the river, let's talk about some of the things you can do to make this flow be more efficiently
[19:12] <jcastro> as I talk about some of these things you're going to think it's all common sense
[19:12] <jcastro> and "wow, how come people just aren't doing that every day?"
[19:13] <jcastro> So, with over 20k packages in our archive, it can be tough to keep track of all this stuff
[19:13] <jcastro> so, we know we have users who care about stuff
[19:13] <jcastro> and we know we have upstreams who always wouldn't mind extra help
[19:13] <jcastro> so, what if we connected people who are passionate about software with the upstream?
[19:14] <jcastro> so, we created adopt-an-upstream
[19:14] <jcastro> which is basically explained here: https://wiki.ubuntu.com/Upstream/Adopt
[19:15] <jcastro> the idea being "I care about my favorite mp3 player, so I am going to work with upstream and ubuntu developers to get things sorted"
[19:15] <jcastro> larger projects, like our amazing MozillaTeam are larger
[19:16] <jcastro> however, poor Joe Smith who started a quickly project last month might not be so lucky.
[19:17] <jcastro> So, let me talk to you about some examples on what I do with my personal favorite piece of desktop software, Banshee
[19:17] <jcastro> I idle in their IRC
[19:17] <jcastro> I subscribe to their mailing lists
[19:17] <jcastro> I read their roadmaps
[19:17] <jcastro> and I do these sorts of things on the distro side as well
[19:17] <jcastro> I try to be the "ubuntu guy" for them.
[19:18] <jcastro> So if they have a fix that they want out to users, I help getting them talk to the packager, etc.
[19:18] <jcastro> And I just don't it myself, we have people from the Debian and Ubuntu Mono teams who chip in
[19:18] <jcastro> so overall we try to basically "be there" for the upstream project.
[19:19] <jcastro> Another place where upstreams appreciate help is bug reporting
[19:19] <jcastro> http://castrojo.tumblr.com/post/785661804/papercutter-profile-marcus-carlson
[19:19] <jcastro> I just blogged about a guy who not only was working on the ubuntu problems, but also helping the upstream clean up their bugs
[19:19] <jcastro> and generally Being Awesome.
[19:20] <jcastro> So what we have is a list: https://wiki.ubuntu.com/BugSquad/AdoptPackage
[19:20] <jcastro> and basically you kind of take ownership of that package
[19:20] <jcastro> you go through the bug reports
[19:20] <jcastro> Launchpad makes it real easy for people to link to upstream bugs
[19:21] <jcastro> unfortunately sometimes people don't know how to make good bugs
[19:21] <jcastro> it might be missing good information, etc.
[19:21] <jcastro> And to be honest, who wants developers reading bugs all day? We want them fixing bugs!
[19:21] <jcastro> So what we try to do is act as a quality filter on bugs
[19:22] <jcastro> we weed out the junk bugs (or try to get reporters to add information)
[19:22] <jcastro> and then only forward the best bugs we can
[19:22] <jcastro> So really, you don't have to be a rocket scientist
[19:23] <jcastro> all it really takes is someone who is willing to put one foot in each project and connect people, bugs, and patches.
[19:23] <jcastro> Any questions so far?
[19:24] <jcastro> Ok, another area of things you can talk to upstreams about are some of the great tools we've made for upstream developers to use.
[19:24] <jcastro> Maybe they need help setting up a daily build PPA.
[19:24] <jcastro> Or a stable release PPA for older Ubuntu releases.
[19:24] <jcastro> maybe they're not in Ubuntu yet, and want to know how to get into Ubuntu.
[19:25] <jcastro> or maybe they don't understand the workflow with Debian.
[19:25] <jcastro> So since I got sick of explaining it to projects over and over again ... I just wrote them all down
[19:25] <jcastro> https://wiki.ubuntu.com/Upstream
[19:25] <jcastro> The goal of this page is to give upstreams a "everything you need to know about Ubuntu in one page"
[19:26] <jcastro> it's not really new content, it just points people to existing pages.
[19:26] <jcastro> You might be looking at this and saying "well, duh."
[19:26] <jcastro> but remember every upstream project is different, so we can't expect them to know what a PPA, and SRU, or Notify-OSD is, for example.
[19:27] <jcastro> one of my FAVORITE things we can do for upstreams is hook them up with apport hooks.
[19:27] <jcastro> So you've all seen when an application crashes
[19:27] <jcastro> and we gather this info, and attach it to the bug report
[19:28] <jcastro> https://wiki.ubuntu.com/Apport/DeveloperHowTo
[19:28] <jcastro> we can write these to get more information
[19:29] <jcastro> So for example, the Banshee guys are currently moving over from HAL (the old device stuff), to udev/gio/libgpod (all the new sexy bits)
[19:29] <jcastro> and they want to test this
[19:29] <jcastro> but in order to be truly useful
[19:29] <jcastro> we need things like the firmware version and all this kind of stuff
[19:29] <jcastro> in the past we would make a huge wiki page
[19:29] <jcastro> and say "fill in your ipod info here and link it to your bug"
[19:30] <jcastro> but with apport hooks we can make that automatically
[19:30] <jcastro> so today I asked didrocks to whip up one for Banshee ipod testing
[19:30] <jcastro> so now users can plug stuff in, click stuff, and auto submit data.
[19:30] <jcastro> So what I did today was talk to one of the Banshee developers
[19:31] <jcastro> and asked him how we could help. What fields of information did he need from the debug tools?
[19:31] <jcastro> where should we send the data?
[19:31] <jcastro> is the data we send you good enough to help you add support for that model?
[19:31] <jcastro> where do we send data that is so new that we need to submit that data to his upstream, libgpod?
[19:32] <jcastro> those are the kinds of things adopters think about, and try to fix.
[19:32] <jcastro> < umang> QUESTION: I know there should be enough projects out there who could be helped. But I was still wondering whether there is a place (e.g. wiki page) where upstreams can register themselves for "we want someone familar with
[19:32] <jcastro>                Debian/Ubuntu to help us work with them"
[19:32] <jcastro> that is an excellent question
[19:32] <jcastro> so ideally, every upstream would have a person to do this
[19:33] <jcastro> however we always have limited time and volunteers
[19:33] <jcastro> (which is why we always run sessions looking for more)
[19:33] <jcastro> right now the best thing to do if you need to be adopted is to add yourself to the wiki page, or ask for help on a mailing list.
[19:33] <jcastro> https://wiki.ubuntu.com/BugSquad/AdoptPackage
[19:34] <jcastro> so under "Packages that should really be adopted"
[19:34] <jcastro> I would just add your project there, and perhaps a note "Get in contact with me and I'll help get you started" or something like that
[19:34] <jcastro> the people in #ubuntu-bugs and the BugSquad can help you as well
[19:35] <jcastro> and we can always do our best to help find you a person
[19:35] <jcastro> < umang> jcastro, I was asking more in terms of finding upstreams that could do with help.
[19:35] <jcastro> ah, so really, that is a great question because it's all of them
[19:35] <jcastro> I know that sounds like a lame answer
[19:36] <jcastro> What I recommend to people is to do something you're familiar with
[19:36] <jcastro> and passionate about
[19:36] <jcastro> no one wants to spend all day working on software they hate
[19:36] <jcastro> The big projects always need a hand (Mozilla, OOo)
[19:36] <jcastro> but I personally prefer to pick something more in the middle. Not too big, not too small.
[19:37] <jcastro> It's also important to remember that you are part of a larger team
[19:37] <jcastro> so don't think if you want to help OpenOffice with bugs that you're going to get swamped and killed.
[19:38] <jcastro> Another way you can help projects is by trying to find them new volunteers.
[19:38] <jcastro> I am notorious for doing this. I basically find people who aren't busy and convince them to help a project.
[19:38] <jcastro> http://castrojo.tumblr.com/post/656609843/someone-want-to-help-out-redshift
[19:38] <jcastro> Here's an example
[19:39] <jcastro> < simar> QUESTION: Say I have adopted a package and aren't enough bug triagers that help with that package, one possible reason for this is that the package is not properly documented anywhere, so some odd triagers will always ask
[19:39] <jcastro>                for irrelevent information from bug filers should someone, probably who know more consider adding a wiki page on information to ask while triaging and debug procedures,,
[19:39] <jcastro> aha! awesome, I was just going to get to that
[19:39] <jcastro> let's look at some examples
[19:40] <jcastro> https://wiki.ubuntu.com/Bugs/Upstream
[19:40] <jcastro> here's an example of some pages on where we talk about how to triage bugs in more detail
[19:40] <jcastro> (this includes forwarding)
[19:41] <jcastro> remember since every upstream is different they might have different workflows
[19:41] <jcastro> so for example, some upstreams want to see every bug, crap or not, they want them all
[19:41] <jcastro> some want us to filter
[19:41] <jcastro> some want patches in bugzilla, some want them in a git branch, some even (still!) want patches posted on mailing lists
[19:42] <jcastro> so here on these pages we try to document how to make that process suck less.
[19:42] <jcastro> so on these pages, the bugsquad took care of the big ones, like KDE and GNOME
[19:42] <jcastro> but let's look at this one: https://wiki.ubuntu.com/Bugs/Upstream/Listen
[19:42] <jcastro> someone who cared about the Listen media player made that page
[19:43] <jcastro> < NMinker> QUESTION: Would it be smart to join a team who only pushes every other new release to (let's say) the main Maverick repo? So that issues (like kernel/program incompatibility) are fixed pushed to the main repo.
[19:43] <jcastro> ABSOLUTELY
[19:43] <jcastro> let's say you're a generalist
[19:43] <jcastro> and you are interested in the desktop
[19:44] <jcastro> (actually hold on, their page is broken, let me find a more squared away team *cough*)
[19:45] <jcastro> (almost found it, smoke if you got em)
[19:46] <jcastro> https://wiki.ubuntu.com/BugSquad/TODO
[19:46] <jcastro> ok
[19:46] <jcastro> so in this example the BugSquad has a list of stuff that needs to get done
[19:46] <jcastro> each team should have a list of "low hanging fruit"
[19:47] <jcastro> for something like the kernel (which is large and has a large team), my recommendation is to just show up on IRC and ask someone for some things that need to get done
[19:47] <jcastro> https://wiki.ubuntu.com/DesktopTeam/GettingStarted
[19:47] <jcastro> here the desktop team has a list of where to sign up
[19:47] <jcastro> and links to bugs you can work on
[19:48] <jcastro> < NMinker> I asked because I'm currently testing Maverick on VMware, and packaging (for open-vm-tools) available in the repo don't compile properly.  And I had to go the bug report and grab the patches needed to make it compile
[19:48] <jcastro>                  properly in Maverick and push it to my PPA.
[19:48] <jcastro> so this is my favorite kind of situation
[19:48] <jcastro> can you link me to the bug?
[19:49] <jcastro> I'd like to take some time to talk about this
[19:49] <jcastro> because I'd like to close the loop on things like this
[19:50] <jcastro> so first off, this is also an example of a "service" that you can help with upstreams
[19:50] <jcastro> perhaps they have a certain patch that they are interested in, but need it tested
[19:50] <ClassBot> There are are 10 minutes remaining in the current session.
[19:50] <jcastro> throwing it in a PPA and letting them know about it lets them throw testers at it
[19:51] <jcastro> so in this case where you have a fix
[19:51] <jcastro> and you have it in a PPA
[19:52] <jcastro> the best thing to do is put it in Maverick, you can do that by generating a debdiff, posting it on the bug, and testing it, and then ask a sponsor to look at it
[19:52] <jcastro> https://wiki.ubuntu.com/SponsorshipProcess
[19:52] <jcastro> ok, any other questions? Is there an area you want me to go over again?
[19:53] <jcastro> one thing I find tremendously useful is to be the ubuntu factoid for an upstream
[19:53] <jcastro> so for example, I am mindful of when freezes are in our development process
[19:53] <jcastro> and how things might work
[19:54] <jcastro> sometimes I know an upstream will say "ah, their feature freeze is on 12 may, that means I can release on 11 may and still make it for lucid!" or whatever
[19:54] <jcastro> this is an excellent time to get them talking to a packager or a Debian Developer
[19:55] <jcastro> because there is always plumbing stuff going on in a distro that upstreams might not be aware of
[19:55] <ClassBot> There are are 5 minutes remaining in the current session.
[19:56] <jcastro> QUESTION: are there any minimal expectations from someone who adopted a package? I adopted the debian-installer packages a few months back but I think it's going to take some time to get everything really nice
[19:56] <jcastro> https://wiki.ubuntu.com/Upstream/Adopt
[19:56] <jcastro> I tried my best to list those at the bottom
[19:56] <jcastro> and asked some upstreams what they would expect someone like that to be
[19:57] <jcastro> from the upstreams I've talked to, they're happy to have someone who is willing to learn.
[19:57] <jcastro> it would suck if you signed up to help a project and ended up just getting in the way
[19:57] <jcastro> which is why I like to idle in IRC channels and read up on the mailing lists
[19:57] <jcastro> so I can educate myself when they're doing major changes
[19:58] <jcastro> I try to pay attention when they want to do a major feature
[19:58] <jcastro> I am always thinking "if we got that into a PPA and brought in the ubuntu hordes, we could get some great testing done."
[19:58] <jcastro> and upstreams /love/ when we can provide them with data.
[19:59] <jcastro> < NMinker> I hate when that happens, when I get in the way
[19:59] <jcastro> everyone messes up!
[19:59] <jcastro> it's how you learn and adapt that make it all Just Work(tm) in the end
[19:59] <jcastro> ok, that's it for me
[19:59] <jcastro> I hope you learned something!
[19:59] <jcastro> And I hope you help me provide our upstream projects with the tools they need to make people love their operating system!
[20:01] <highvoltage> Good morning / afternoon / evening depending on where you are!
[20:02] <highvoltage> This session is on Edubuntu, and how to get involved
[20:02] <highvoltage> It's not as interactive as mhall119's session from earlier, and not quite as well prepared as jcastro's session
[20:03] <highvoltage> I moved from South Africa to Canada about two weeks ago, and I'm in the process of moving to a new apartment so to say that I'm all over the place at the moment is a bit of an understatement :)
[20:03] <highvoltage> In this session, I hope to introduce you to the project and make it easy to get involved, I'll cover:
[20:03] <highvoltage> • What the Edubuntu project is,
[20:04] <highvoltage> • What we do
[20:04] <highvoltage> • Community structure
[20:04] <highvoltage> • and how you could get involved.
[20:05] <highvoltage> if there's any questions, feel free to ask at any time in #ubuntu-classroom-chat, if you append QUESTION to your question, the bot will notify my in a private message
[20:05] <highvoltage> (although at this stage in the developer week I'm sure everyone knows that by now ;) )
[20:05] <highvoltage> Let's start at the beginning, usually a very good place to start.
[20:06] <highvoltage> The Edubuntu project takes on a quite a few tasks
[20:06] <highvoltage> ons of the most important tasks is supporting, maintaining packages relating to education in Ubuntu
[20:07] <highvoltage> that also includes bug fixes
[20:07] <highvoltage> if you followed the session on adopt-an-upstream earlier, it's like the Edubuntu team adopted all of the educational packages in the Ubuntu repositories
[20:08] <highvoltage> not quite as formally though, but after that session we might actually do it :)
[20:08] <highvoltage> if you'd like to get involved with Edubuntu on a technical level, then bug fixes are a great place to start
[20:09] <highvoltage> you can find a list of current bugs in the packages that we track at the following URL:
[20:09] <highvoltage> https://bugs.launchpad.net/~edubuntu-bugs/+packagebugs
[20:10] <highvoltage> you'll notice that there are currently 356 open bugs being tracked
[20:11] <highvoltage> and that the packages range from educational software, to system management tools useful for classrooms and more
[20:11] <highvoltage> while Edubuntu tracks the bugs in these packages, most of these packages are also tracked by other teams
[20:11] <highvoltage> for example,
[20:12] <highvoltage> ltsp, ltspfs and ldm are all part of LTSP, which are maintained by the LTSP team (https://launchpad.net/ltsp)
[20:13] <highvoltage> and the kdeedu suite is also maintained by the Kubuntu team who does a great job of looking at Ubuntu's KDE packages
[20:13] <highvoltage> there are some packages which are maintained by us only
[20:14] <highvoltage> you could think of them as the packages for which we are upstream
[20:14] <highvoltage> these are usually the packages that I personally give most attention to since they're vital for being able to install an Edubuntu system
[20:15] <highvoltage> these package names typically begin with edubuntu- or ubuntu-edu
[20:15] <highvoltage> examples are:
[20:15] <highvoltage>  ∘ ubuntu-edu-preschool
[20:15] <highvoltage>  ∘ ubuntu-edu-primary
[20:15] <highvoltage>  ∘ ubuntu-edu-secondary
[20:15] <highvoltage>  ∘ ubuntu-edu-tertiary
[20:15] <highvoltage>  ∘ edubuntu-artwork
[20:15] <highvoltage>  ∘ edubuntu-live
[20:16] <highvoltage>  ∘ edubuntu-desktop
[20:16] <highvoltage> the ubuntu-edu-* packages are metapackages
[20:17] <highvoltage> metapackages are packages that don't contain any direct data, but contains information such as dependencies, so they end up just installing other software
[20:17] <highvoltage> ubuntu-edu-preschool will install an application bundle for really young kids
[20:17] <highvoltage> primary and secondary for school kids, and tertiary for post-secondary studends
[20:18] <highvoltage> we don't write any of the educational software ourselves
[20:19] <highvoltage> instead, we aim to put together the best of what the free software world has to offer together in an easily installable package
[20:19] <highvoltage> before I move on, I'd like to mention bug days
[20:20] <highvoltage> every now and again (and we should have one scheduled again soon) we have a bug day where the team joins in on #edubuntu, and we co-ordinate and fix a bunch of bugs
[20:20] <highvoltage> we like to do this before alpha and beta releases, this also provides a great opportunity to test the images that are generated
[20:21] <highvoltage> if you follow planet ubuntu (http://planet.ubuntu.com), you'll usually see a bunch of us blog about it
[20:21] <highvoltage> otherwise, joining the edubuntu development mailing list is probably the best way to keep up to date with events
[20:22] <highvoltage> I'll provide more details on that and how to get in touch a bit later
[20:22] <highvoltage> I'll already said quite a bit, any questions before we move on?
[20:23] <highvoltage> one of the more prominent Edubuntu projects is our Edubuntu installation disc
[20:24] <highvoltage> it takes all the meta-packages I mentioned earlier and installs it automatically as part of the installation process
[20:25] <highvoltage> this allows very easy installation of all the education packages. It's in part being obsoleted by the software center
[20:25] <highvoltage> or at least, so we thought :)
[20:26] <highvoltage> in previous releases, we made Edubuntu an add-on cd to Ubuntu, since the packages became really easy to install via the app installer. we had quite a few users which were outraged, a lot of people want something really simple and turn-key
[20:26] <highvoltage> that's also why we spend some energy on LTSP
[20:26] <highvoltage> LTSP is the Linux Terminal Server Project, it allows you to netboot a whole bunch of diskless machines from one machine without having to do a lot of setup work
[20:27] <highvoltage> for Edubuntu 10.04, we integrated a graphical LTSP installer as part of the installation process
[20:27] <highvoltage> it makes it really easy for even a relatively unexperienced user to install it
[20:28] <highvoltage> also, we've included an option to run LTSP live from the live CD
[20:28] <highvoltage> for improved performance, you can also use the startup disk creator to create a live USB disk to test ltsp
[20:28] <highvoltage> this is great for demoing the technology and also for users completely new to the concept to experiment with it
[20:30] <highvoltage> in addition to producing our own artwork and session packages, we also like to work with other derivatives and if possible, get their work included in the archives so that it can be easily installed on Ubuntu
[20:31] <highvoltage> our best example so far is Qimo and mhall119. We worked together to get the Qimo packages into the Ubuntu archives
[20:31] <highvoltage> now, if someone wants to install a Qimo desktop session in Ubuntu, it's as simple as installing the qimo-session meta-package
[20:32] <highvoltage> we'd like to do more things like this, although it's often very time consuming keeping contact with other projects (also ties in with adopt-an-upstream again)
[20:32] <highvoltage> but mhall119 has been really great and has been really easy to work with!
[20:34] <highvoltage> that pretty much covers what we do, in summary, we maintain a bunch of packages in Ubuntu, try to get new ones in, work with similar projects as far as we can and also produce an installable DVD that aims to make it really easy for pretty much anyone
[20:35] <highvoltage> Next I'll cover our community structure. Since we're just over half-way, are there any questions before we move on?
[20:36] <highvoltage> Edubuntu is fully integrated into the rest of the Ubuntu community
[20:36] <highvoltage> we follow all the same procedures, we use the same build infrastructure and follow all the same rules
[20:36] <highvoltage> some people prefer to think of Edubuntu as a completely seperate project than Ubuntu
[20:36] <highvoltage> but that is just wrong
[20:37] <highvoltage> all of our work happens from within Ubuntu, we report to the Ubuntu Community Council and also the Ubuntu Technical Board
[20:38] <highvoltage> we also have our own council, called the Edubuntu Council. The Edubuntu Council is a deligate to the Community Council and the Ubuntu Technical Board
[20:38] <highvoltage> if you're unfamiliar with those terms,
[20:39] <highvoltage> please refer to the ubuntu governance page on http://www.ubuntu.com/project/about-ubuntu/governance
[20:39] <highvoltage> it's usually much easier to contribute to a project if you know how it's managed :)
[20:40] <highvoltage> being a Community Council delegate, the Edubuntu Council is allowed to grant Membership to people who have contributed good solid contributions over a period of time
[20:41] <highvoltage> Ubuntu membership is an official recognition of work done with Ubuntu (or in our case, Edubuntu). as part of this you'll get an @ubuntu.com e-mail address (and also a @edubuntu.org email address) as well as have the right to represent yourself as an Ubuntu representative by printing Ubuntu/Edubuntu business cards
[20:42] <highvoltage> more information on membership is available on https://wiki.ubuntu.com/Membership
[20:43] <highvoltage> being a Technical Board delegate, the Edubuntu Council is allowed to grant upload rights to contributors who have shown skills and commitment to maintaining packages
[20:44] <highvoltage> applying with the Edubuntu Council, you can become an official Edubuntu Developer (edubuntu-dev on Launchpad)
[20:44] <highvoltage> Edubuntu Developers can upload any of the packages that form part of the Edubuntu, which is pretty much the bug list I mentioned earlier
[20:46] <ClassBot> mhall119 asked: https://launchpad.net/~edubuntu is a moderated team, what are the requirements for membership?
[20:46] <highvoltage> I was thinking about that just earlier today!
[20:46] <highvoltage> when Edubuntu was initially founded, that was the group for the entire team
[20:47] <highvoltage> since then we branched out and created a ton of new groups, and also later on cut back and simplified
[20:48] <highvoltage> basically that group is currently undefined, what I'm going to suggest at the next edubuntu weekly meeting,
[20:48] <highvoltage> is that we just make it an open group for anyone interested in edubuntu to join
[20:48] <highvoltage> we've had lots of people wanting to join #edubuntu-members like that, so if someone wants to show support for edubuntu and get an edubuntu badge on their profile it would be nice to have a group for that
[20:49] <highvoltage> so in short, we'll probably make it a group that anyone who wants to get involved with edubuntu can join
[20:50] <highvoltage> the Edubuntu team has weekly meetings on IRC where we do a quick status update on the activities the last week, and also discuss any problems that we might have
[20:51] <ClassBot> There are are 10 minutes remaining in the current session.
[20:51] <highvoltage> attending these meetings is probably the best way to keep up to date of what's happening in Edubuntu
[20:51] <highvoltage> it's also a good place to check in and find out what the current problems are, which can be useful if you want to get involved
[20:52] <highvoltage> It's every Wednesday evening  at 19:00 in #ubuntu-meeting
[20:53] <highvoltage> it's an open meeting and anyone is allowed to join
[20:53] <highvoltage> if you'd like to add a topic, feel free to add it to our agenda and add your name after the agenda item: https://wiki.ubuntu.com/Edubuntu/Meetings/Agenda
[20:54] <highvoltage> besides the weekly meetings, we also communicate over other platforms
[20:54] <highvoltage> we use a few mailing lists:
[20:54] <highvoltage> Edubuntu users: general support list for all Edubuntu users. This includes regular Ubuntu users who happen to use educational packages or Ubuntu in an educational environment
[20:55] <highvoltage> that list is at http://lists.ubuntu.com/mailman/listinfo/edubuntu-users
[20:55] <highvoltage> Then there's Edubuntu Developers, that's for anyone who contributes to and works on Edubuntu:
[20:55] <ClassBot> There are are 5 minutes remaining in the current session.
[20:55] <highvoltage> http://lists.ubuntu.com/mailman/listinfo/edubuntu-devel
[20:56] <highvoltage> and there's also the Ubuntu Education list, this is a list for mostly non-technical users and educators who use Ubuntu for educational purposes
[20:56] <highvoltage> http://lists.ubuntu.com/mailman/listinfo/ubuntu-education
[20:57] <highvoltage> you can find us on Identica: http://identi.ca/group/edubuntu
[20:57] <highvoltage> facebook: http://www.facebook.com/pages/Edubuntu/112139832136110
[20:57] <highvoltage> as mhall119 mentioned in -chat, the IRC channel is a great place to find all of us
[20:57] <highvoltage> that's on #edubuntu on this network
[20:58] <highvoltage> we're basically out of time, but I think I managed to say everything that I intended to.
[20:58] <highvoltage> There's 2 more minutes left, any final questions?
[20:59] <highvoltage> For anyone reading either on IRC or in the logs afterwards, thanks for doing so, have a great weekend!
[21:00] <highvoltage> End of session. *GONG*
[21:00]  * warp10 waves
[21:00] <gaspa> one-two one-two
[21:00] <gaspa> warp10: ok, the mike works...
[21:00] <warp10> Thank you highvoltage, and hi everybody, guys! Who is here to have great moments learning about QA stuff, raise your hand (in #ubuntu-classroom-chat, please)!
[21:02] <warp10> OK, great. I'm Andrea Colangelo, an Ubuntu Developer. BlackZ, gaspa and me from the Ubuntu Italian Mafia Famiglia [Copyright (C) Daniel Holbach] will try to show you that QA is not that boring at all, and rather it is a very appreciated activity in Ubuntu development.
[21:03] <warp10> In case you don't know already, QA means Quality Assurance, and it involves a number of procedures and tools aiming to keep Ubuntu packages and the whole archive in good shape.
[21:03] <warp10> Wrong or circular dependencies, packages that Fails To Build From Source (FTBFS) and that Not Build from Source (NBS) anymore, install and upgrade issues, fixing lintian errors: all of them are problems that QA activites are intended to fix.
[21:04] <warp10> QA is not focused on a particular set of packages, rather the whole archive is the domain of our activities. Therefore, a good committement to QA also gives you the possibility to increase your packaging knowledge and skills, and will allow you to reach the deeper and more obscure corners of the archive.
[21:04] <warp10> Further, a good QA also means working side-by-side with your fellow developers who packaged and/or cared of the package you are working on, and will give you that extraordinary feeling of "standing on the shoulders of giants" that new contributors well know.
[21:05] <warp10> And please, don't think QA involves Ubuntu only. Very often your fixes for Ubuntu issues apply to Debian too, and a good Ubuntu Developer is always ready to open reportbug and send patches upstream to Debian.
[21:05] <warp10> Therefore, QA and community are thigtly related, and a good QA will make all Ubuntu users happier. This is one among the many reasons why we like QA so much! :)
[21:05] <warp10> Since QA is such a wide and extensive field of activities, you will find *lot* of things to do, and *lot* of issues to fix anytime. But don't be scared: lots of tools have been deployed to help your efforts, tools that gaspa, BlackZ and me will try to show you in these remaining 55 minutes.
[21:06] <warp10> If you are really interested in QA, the website you will definitely want to add to your favourites is http://qa.ubuntu.com/. There you will find (almost) everything that is QA-related.
[21:06] <warp10> Lots of (hopefully) good words so far, but we still didn't saw anything. So, let's dirt our hands with something more pragmatic. But first of all: any question so far? (In -chat, please)
[21:07] <warp10> Ok, good. The first argument we will introduce is NBS. Who of you already knows what a NBS is? Raise your hands again (in -chat, please)!
[21:08] <warp10> Ok, great. NBS are one of the most appreciated QA activities, and the one I like most, personally. :)
[21:09] <warp10> NBS stands for "Not Built From Source". As you can easily understand, it refers to packages that, altough still in the archive, are no longer built from source.
[21:09] <warp10> You might wonder why such a situation could happen. Well, there is a number of different reasons. The most common one is that the package has been renamed.
[21:10] <warp10> For examble, upstream released a brand new release and renamed his software, so we may want to rename the package as well. Another possibility is that a library gets a new SONAME and this has to be reflected in the binary name.
[21:10] <warp10> (For people who don't know already, a SONAME is a sort of "name" describing what functionalities a certain library or piece of software exposes. See also: http://en.wikipedia.org/wiki/Soname.)
[21:11] <warp10> If there are packages that still depend on the NBS package, the NBS can't be removed from the archive, or it would cause an unmetdep (i.e.: a package is not installable because one of its dependency is missing from archives).
[21:11] <warp10> Our work as QA guys is to carefully check the situation and rebuild the packages depending on our NBS, so that their dependencies list is updated with the new package, and then we can drop the useless NBS from archives.
[21:12] <warp10> Feeling a little confused? Yeah, comprehensible. Don't worry: we will see some examples in a few seconds. Also, please refer to https://wiki.ubuntu.com/UbuntuDevelopment/NBS for a broader overview and more examples. And ask your questions anytime in -chat if needed, ok?
[21:12] <warp10> The most important thing to understand right now is that when you tackle a certain NBS you won't work on the NBS package itself (it's a zombie! It is going to be deleted from archives!), but rather on the packages depending on the NBS package, to make those packages not depend anymore on the zombie.
[21:13] <warp10> In fact, our final goal is to make sure that the NBS package has no reverse-dependencies (i.e.: no packages depending on it), making it a dead leaf we can drop with no pain from the archive.
[21:13] <warp10> A few tools are here to help you NBS, guys. The most important one is this page: http://people.canonical.com/~ubuntu-archive/NBS/
[21:13] <warp10> The full list of NBS waiting for love is there. It is updated about every 6 hours. As you see, every NBS is represented by a text file (named after the package name).
[21:14] <warp10> Let's open a NBS and see what's written there. For example, let's take libgss1: a pretty easy one. StraigLet's open a NBS and see what's written there. For example, let's take libgss1: a pretty easy one. Straight link is: http://people.canonical.com/~ubuntu-archive/NBS/libgss1ht link is: http://people.canonical.com/~ubuntu-archive/NBS/libgss1
[21:15] <warp10> This file contains informations about libgss1 reverse dependencies. In our case, two packages depend on libgss1 both on ia64 and sparc: libgss-dpg and libgss-dev. These two packages have to be rebuilt to drop the NBS.
[21:15] <warp10> You might be wondering why a simple rebuild is enough to fix everything. This happens thanks to the "{shlibs:Depends}" macro in debian/control who will link our package to the latest libraries available. In this case, it will drop the dependency on libgss1 and will link our packages to libgss3 (the brand new package who made libgss1 a NBS)
[21:16] <warp10> Let's see another example. Please, open libopensync0. As you see, this NBS has several reverse-dependencies that need to be updated. Anyway, don't despair. Very often, it's just a matter of rebuilding a few source packages that build several binary packages.
[21:17] <warp10> Let's go deeper in the matter with a third example. Please, open libv8-2.2.7: http://people.canonical.com/~ubuntu-archive/NBS/libv8-2.2.7.
[21:17] <warp10> As you see, there is just one package depending on libv8-2.2.7: it is nodejs on amd64, i386, and armel. Since (almost) everybody has either an i386 or amd64 machine, we can work on it.
[21:18] <warp10> Let's get some informations about nodejs. Let's download it from the archive and run dpkg -I on it: wget http://archive.ubuntu.com/ubuntu/pool/universe/n/nodejs/nodejs_0.1.97-1_i386.deb && dpkg -I nodejs_0.1.97-1_i386.deb | grep Depends
[21:18] <warp10> As you see, it depends on libv8-2.2.7 (but we already knew that). Right now, the archive has libv8-2.2.18 and we should rebuild nodejs against it
[21:19] <warp10> Therefore, let's apt-get source nodejs. We will not make anything special about it, except for updating the changelog. Actually, we won't add the standard "ubuntu1" after the debian revision, but will rather use "build1" to show that we didn't modified anything and this is just a rebuild.
[21:19] <warp10> Anyway, given that we are asking the build daemons to rebuild the whole package, this is a good occasion to do other maintainance around nodejs. For example, we could check if there are open bugs, if the package is lintian free or if it needs to be merged/synced from Debian.
[21:19] <warp10> In any case, once we are over with the modifications we need (if any), we have to rebuild the package with our favourite tool (e.g.: pbuilder) and after the standard Build-Install-Run test, we can upload it to archives, or ask a sponsor to do it for us.
[21:20] <warp10> Fixing a NBS isn't always that easy. Sometimes your package FTBFS, or there are other issues around that will make your life not easy. Don't forget that your fellow Ubuntu Developers are around and ready to help and assist you
[21:21] <warp10> Ok, everything clear so far? Is your mind all messed up with reverse-deps and NBS? :)
[21:21] <warp10> A final word about another tool the Good Old Gaspa made available for all of us. Please, head your browser to http://gaspa.yattaweb.it/issues/reverse_nbs.xml at maximum warp speed.
[21:22] <warp10> As you can easily understand from the name itself, this page allows you to tackle NBSs from the build-deps side. Rather than opening the NBS page and reading what package needs to be rebuilt, you here see what package depends on which NBSs (yes, even multiple ones)
[21:22] <warp10> This way, you can check the status of a particular package you are working on, and can easily understand if that package needs multiple transitions.
[21:23] <warp10> That page also shows some other interesting information, like the already done NBS (i.e.: ready to be dropped from archives), and lots of links to launchpad, packages.u.c, the NBS page on people.u.c, all with an eye-candy UI (altough gaspa should update it to the lucid's aubergine colour :))
[21:24] <warp10> Summarizing, NBSs are a nice, funny, and appreciated QA activities (we can't release Ubuntu if NBSs are around in the archives!) and you have at least two tools and 100+ Ubuntu Developers ready to help you.
[21:24] <warp10> Therefore, choose your favourite NBS and kill him rebuilding all of its reverse-deps! :)
[21:25] <warp10> And now, let's move to a completely different topic: FTBFS. Unless you have questions to ask in -chat, of course.
[21:25] <gaspa> :)
[21:26] <gaspa> First of all, presetation: hi everybody! I'm gaspa, MOTU, a python passionate (well, passionate of
[21:26] <gaspa> thousands of other things, but that's what matters),
[21:26] <gaspa> and then,let's talk about QA: as you may know, we have a lot of packages in ubuntu but not all of them were successfully built.
[21:27] <gaspa> When this happens we say that this package "Fails To Build From Source", but usually we use the acronym FTBFS for indicate that.
[21:27] <gaspa> A package can FTBFS for a lot of reasons, the most common reason is for its dependencies... for example some dependencies could have a different version than debian.
[21:28] <gaspa> what I said above is important: in fact if a package FTBFS in ubuntu it does not mean that it will FTBFS in debian...
[21:28] <gaspa> ( so we should often figth them with our forces ;) )
[21:29] <gaspa> but, of course, we have our tools that gives help: guess what? we havea list of packages that FTBFS, see http://qa.ubuntuwire.org/ftbfs
[21:30] <gaspa> the page lists all the packages, together with a lot of helpful informations, the arch that fails, links to LP and packages.debian.org pages....
[21:31] <gaspa> but the most important is the build log, that help us understand really what gone wrong!
[21:31] <gaspa> In the best case you just need to do a fresh build of it, or perhaps to update a single dependency...
[21:32] <gaspa> but other issues can happen too, of course...
[21:32] <gaspa> for example, another reason is that we have sometimes different compiling option from debian or upstream, for this kind of problems google helps greatly (search for the string that gives the error...)
[21:33] <gaspa> i.e. it happened with different versions of glibc between debian/ubuntu
[21:35] <gaspa> of course we have a lot of programming languages, every kind of language has different behavior and different problems... You can concentrate on your preferred language and find the package of that language.
[21:35] <gaspa> Last, but not the least, it can be an upstream bug: remember always to report them (together with the fix you found, of course), so the package will be updated in debian and then we can sync/merge it
[21:36] <gaspa> now, another kind of QA we can do... merges!
[21:36]  * gaspa throw the mike toward warp10
[21:37]  * warp10 grabs the microphone and reaches the center of the classroom
[21:38] <warp10> Ok, we all know Ubuntu is a debian-derived distro. This means we have the same packages too. We have a few procedures to update our packages from debian to ubuntu. We can do a sync if the package has no ubuntu changes, otherwise we need to merge all ubuntu changes for the new package from debian.
[21:38] <warp10> First of all we have to check if our ubuntu changes have been accepted in the debian package. We can sync the package only if *every* change in the ubuntu package has been accepted in the debian package too
[21:39] <warp10> Why do we need to do those changes? Well, for example we want to fix a bug in our ubuntu package which is not fixed yet in Debian, or we need to do ubuntu-*specific* changes.
[21:39] <warp10> Let's go ahead with merges. How can we merge a package? First of all we need to check the pending merges with MoM, a web application hosted on merges.ubuntu.com
[21:40] <warp10> Once we are there we will see the merges sorted from 4 components (universe, multiverse, main and restricted). In this session we will work on the pending merges of the universe component, so let's visit merges.ubuntu.com/universe.html
[21:40] <warp10> And please, don't forget to contact the latest uploader of the package (to prevent doubling the work).
[21:41] <warp10> You can do a merge in many ways: either manually, or with the grab-merge script. In this session we will use this second method.
[21:41] <warp10> Where can we download the grab-merge script? It has been included in the ubuntu-dev-tools package, so just install the ubuntu-dev-tools package.
[21:41] <warp10> Let's suppose we will work on the 'vlc' package, so type 'grab-merge vlc' and read the REPORT file for useful informations.
[21:42] <warp10> We will check the changelog of ubuntu and debian (let's suppose we have the version 1.0.5-1ubuntu1 and the version 1.0.6-1 in debian).
[21:42] <warp10> Imagine we have the ubuntu change * Add foobar to BD (LP: #123456). First of all, we will edit our debian/changelog file (changing the description of the change and replacing the mom signature with our own).
[21:42] <warp10> Then we will merge that change adding the BD foobar in debian/control
[21:43] <warp10> If you're unsure, don't forget you can visit patches.ubuntu.com and check with the latest debdiff (ubuntu+version.patch).
[21:43] <warp10> Once you are done you have to run ../merge-genchanges in the new, merged package, and then ../merge-buildpackage to check the package builds correctly.
[21:43] <warp10> If the package builds fine, you have to open a bug report in LP against the package with the summary: "Please merge vlc 1.0.6-1 (universe) from debian unstable (main) (if it's in debian unstable in the component 'main', of course)
[21:44] <warp10> Now, you can attach your debdiff to the bug report. Otherwise, you can use bzr to create a branch with your debdiff.
[21:44] <warp10> You're done! just subscribe ubuntu-sponsors and wait patiently. :)
[21:45] <warp10> As I said above, we can merge with bzr too. Let's see how that works.
[21:45] <warp10> First of all, we need to see if the package we want to merge has any failure http://package-import.ubuntu.com/status/
[21:45] <warp10> Let's suppose we want to merge vlc from debian sid again. Run: bzr merge-package lp:debian/sid/vlc
[21:46] <warp10> Then we need to run 'bzr status' and 'bzr diff' to check if there are conflicts or something else wrong
[21:46] <warp10> For example, if there are conflicts, you have to run bzr resolve and bzr conflicts, and  then you can do an entry in debian/changelog with the command dch -i
[21:46] <warp10> Now our branch is ready to be committed, but run bzr diff -r tag:1.0.6-1 first to check all ubuntu changes. You're done!
[21:47] <warp10> This concludes the part of this session about merges. The last quarter will be held from Good Old Gaspa who will talk about ubuntuwire
[21:47]  * warp10 throw the microphone back to gaspa
[21:47]  * gaspa 's not Old
[21:47]  * gaspa catch the mike with a double-back-flip
[21:48]  * warp10 but he his Good! \o/
[21:48] <gaspa> ok, warp10 already talked about http://qa.ubuntu.com....
[21:48] <gaspa> lol
[21:48] <gaspa> another resources I want to point all fo you is UbuntuWire... Ubuntuwire is a
[21:48] <gaspa> website that collect a lot of services that fit into the ubuntu community: lists, search, and a lot of QA resources.
[21:49] <gaspa> point your browsers to http://ubuntuwire.com
[21:49] <gaspa> Unfortunately there's no time to look in deep at each of them, but a look on the page above will give you a bit of taste.
[21:49] <gaspa> There are community driven resources, as well as Canonical ones. For example you already saw NBS (the first of Canonical resources), and the ftbfs page.
[21:50] <gaspa> Well, you'd already have a lot of material to look at, tonight ;)
[21:50] <gaspa> isn't it? :)
[21:50] <gaspa> Although, but I want to point you on a couple of these pages that I found
[21:50] <gaspa> particularly useful.
[21:50] <ClassBot> There are are 10 minutes remaining in the current session.
[21:51] <gaspa>  the first of them is the debcheck page: http://qa.ubuntuwire.org/debcheck/ This page lists all the package that aren't
[21:51] <gaspa> in good shape.
[21:51] <gaspa> from the point of view of their relationships (packages that feel alone, poor
[21:51] <gaspa> packages :) )
[21:51]  * warp10 chuckles
[21:51] <gaspa> If you give a fast look at that page, you'll see a lot of classes of issues: Broken Depends/Recommends/Suggests, Build-Depends, HalfBroken, Packages in Main with depends on !Main...AWESOME, we'll have a lot of work!! :)
[21:52] <gaspa> As you can see, pages are grouped by issue, but if you select a single package, you'll see a lot of issues for only one! So, you can make the package shine resolving a lot of problems. [well, to be honest, often a lot of issues are caused by a single problem, so it's probably easier to fix them in a while)
[21:52] <gaspa> example! let's take a look at a single package:
[21:52] <gaspa> http://qa.ubuntuwire.org/debcheck/debcheck.py?dist=maverick&package=anjal
[21:53] <gaspa> you can see that "Package declares a build time dependency on evolution-plugins (<< 2.29.0) which cannot be satisfied on ia64. evolution-plugins (<< 2.29.0) 2.30.1.2-3ubuntu1 is available." So, anjal depends on evolution-plugins << 2.29.0, but we have 2.30 in maverick!
[21:53] <gaspa> What should we do!?
[21:54] <gaspa> Of course this issue could be caused by some different reasons. One could be simply a build-dependency that need to be updated.... is this the case? [ Hint: why there's a '<<' on the build-dependency and not a "<=" ?? ]
[21:54] <gaspa> oh, another possibility is that anjal depends on a feature that's present on evolution-plugins in 2.29, but is moved on another package from 2.29 and so on...
[21:55] <gaspa> note that *I don't know the real answer*, so perhaps it's worth a rebuild on your ppa and test the package with only a version dump.
[21:55] <ClassBot> There are are 5 minutes remaining in the current session.
[21:56] <gaspa> we can look at how behave the build in your ppa, and let's proceed in the right direction
[21:56] <gaspa> thanks, ClassBot.
[21:56] <gaspa> Little hint: If you have doubts, well, you can always take a look at Debian packages... they should be always your reference [in particular seems this package does not have a debian maintainer... any volunteer in here? :) ]
[21:56] <gaspa> :)
[21:57] <gaspa> Another thing that you should remember (haven't said it yet??) is to keep in contact with upstream, when possible...
[21:57] <gaspa> asking upstream is perhaps a bit longer than resolve problems ourselves, but have the advantage that tipically upstream knows better the software in case :)
[21:57] <gaspa> Ok, we met debcheck. Keep in mind that you can run itself on your PCs,it's enough to install edos-distcheck and make it runs :)
[21:57] <gaspa> for example, I did on my own and I publish sometimes the results:
[21:58] <gaspa> http://gaspa.yattaweb.it/issues/issues/edos/lucid_i386_edosresults.xml
[21:58] <gaspa> ( i didn't do any run for maverick, yet... :P I'll do one soon, I promise! )
[21:58] <gaspa> ok, I wanted to cite Harvest, but there's no time, I guess...
[21:59] <warp10> gaspa: I suppose we can steal a few more minutes, if needed
[21:59] <gaspa> so, just some time for question...
[21:59] <gaspa> warp10: if ClassBot wont shut up us :)
[22:00] <warp10> gaspa: don't think so. He is such a good boy :)
[22:00] <gaspa> ok :)
[22:00] <gaspa> let's try ;)
[22:00] <gaspa> I'll be brief: the approach we got  till now, is something like "take a kind of bug and fix as many package as you can"
[22:00] <gaspa> merges, ftbfs, nb...
[22:00] <gaspa> This is handful sometimes, expecially when you want to became experienced on something in particular
[22:01] <gaspa> But, have you noted that every of these pages/tools we showed so far differs, is in a different place from the others? well, wouldn't be more efficient to take a package and fix all the problem of that package? So, for this kind of QA,dholbach build Harvest
[22:01] <gaspa>  Harvest's aim is to centralize a lot of these lists of bugs, and show them in a comfortable way, and makes us able to fix a lot of bugs of a single package without searching here and there in the internet :) ... so, it makes us *really* happy :)
[22:02] <gaspa> I can't show you as daniel is working hard with a GSoC student to get it back more cool, usable, extensible, and whatever :P... but STAY TUNED on the link at the qa.ubuntu.com page :)
[22:02] <gaspa> ok, finished. ;) thanks and sorry for taking a bit of other time :)