[07:25] <magnus> hello
[11:12] <annma> hello people
[11:12] <annma> anyone already in Boston?
[11:13] <annma> jcastro: ping
[13:37] <kiri> w007!!?
[13:37] <AstralJava> netsplit
[14:58] <bonii> @now
[14:58] <ubotu> Current time in Etc/UTC: October 26 2007, 13:58:18 - Next meeting: Kernel Team in 4 days
[16:02] <Ertorito> Hola !
[16:08] <Ertorito> Hola, hay alguien ahi?
[16:11] <dgjones> isn't there due to be a session on now?
[16:11] <mrevell> dgjones: There is. I'm trying to track down the person who is due to give it.
[16:12] <dgjones> rite, wondered what was happening
[16:13] <dgjones> mrevell, do you mind a quick pm?
[16:13] <mrevell> dgjones: Not at all
[16:13] <bahadunn> no classes today?
[16:14] <mrevell> bahadunn: There will be as of 16.00 UTC.
[16:14] <bahadunn> what time is it now in UTC?
[16:14] <bahadunn> 15:00?
[16:15] <gotiniens> @now
[16:15] <mrevell> It's 15.15 in UTC
[16:15] <bahadunn> thought so
[16:15] <bahadunn> ok thanks
[16:15] <bahadunn> I guess I could have looked at the schedule
[16:15] <bahadunn> oh well
[16:15] <bahadunn> sorry for wasting you guys time
[16:15] <mybunche> we are here anyways
[16:16] <FayZee_> The schedule on https://wiki.ubuntu.com/UbuntuOpenWeek doesn't say it's canceled. Is it tehn?
[16:16] <bahadunn> the new ubuntu looks nice
[16:16] <bahadunn> got it running in qemu
[16:17] <bahadunn> first one to successfully run in qemu for me
[16:17] <FayZee_> bahadunn: what problems did you have with other distros in qemu?
[16:18] <bahadunn> FayZee_: some funky error that I cannot recall
[16:18] <FayZee_> bahadunn, did you try Mandriva Spring 2007 or even the lately released 2008?
[16:19] <bahadunn> FayZee_: no
[16:19] <bahadunn> FayZee_: I have strong hate for mandriva
[16:20] <bahadunn> FayZee_: debian runs fine on the qemu and also debian/kfreebsd runs fine on the qemu
[16:20] <mrevell> Hi guys - could you move chat to the -chat channel please?
[16:21] <FayZee_> So is Launchpad Personal Package Archives officially  canceled/postponed?
[16:21] <FayZee_> Sorry
[16:21] <mrevell> FayZee_: I'm going to set it as cancelled. Unfortunately, I can't find the person who was due to give it.
[16:36] <jcastro> annma: hi
[16:37] <annma> jcastro: hi
[16:37] <annma> jcastro: my plane was cancelled
[16:37] <annma> I could not even reach Paris
[16:37] <jcastro> yikes!
[16:37] <annma> big strike in France
[16:37] <annma> I mailed the travel agency but it looks I won't make it
[16:37] <jcastro> :(
[16:45]  * Hobbsee waves
[16:45]  * DShepherd waves
[16:48] <Hobbsee> Hey all, it seems like the session got cancelled, but if you have questions about ppa's, some of us around should be able to answer them.
[16:49] <Hobbsee> wont be a normal session, i know.  but it seems that some people have turned up.
[16:50] <evarlast> is it possible to have a team ppa just be an aggregate of its members ppa?
[16:51] <Hobbsee> I dont think so.
[16:51] <DShepherd>  is there a limit on the amount of space one is allotted for a ppa?
[16:51] <PriceChild> DShepherd, about a Gb or so i "think" but it can be enlarged on request.
[16:52] <Hobbsee> DShepherd: it appears to be 1gb, but I dont think they've done the quotas yet, as people can't remove things.
[16:52]  * DShepherd goes to check the size of assault cube
[16:55] <kostkon> do you think it's OK for a project to be "served" only through a PPA or should better opt to be included in the official repositories nad use the PPA only for testing (and other) purposes?
[16:55] <brobostigon> when is the mythbuntu session?? its 16:55 pm at the moment.
[16:55] <Hobbsee> @now utc
[16:56] <Hobbsee> brobostigon: 2 hours
[16:56] <stdin> kostkon: well PPA's are still in beta, and aren't 100% reliable yet. but it should be OK for a small project
[16:56] <brobostigon> so 19:00 pm
[16:56] <ubotu> Current time in Etc/UTC: October 26 2007, 15:55:51 - Next meeting: Kernel Team in 4 days
[16:56] <Hobbsee> kostkon: if you put it into the official repositories, you're going to be able to reach everyone - whereas if you only have it in a ppa, they have to manually edit the lines of their sources list, to include the repository.
[16:56] <Hobbsee> kostkon: for that reason, you're probably better off putting it into ubuntu.
[16:57] <Hobbsee> kostkon: but, either works.  As for speeds and such for downloading, I couldn't tell you.
[16:58] <Hobbsee> any more questions?
[17:00] <PriceChild> Can I have a pony?
[17:00] <mrevell> PriceChild: Yes, but only if you wash the dishes
[17:01] <Hobbsee> PriceChild: no.
[17:01] <mrevell> Okay, are you ready to rock? Or at least to have a session about Launchpad Translations?
[17:01] <Hobbsee> @pony | PriceChild
[17:01] <Hobbsee> mrevell: sounds good. over to you :)
[17:01] <mrevell> :)
[17:01] <mrevell> Hello! My name is Matthew Revell and I work for Canonical as part of the Launchpad team.
[17:02] <mrevell> Welcome to this session, which is all about one of Launchpad's applications, Translations.
[17:02] <mrevell> I'm going to introduce you to Launchpad Translations and tell you:
[17:02] <mrevell> * what it does
[17:02] <mrevell> * how it works
[17:02] <mrevell> * a little about how Ubuntu uses it.
[17:03] <mrevell> I'll also be pleased to take your questions at the end of the session.
[17:03] <mrevell> However, the developers who work on Launchpad Translations are in a high intensity sprint right now, so I may have to pass on some questions. That's not to say you won't get an answer!
[17:04] <mrevell> But I may ask you to mail me
[17:04] <mrevell> Most week days you can find me as mrevell on Freenode. I hang out in #launchpad.
[17:04] <mrevell> You can also email me - matthew.revell@canonical.com.
[17:04] <mrevell> You can get in touch with the Launchpad team by sending an email to feedback@launchpad.net
[17:05] <mrevell> Okay, so let's get going!
[17:05] <mrevell>  
[17:05] <mrevell> A quick overview of Launchpad Translations
[17:05] <mrevell> -------------------------------------------
[17:05] <mrevell>  
[17:05] <mrevell> One of the great advantages that the open source development model gives us is that it's relatively easy for people who use software to translate it into their own language.
[17:06] <mrevell> Much free software uses GNU GetText for localisation.
[17:06] <mrevell> Developers put markers in their code to show where a GetText should insert strings of interface text.
[17:06] <mrevell> So, if I'm using some software in Spanish, GetText will insert the appropriate Spanish interface text.
[17:07] <mrevell> If, however, I'm using Hindi, GetText will insert the Hindi text.
[17:07] <mrevell> GetText has a simple file format where people can specify which text should be presented for each language.
[17:07] <mrevell> All that a translator needs to know is what the original English text means and how to translate it into their own language.
[17:08] <mrevell> However, this way of working means that translators need to download each GetText file and work alone.
[17:09] <mrevell> It also means that translators have to work like coders - they need to learn how to use GetText's file format, they may need to learn how to use whatever version control system the project uses and, in many cases, get write access to it.
[17:09] <mrevell> Launchpad Translations takes the pain out of translating software into different languages.
[17:09] <mrevell> Using a simple web interface, it makes it easy for people to translate just one line of text (what Launchpad Translations calls a string) or take an entire project and translate it into their language.
[17:10] <mrevell> It can import and export GetText's file formats, making it ideal for translating a huge number of free software projects.
[17:10] <mrevell> It can even make suggested translations.
[17:10] <mrevell>  
[17:11] <mrevell> People power
[17:11] <mrevell> ------------
[17:11] <mrevell>  
[17:11] <mrevell> Right now, Launchpad Translations has:
[17:11] <mrevell>  
[17:11] <mrevell> * 25,223 translators
[17:12] <mrevell> * working 243 languages
[17:12] <mrevell> * with 833,733 strings of translated text.
[17:12] <mrevell>  
[17:12] <mrevell> It's probably fair to say that more people are working to translate free software using Launchpad than in any other single way.
[17:12] <mrevell> This brings with it huge advantages, both for Ubuntu and the other projects using Launchpad for translations.
[17:12] <mrevell> For example...
[17:12] <mrevell> When the Jokosher audio editor started using Launchpad for translations, the Jokosher team didn't actually tell anyone.
[17:12] <mrevell> They simply put their translation templates online in Launchpad and left them.
[17:12] <mrevell> Within a couple of weeks they had translation efforts in 18 different languages!
[17:13] <mrevell> The community of translators using Launchpad is large but, also, Launchpad makes it incredibly easy to translate software.
[17:13] <mrevell>  
[17:13] <mrevell> Simple web interface
[17:13] <mrevell> --------------------
[17:13] <mrevell>  
[17:13] <mrevell> Let's take a look at Ubuntu's page in Translations:
[17:13] <mrevell>  
[17:13] <mrevell> https://translations.launchpad.net/ubuntu
[17:13] <mrevell>  
[17:14] <mrevell> Straight away, if you're looking to translate parts of Ubuntu into your language you can see how much work needs to be done for Gutsy.
[17:14] <mrevell> Let's pick Esperanto:
[17:14] <mrevell>  
[17:14] <mrevell> https://translations.edge.launchpad.net/ubuntu/gutsy/+lang/eo
[17:14] <mrevell>  
[17:14] <mrevell> You can see various different packages in Gutsy and how well translated into Esperanto they are.
[17:14] <mrevell>  
[17:14] <mrevell> Green, purple and light blue all represent translated text.
[17:15] <mrevell> Red means that there's still work to be done.
[17:15] <mrevell> Now, you can find which Gutsy package needs you most and dive in!
[17:15] <mrevell> You see that most of "yelp" has been translated but not quite all.
[17:15] <mrevell> Let's dive in and have a look and what needs to be done.
[17:15] <mrevell>  
[17:15] <mrevell> https://translations.launchpad.net/ubuntu/gutsy/+source/yelp/+pots/yelp/eo/+translate?batch=10&show=untranslated
[17:15] <mrevell>  
[17:15] <mrevell> These are all the "yelp" strings that remain untranslated in Esperanto.
[17:15] <mrevell>  
[17:15] <mrevell> As you can see, Launchpad shows you the English and gives you a text box in which to make the Esperanto translation.
[17:16] <mrevell> At the top is "Page not found".
[17:16] <mrevell> If we knew the Esperanto equivalent for that phrase, we could type it in, scroll to the bottom of the page and click "Save and continue".
[17:16] <mrevell> Simple!
[17:17] <mrevell>  
[17:17] <mrevell> Suggestions
[17:17] <mrevell> ------------
[17:17] <mrevell>  
[17:17] <mrevell> As you probably realise, the same phrases crop up in software quite often.
[17:17] <mrevell> Take a look at the fourth translation down on the page we've just been looking at:
[17:17] <mrevell> "File not found"
[17:17] <mrevell> There isn't a translation yet for the "yelp" package but Launchpad has seen "File not found" translated into Esperanto before.
[17:17] <mrevell> So, it makes a suggestion.
[17:17] <mrevell> In fact, it makes several and tells us which package each comes from and who made the translation.
[17:18] <mrevell> Ne trovis dosieron - Used in kbabel in Ubuntu Dapper package "kdesdk" by Donald Rogers  on 2007-07-30
[17:18] <mrevell> Netrovita dosiero - Used in gqview in Ubuntu Gutsy package "gqview" by Antonio Codazzi (la Filozofo)  on 2007-06-11
[17:18] <mrevell> ERARO: dokumento ne trovita -  	 Used in koffice in Ubuntu Gutsy package "koffice" by Steffen Pietsch  on 2006-04-21
[17:18] <mrevell> Dosiero ne trovita: -  	 Suggested in ooo-basic in Ubuntu Breezy package "openoffice.org2" by Leo  on 2006-03-20
[17:18] <mrevell>  
[17:18] <mrevell> Now, I can decide which of these I want to use and judge which one might be best according to where it was used and who made the translation.
[17:18] <mrevell>  
[17:18] <dayanandasaraswa> hi
[17:19] <mrevell> Translation teams
[17:19] <mrevell> -----------------
[17:19] <mrevell>  
[17:19] <mrevell> Ubuntu has a number of translations teams.
[17:19] <mrevell> This is controlled using something we call 'Translation Groups'.
[17:19] <mrevell> You can see Ubuntu's translations groups at:
[17:20] <mrevell> https://translations.launchpad.net/translations/groups/
[17:20] <mrevell> This provides a mapping between languages and the teams that translate are responsible  for translating them.
[17:20] <mrevell> Translation teams look after the QA of translations.
[17:20] <mrevell> Members of translation teams should *only* be trusted translators: they will have full power over translations for that language, and you should NOT let anyone in.
[17:21] <mrevell> Some upstreams have complained about bad translations, and most of them were due to badly managed teams (i.e. teams allowing anyone in). So, be strict about who you let in :)
[17:21] <mrevell> At the moment, to organise work you need to coordinate outside Launchpad: use mailing lists, IRC, Jabber or whatever.  We will be solving this.
[17:22] <mrevell> When you make a translation on an Ubuntu package, most of the time you're actually making a suggested translation.
[17:22] <mrevell> A member of the appropriate translation team will then approve or decline your text.
[17:22] <edenbeast> ja, in opleiding maakt dat toch nog geen zak uit want ge doet toch niks
[17:22] <mrevell> This makes sure that anyone can get involved, with minimal effort, but helps maintain the quality and consistency of translations.
[17:23] <mrevell> However, if you are a member of the translation team you can submit translations directly.
[17:23] <mrevell>  
[17:23] <mrevell> Future
[17:23] <mrevell> ------
[17:23] <mrevell>  
[17:23] <mrevell> We've got big plans for the future, and some of the priorities are the following:
[17:23] <mrevell>  
[17:23] <mrevell> Search for translations (yes, infamous bug 44 in LP)
[17:23] <mrevell> Native support for other translation formats (Mozilla, OpenOffice.org...)
[17:23] <mrevell> Improved mechanisms for upstream cooperation
[17:24] <mrevell> Make team management more flexible and powerful
[17:24] <mrevell> We welcome suggestions on what should we focus on!.
[17:24] <mrevell>  
[17:24] <mrevell> Trivia and tips
[17:24] <mrevell> ---------------
[17:24] <mrevell>  
[17:25] <mrevell> This section comes from our the Launchpad Translations developers and it's their tips and tricks for using LP Translations.
[17:25] <mrevell> When uploading, choose 'Published upload' if you don't want to override others' translations that have happened in the meantime.
[17:25] <mrevell> You can download PO files to find a specific string in it (many have done this already)
[17:26] <mrevell> For Ubuntu, start translating from the top of https://translations.beta.launchpad.net/ubuntu/feisty/+lang/sr (for Serbian): they are sorted by priority.
[17:26] <mrevell> Sorry, that URL should be:
[17:27] <mrevell> https://translations.launchpad.net/ubuntu/feisty/+lang/sr
[17:27] <mrevell> Don't forget to update Last-Translator field when translating via PO files, and also never remove or change X-Rosetta-Export-Date field from PO header (or you won't be able to re-import it).
[17:27] <mrevell> Use Google with "site:translations.launchpad.net" to search for strings as a workaround.  This will commonly give you pointer to someone's translations page, but you can pick a template name from there, visit it, and switch over to your own language.
[17:27] <petrovicivan> regards from Serbia
[17:27] <mrevell> You can use [nbsp] to get non-breaking spaces if you've got problems inserting them directly (Firefox is known to be buggy with them).
[17:28] <mrevell> No need to email us back with 'thank you' for automatic exports (though, we indeed appreciate those :).
[17:28] <mrevell> When you get message that your language is missing plural forms, either email us at feedback@launchpad.net, or file a ticket using https://answers.launchpad.net/rosetta/
[17:29] <mrevell>  
[17:29] <mrevell> Finding out more about Launchpad
[17:29] <mrevell> -----------------------
[17:29] <mrevell>  
[17:29] <mrevell> #launchpad here on Freenode is where you can find Launchpad developers.
[17:30] <mrevell> The launchpad-users list is also a great place to discuss Launchpad, get help from members of the team and make suggestions.
[17:30] <mrevell> You can sign up at:
[17:30] <mrevell> http://lists.ubuntu.com/mailman/listinfo/launchpad-users
[17:31] <mrevell> There's documentation at: help.launchpad.net - I'm personally working on that and appreciate any suggestions you may have.
[17:31] <mrevell> And if you want to get to try out new Launchpad features before anyone else, you can join the Launchpad Beta Testers team. Here's a guide for signing up:
[17:31] <mrevell> https://help.launchpad.net/JoiningLaunchpadBetaTesters
[17:31] <mrevell>  
[17:32] <mrevell> Well, I seem to have finished somewhat early. So, if you have any questions, please fire away! Although, as I say, the Translations developers aren't available at the moment, so I may have to come back to you with answers.
 QUESTION: How do you solve conflicts between translations in LP and those of upstream?
[17:35] <mrevell> samgee: For Ubuntu packages, translations made in Launchpad take priority. We don't send translations upstream automatically, although they can of course export translations from Launchpad. Better coordination with upstreams is an area that we're going to work on over the coming months, I believe.
 Question: Is there a list of file formats that can be converted to .po files?
[17:38] <mrevell> spd106: I'm told that the best place to start is the Translate Toolkit at http://translate.sourceforge.net/
[17:39] <mrevell> Any more questions?
 QUESTION: Do translation for each release stop after 18 months? What about LTS?
[17:41] <mrevell> spd106: You can continue with translation so long as the Ubuntu release is supported.
[17:49] <mrevell> Thank you everyone for attending this session. I'll be back at the top of the hour for the BLueprint session. Right now, I need to go get a drink, so I'll see you in 11 minutes!
[17:50] <mybunche> Thanks mrevell.
[17:53] <PriceChild> mrevell, are you doing "Planning features and sprints in Launchpad" as well?
[17:55] <mrevell> PriceChild: I am
[17:55] <PriceChild> cool :)
[18:00] <mrevell> Right, who's ready to rock?
[18:00] <mrevell> Etc
[18:00] <mrevell> :)
[18:01] <mrevell> Hello! My name is Matthew Revell and I work for Canonical as part of the Launchpad team.
[18:01] <mrevell> Welcome to this session, which is all about one of Launchpad's applications, Blueprint.
[18:01] <mrevell> I'm going to introduce you to Blueprint and tell you:
[18:01] <mrevell> * what it does
[18:01] <mrevell> * how it works
[18:01] <mrevell> * a little about how Ubuntu uses it.
[18:02] <mrevell> I'll also be pleased to take your questions at the end of the session.
[18:02] <mrevell> Before I continue, I want to let you know how you can get in touch with me and the Launchpad team.
[18:02] <mrevell> Most week days you can find me as mrevell on Freenode. I hang out in #launchpad.
[18:03] <mrevell> You can also email me - matthew.revell@canonical.com.
[18:03] <mrevell> You can get in touch with the Launchpad team by sending an email to feedback@launchpad.net
[18:03] <mrevell> Okay, so let's get going!
[18:03] <mrevell>  
[18:03] <mrevell> What is a blueprint?
[18:03] <mrevell> ---------------------
[18:03] <mrevell>  
[18:03] <mrevell> In the design of physical objects, a blueprint is a plan of action.
[18:03] <mrevell>  
[18:04] <mrevell> It takes the ideas of an individual or group of people and turns them into dimensions, angles, materials and so on.
[18:04] <mrevell>  
[18:04] <mrevell> A blueprint in Launchpad is similar: it helps individuals and groups of people to tell the world about an idea, a new feature or an entirely new project.
[18:05] <mrevell> The important difference between a traditional blueprint and the blueprints in Launchpad is that Launchpad's blueprints don't end with publication.
[18:05] <mrevell> Instead, a blueprint in Launchpad tracks the progress of an idea from conception to implementation.
[18:05] <mrevell> Sound complicated?
[18:05] <mrevell> Don't worry: it's not at all :)
[18:05] <mrevell> We've designed Blueprint - the Launchpad application - to be as simple as possible.
[18:06] <mrevell> If all you want is to write a few sentences describing your idea and then publish it, you can do that with Blueprint.
[18:06] <mrevell> If, however, you want to:
[18:06] <mrevell>  
[18:06] <mrevell> * track who is responsible for implementation and approval
[18:06] <mrevell> * link the blueprint to a branch of code that implements it
[18:06] <mrevell> * target your blueprint to a particular software release
[18:06] <mrevell> * track the dependencies required for your blueprint's implementation
[18:06] <mrevell> * and more....
[18:06] <mrevell>  
[18:06] <mrevell> ...then Launchpad Blueprint can help you with those too.
[18:06] <mrevell>  
[18:07] <mrevell> Blueprint doesn't force any particular project management methodology on you. Instead, it allows you to use however much or little you want.
[18:07] <mrevell>  
[18:07] <mrevell> Let's take a closer look
[18:07] <mrevell> ------------------------
[18:07] <mrevell>  
[18:07] <mrevell> Each Blueprint belongs to a particular project.
[18:07] <mrevell> That means you can see lists of all the ideas, proposals or suggestions that are "out there" for a given project.
[18:08] <mrevell> For example, Ubuntu has more than 1,000 such blueprints, in various states of completion or discussion:
[18:08] <mrevell> https://blueprints.launchpad.net/ubuntu
[18:08] <mrevell>  
[18:08] <mrevell> Each Blueprint has a priority, a "definition" status, and a "delivery" status.
[18:08] <mrevell>  
[18:08] <mrevell> Anybody can contribute Blueprints for any project - there is no way to prevent someone from posting their ideas.
[18:09] <mrevell>  
[18:09] <mrevell> However, the project leaders can set the priority - which means the extent to which they endorse the idea, or think it is important to implement soon.
[18:09] <mrevell> The "definition" status tells you whether or not the project has reached consensus on how the idea should be implemented.
[18:09] <mrevell>  
[18:10] <mrevell> In some projects there will be a person, or team of people, who will approve the plan.
[18:10] <mrevell> In others, plans are considered unnecessary or harmful, so this value is less important.
[18:10] <mrevell> In Ubuntu, they try to have a senior contributor review and approve any significant piece of work that is planned for any given release.
[18:10] <mrevell> Of course, lots happens without these plans, but it does give some certainty that the various plans gel well, and that people have thought about the most important issues before they commit to getting something done in a particular release.
[18:10] <mrevell>  
[18:11] <mrevell> Finally, the "delivery" status is all about implementation and execution.
[18:11] <mrevell> It tells you whether the work has been done, or whether it is on track to be done.
[18:11] <mrevell> Each blueprint also has a:
[18:11] <mrevell>  
[18:11] <mrevell> * "Drafter" - the person who is responsible for setting out the idea
[18:11] <mrevell> * "Assignee" - the person who is going to implement the ideas set out in the blueprint
[18:11] <mrevell> * "Reviewer" - the person who'll check the work on the blueprint.
[18:11] <mrevell>  
[18:12] <mrevell> You can see these in the top right of the page, alongside the implementation status, priority and a definition.
[18:12] <mrevell> Where to put the details
[18:12] <mrevell> -------------------------
[18:12] <mrevell>  
[18:12] <mrevell> Launchpad itself only contains a summary of the Blueprint - usually just the introductory paragraph - and then a URL to the location of the real document.
[18:12] <mrevell>  
[18:13] <mrevell> In some cases, the single paragraph (or sentence) is enough, but it's more typical to keep the full document in a wiki, where members of the community can easily collaborate.
[18:13] <mrevell>  
[18:13] <mrevell> Just having a list of proposals and ideas in one place is useful, even if, as in the case of Ubuntu, there are clearly many more ideas than developers!
[18:13] <mrevell>  
[18:13] <mrevell> It's convenient to be able to point new members of the community at a single place where those ideas are catalogued and to allow people to gravitate towards the pieces they are most interested in.
[18:13] <mrevell>  
[18:13] <mrevell> People can subscribe to Blueprints and get notifications when their status changes and even when the wiki document they are in is updated.
[18:13] <mrevell>  
[18:14] <mrevell> Newcomers can easily see which ideas are important to the project leaders, and which are not, so they can choose to focus their contributions on those pieces most likely to be accepted into the project.
[18:14] <mrevell>  
[18:14] <mrevell>  
[18:14] <mrevell> Linking blueprints
[18:14] <mrevell> ------------------
[18:14] <mrevell>  
[18:14] <mrevell> Launchpad allows you to link a blueprint and a bug, or a blueprint and a branch of code.
[18:14] <mrevell>  
[18:15] <mrevell> This allows people to see how pieces of work relate to one another.
[18:15] <mrevell>  
[18:15] <mrevell> It's very useful, for example, to be able to see the code that implements a blueprint evolving over time.
[18:15] <mrevell> It's also possible to link blueprints to one another, indicating rough dependencies.
[18:16] <mrevell> This lets you map out the order in which pieces of work should be implemented.
[18:16] <mrevell>  
[18:16] <mrevell> Let's take a look at an example of the dependency chart that Launchpad produces:
[18:18] <mrevell> https://blueprints.launchpad.net/ubuntu/+spec/printer-sharing
[18:18] <mrevell> This is a very simple example. This particular blueprint depends on one other. The current blueprint is shown in red. The other blueprint is in grey, which shows that it has been implemented.
[18:18] <mrevell>  
[18:19] <mrevell> Release management
[18:19] <mrevell> ---------------
[18:19] <mrevell>  
[18:19] <mrevell> The most useful aspect of Launchpad's blueprint tracker, however, is the ability to group  the blueprints that describe chunks of work that the project thinks are important to track for the next major series.
[18:19] <mrevell>  
[18:20] <mrevell> Here's the list for Gutsy:
[18:20] <mrevell> https://blueprints.launchpad.net/ubuntu/gutsy
[18:20] <mrevell>  
[18:20] <mrevell> These are blueprints that have been reviewed by the team
[18:21] <mrevell> and that they  agreed should be worked on during the Gutsy cycle.
[18:21] <mrevell> In general, about 80% of the planned feature goals have landed in each Ubuntu release.
[18:21] <mrevell> Ubuntu choose to ship on time, rather than necessarily waiting till every feature lands. However, different projects can adopt different release management goals.
[18:22] <mrevell> The important thing, of course, is that everyone can see where the project stands on any particular item.
[18:22] <mrevell> Sometimes you may want to group just the blueprints that are relevant for an interim release. For that, Launchpad has what we call milestones.
[18:23] <mrevell>  
[18:23] <mrevell> Milestones
[18:23] <mrevell> ------------
[18:23] <mrevell>  
[18:23] <mrevell> We've discussed projects and series, which are the major ways in which we keep track of the progress of a free software project in Launchpad.
[18:23] <mrevell>  
[18:24] <mrevell> Milestones are a very lightweight way to organise a group of bugs or blueprints.
[18:24] <mrevell> A milestone is a point in time, or a test release, for which you need to keep track of a few bugs or blueprints.
[18:24] <mrevell>  
[18:24] <mrevell> In Launchpad, you can easily create a milestone, and then link bugs or blueprints to that milestone as a way of saying "we think these items are worth keeping track of as we get closer to that date".
[18:24] <mrevell>  
[18:25] <mrevell> Here's an example milestone. It's the 1.1.11 milestone for the whole Launchpad project and is what we're working on now, due for release in November:
[18:25] <mrevell> https://launchpad.net/launchpad/+milestone/1.1.11
[18:25] <mrevell>  
[18:26] <mrevell> As you can see on that page, there are a number of blueprints targeted against the milestone, just as there were earlier when we look at Gutsy's blueprints.
[18:27] <mrevell> In the Launchpad team, we make a new release every four to five weeks. This means that we're making iterative improvements to Launchpad quit frequently. So, each release isn't a major release.
[18:28] <mrevell> Bug<--->Blueprint links
[18:28] <mrevell> -----------------------
[18:28] <mrevell>  
[18:28] <mrevell> Earlier, I menetioned that you can link bugs and blueprints.
[18:28] <mrevell> Let's take a look at the Bazaar project for an example.
[18:29] <mrevell> https://code.launchpad.net/bzr/
[18:29] <mrevell>  
[18:30] <mrevell> This is a list of all the branches of the Bazaar project that Launchpad knows about.
[18:30] <mrevell> Scroll down and you'll see three types of icon beside the branch names:
[18:30] <mrevell> * A small bug.
[18:30] <mrevell> * A warning triangle.
[18:30] <mrevell> * Some blue papers.
[18:30] <mrevell>  
[18:31] <mrevell> That last one is indicates that the branch is linked to a blueprint.
[18:31] <mrevell>  
[18:31] <mrevell> Sprints and meetings
[18:31] <mrevell> -------------------
[18:31] <mrevell>  
[18:32] <mrevell> Many free software projects use real-world meetings to thrash ideas or as development sprints.
[18:32] <mrevell> Launchpad helps you to organise such meetings and use a list of blueprints as the meeting's agenda.
[18:33] <mrevell> Ubuntu's six-monthly Ubuntu Developer Summits are an ideal example of such a meeting.
[18:33] <mrevell> Let's take a look at what's planned for next week's UDS in Cambridge, Massachusetts.
[18:34] <mrevell> https://launchpad.net/sprints/uds-boston-2007
[18:34] <mrevell>  
[18:35] <mrevell> Using the two panels in the left-hand sign of the page, you can see when the meeting is, who's organising it and who is attending.
[18:35] <mrevell> You can also sign yourself up as an attendee.
[18:35] <mrevell> In the central part of the page is a "full current agenda" link, which takes us to:
[18:35] <mrevell> https://launchpad.net/sprints/uds-boston-2007/+specs
[18:35] <mrevell> These are all the blueprints that are due for discussion at UDS Boston.
[18:36] <mrevell> Again, this is another example of Launchpad Blueprint offering a very simple solution to a common problem in planning a free software project.
[18:36] <mrevell>  
[18:36] <mrevell> That's all folks
[18:36] <mrevell> --------------
[18:36] <mrevell>  
[18:36] <mrevell> So
[18:37] <mrevell> I'll be very happy to take your questions now, if you have any.
[18:37] <mrevell> Please paste them in the #ubuntu-classroom-chat channel.
[18:37] <mrevell> Alternatively, please mail me - feedback@launchpad.net
[18:37] <mrevell> I'd also like to invite you to join us on the launchpad-users list:
[18:37] <mrevell> http://lists.ubuntu.com/mailman/listinfo/launchpad-users
[18:38] <mrevell> You can come along to our developer meetings in #launchpad at 14.00 UTC every Thursday.
[18:38] <mrevell> And if you want to find out more about what we've got planned for Launchpad, join the Launchpad Beta Testers team at:
[18:38] <mrevell> https://launchpad.net/~launchpad-beta-testers/+members
[18:39] <mrevell> No questions?
[18:39] <mrevell> Okay, well, thank you for joining me today. Goodnight!
[18:40] <mzungu> mrevell, thanks
[18:40] <samgee> thanks, matt
[18:40] <brobostigon> thanks
[18:57] <habitantee> hola comunidad
[18:57] <habitantee> tengo problemas al al actulizarme
[18:58] <superm1> @date chicago
[19:00] <superm1> Hi everyone, my name is Mario Limonciello, and I'm leading the Mythbuntu effort.
[19:00] <superm1> I'm assuming that everyone attending here today has at least heard of Mythbuntu.  In case you haven't though, I'd recommend you take a quick look at our homepage at http://www.mythbuntu.org .
[19:00] <habitantee> q dice la comunidad
[19:00] <superm1> i'll talk a little bit about our bases and then move over a little to talk about the development cycle
[19:01] <superm1> The big thing that makes Mythbuntu stand out from other similar projects is its relationship within the community.  All development is done directly within the Ubuntu archives and follows the standard Ubuntu release cycle.
[19:01] <superm1> We are happy to share our code, artwork, and everything we have learned during development with other teams.
[19:01] <laga> habitantee: wrong channel, try #ubuntu
[19:02] <superm1> We have actually been in colaboration with the Ubuntu Media Center (UMC) team regarding some common blueprints and goals that we share such as remote control support (LIRC).  Likewise, the UMC team has begun to adapt some of our scripts and smaller applications that we use to create our environment.
[19:02] <superm1> there has been a common push between us to make remote control support a more OOTB (out of the box) user friendly experience
[19:03] <superm1> items here have ranged from adding support for pre-compiled kernel modules, improving debian install scripts, all the way to writing custom third party applications to help
[19:03] <superm1> By using Ubuntu as our base and doing the development within the Ubuntu archives, we have a requirement of interaction with a large variety of other teams.
[19:04] <superm1> One of these teams is the MOTU (masters of the universe) team.
[19:04] <superm1> you may have attended some meetings in here where they discussed packaging and how all the things in universe get maintained
[19:05] <superm1> All of the Mythbuntu specific packages sit in Universe or Multiverse.  Since i'm now a MOTU, I am typically the person sponsoring our packages.  This doesn't mean however that I am the sole sponsor or developer of the packages.
[19:06] <superm1> if mythbuntu is to eventually turn into a canonical "supported" project, these packages will eventually need to be moved over to the 'main' component
[19:06] <superm1> Several of our team members have aspirations to eventually become MOTUs themselves.  I am working with them and trying to teach them how to properly produce packages that are sufficient for the archive.
[19:06] <superm1> PPAs (personal package archives) have been immensely useful here in testing our new packages.  Since our build process doesn't currently use the standard Ubuntu CD image builder, we have been able to add support for using a PPA to build the disks.
[19:07] <superm1> If one of us has a package that needs to be verified to work correctly before pushing it out to the archive, it can be pushed to the PPA.  Any of us can then initiate a new local CD build that would use the PPA.  Once the CD build has been verified to work with that package, it can be pushed to the normal Ubuntu archive.
[19:08] <superm1> If you are considering becoming a MOTU yourself, we are always looking for more people to help maintain and add additional new packages.  If you'd like to try to work on helping us with some packages to add to your portfolio of sponsored uploads, come and join us and we can try to help mentor you.
[19:08] <laga> regarding the move to main: currently, the MythTV packages cannot be moved to main because of dependencies, eg liblame. liblame is used to encode the audio stream with some types of TV cards.
[19:09] <superm1> if ever MythTV can be abstracted to depend on liblame or a third party "for purchase" decoder/encoder, this can become more feasible
[19:09] <laga> we'd have to move away from liblame and friends to put mythtv into main. in order to do that, we'd need to work with upstream. there's also been an (orphaned AFAIK) project on debian's alioth server which tried to do just that.
[19:10] <laga> superm1: yes, this will require some careful interaction with upstream. upstream seems to like liblampe a lot - that's an adventure for the future :)
[19:10] <superm1> well, so if anyone has an interest in doing this, we can chat some more in our development channel about technical requirements and alternatives
[19:11] <superm1> I'll jump back onto what i was going to go into next :)
[19:11] <superm1> So wrg to packaging, the way that I got involved with Ubuntu originally was by working on the 'mythtv' package
[19:12] <superm1> personally i've tried to stick to very related packages such as lirc, ivtv, mythplugins, ffmpeg, mplayer etc
[19:12] <superm1> lots of MOTUs like to have diversity in the packages they work with, but i'll say its not necessary to become a MOTU
[19:13] <superm1> the more important part is to show the knowledge that you have with packaging, and the conciseness, and concern for intricacies and ramifications for changes
[19:14] <superm1> okay moving on:
[19:14] <superm1> Another big area that we touch upon is Ubiquity.  We are the first Ubuntu derivative to have a custom frontend for Ubiquity.  Our frontend for it is derived from the GTK frontend.
[19:14] <superm1> ubiquity is written in the sense that it can have different "interfaces"
[19:14] <superm1> when you install a standard GNOME based Ubuntu install, you use the GTK interface
[19:15] <superm1> if you install Kubuntu, you will see that it uses a QT based interface instead
[19:15] <superm1> both of these interfaces are considered 'frontends' which call upon common code that is used to actually do the installation
[19:15] <brobostigon> is this the mythbuntu session??
[19:15] <superm1> brobostigon, Yes
[19:15] <laga> because kubuntu uses KDE which is based on QT - you get a more consistent interface.
[19:15] <brobostigon> thanks
[19:15] <superm1> mythbuntu doesn't really have a standard 'interface' per say like gnome and kde do though
[19:16] <superm1> we have just chosen to adapt GTK out of a personal preference
[19:16] <superm1> so our frontend then derives a lot of its functionality directly from the GTK interface that is used for Ubuntu
[19:16] <superm1> By using this custom installer we have the ability to ask questions and perform installations that would typically only be available in an alternate type installer.  We can then have custom post installation steps and do a lot more than the standard installer.
[19:17] <superm1> if you have looked at the Ubuntu installer, it is much shorter than ours is.  Ours is actually about twice as long.
[19:17] <superm1> by doing this, we are able to ask additional questions to better customize the system, and packages installed before you actually reboot.
[19:17] <laga> some time far, far away we might use the MythTV UI libraries to build an installer (and port mythbuntu-control-centre as well), but that won't happen soon. if you're interested, there's a very interestinjg üproject called "mythpython" which aims to porvide python bindings for the UI code of MythTV
[19:18] <laga> it's still in its early stages, though. search the mythtv-dev mailing list if you're interested. also, you can come to talk to use in our developer channel :)
[19:18] <superm1> it would be very cool to have an installer that was based out of libmythui though too
[19:18] <superm1> the problem is that by using ubiquity our entire installer is based off a combination of sh and python
[19:18] <superm1> so it would be a very involved conversion to go to C or C++
[19:19] <laga> not if we end up using mythpython. but we'll have to see how everything works out :)
[19:19] <superm1> as I said our installer disk is kinda like a hybrid between the 'alternate' installer and the normal ubiquity installer
[19:19] <superm1> because so much time had to be put into working on the ubiquity based installation, we didn't manage to finalize the items necessary for an 'alternate' disk install
[19:20] <superm1> this will be one of the goals for the upcoming cycle however.
[19:20] <superm1> something very nice though, the installer team has been very accepting of our code
[19:20] <superm1> so we actually have our ubiquity builds built at the same time as the normal ubiquity
[19:21] <superm1> this being said though there is a lot of work to be done in the installer yet.
[19:21] <laga> some examples of what we're doing in our installer: we can set up LIRC (eg make your remote control do something useful), configure proprietary drivers including TV-out, enable VNC and a few more.
[19:22] <superm1> so if anyone would have an interest in learning more about how it works, implementing their own derivative, or even abstracting the frontend further for other derivatives to take advantage of, these are all items you can come and join us to talk about
[19:23] <superm1> As you would expect, like a lot of Ubuntu, we use a lot of custom code to integrate and work with these packages.  A lot of our development has been python lately.  However we are looking people who are interested in helping the project.  This includes artists, translaters and coders to name a few. We're also looking for people who'd like to help out with documentation. If you think you can help our effort, please do get in contact.
[19:23] <superm1> a majority of ubiquity itself is python, as well as multiple of our custom applications that were written
[19:24] <superm1> if you take a look at the screenshots on mythbuntu.org, you will see some for the mythbuntu-control-centre
[19:24] <laga> like mythbuntu-control-centre and mythbuntu-lirc-generator
[19:24] <superm1> yup :)
[19:24] <superm1> these are completely custom applications that create an incredible end user experience
[19:24] <DaveMorris> screenshots- http://www.mythbuntu.org/image/tid/5
[19:25] <superm1> we're always looking for ideas to improve them still though, and more developers to improve them too
[19:26] <superm1> one of the biggest ways we were looking for help still was translations.  As an example, we are pleased to see our control centre application being translated.  Currently that effort is going suprisingly well with 15 languages being worked on.
[19:26] <superm1> https://translations.launchpad.net/ubuntu/gutsy/+source/mythbuntu-control-centre/+pots/mythbuntu-control-centre . You can also help us translate the packaging scripts at https://translations.launchpad.net/ubuntu/gutsy/+source/mythtv and https://translations.launchpad.net/ubuntu/gutsy/+source/mythplugins
[19:26] <superm1> so as you can see there is a very large variety of areas that we touch upon to make this derivative happen.
[19:27] <superm1> there are many teams that are involved with the interaction, even if indirectly
[19:27] <laga> which means there's a very large variety of areas where we can use your help :)
[19:27] <superm1> so even if you don't contribute to us directly, but help out with one of the parent projects that we use: you will help us immensely
[19:28] <superm1> recently since we started to use Xfce, I messaged the Xubuntu development team, and we will be working with them
[19:28] <superm1> so out of that, both xubuntu and mythbuntu will be improving with all of the increased exposure and bug filing that will result
[19:29] <superm1> okay so that's about what i had to say about our development.  So if you would like to get involved, please join us in #ubuntu-mythtv-dev shortly after this meeting.
[19:30] <superm1> we can discuss more of our specifications
[19:30] <superm1> and goals for hardy
[19:30] <superm1> Lastly, I'd like to thank everyone for putting aside some time to come and hear what we're about.  I'll open the floor to any questions.
[19:30] <Daviey> Please ask questions to the mythbuntu dev team in #ubuntu-classroom-chat , and they will be pasted in order.  Thanks
[19:30] <Daviey> < DaveMorris> [QUESTION] What does mythbuntu plan to add over the coming  Hardy cycle?
[19:31] <superm1> well we've got a very large (and growing) list of specs
[19:31] <superm1> https://blueprints.edge.launchpad.net/mythbuntu/
[19:31] <superm1> some of the bigger ones will be switching over to mythtv 0.21 as it gets released
[19:31] <superm1> and adding support for out of the box IR blasters
[19:32] <superm1> and consequently multiple LIRC devices
[19:32] <Daviey> We are also at a stage where we really need to thrash out some ideas that we have had.  These will be converted into blueprints for inclusion in Hardy (8.04)
[19:33] <superm1> if anyone has any ideas that they would like to see that are not on that list, please feel free to add a spec
[19:33] <superm1> you just need to register with launchpad. anyone registered on launchpad can submit one.
[19:34] <superm1> any additional questions?
[19:34] <tgm4883_laptop> [QUESTION] What is the process of becoming a Mythbuntu developer or in aiding in the development of it.
[19:34] <superm1> well there are three big ways that development can be aided
[19:35] <superm1> 1) help out with a project that we use in mythbuntu.
[19:35] <superm1> this is probably one of the best ways, because then we benefit as well as a lot of other people
[19:36] <superm1> 2) Testing testing testing
[19:36] <Daviey> 2a) report bugs, report bugs, report bugs!
[19:36] <superm1> if we don't have people testing our products before release, its hard to gauge what's broken
[19:36] <laga> 2b) triage bugs!
[19:36] <superm1> right after our first stable release, there was a large influx of bugs that could have been trivial fixes, but since we had just released, there wasn't much we could do about them at that time
[19:37] <superm1> the biggest point here will be regression testing
[19:37] <superm1> especially if you have very obscure hardware
[19:37] <superm1> there might only be 5 of you out there with that hardware, but if we know that it doesn't work for you, we can fix it and have it work for all 5 of you
[19:38] <superm1> 3) Come and join us in #ubuntu-mythtv-dev
[19:38] <Daviey> < tgm4883_laptop> [QUESTION] If i wanted to help, how active would i need to be?
[19:38] <superm1> we can talk to you about your strengths and weaknesses
[19:39] <superm1> and find where it would be best for you to help out with the project
[19:39] <superm1> you can commit as much time as you would like
[19:39] <superm1> there are no "requirements" per say
[19:39] <superm1> this is after all a community effort
[19:39] <superm1> we can try to set realistic deadlines for different specifications that are assigned and such.
[19:40] <Daviey> So flexible!  If you can help - do :)
[19:40] <superm1> and remember contributing doesn't have to be directly working on code
[19:40] <superm1> translations, helping users, and bug fixing are all great things to do
[19:40] <superm1> our forums are getting quite busy, so the more help the bettter
[19:40] <superm1> s/bettter/better/ :)
[19:40] <Daviey> The initial artwork was done by coders.. and it showed :) .  So anything you think you can bring to the project, we are listening.
[19:41] <Daviey> next?
[19:41] <Daviey> tgm4883_laptop> [QUESTION]  If I had an idea for mythbuntu, whats the best way to make sure it gets into Hardy?
[19:42] <superm1> file a spec on it
[19:42] <superm1> the more information you can add to the spec the better
[19:42] <superm1> if you for example have a remote control that works with a 10 step process
[19:42] <superm1> put that 10 step process in the spec
[19:42] <superm1> if you've got the time and knowledge to do so: even better, join up with us and implement it :)
[19:43] <Daviey> < laga> [QUESTION] how does regression testing work on Mythbuntu? .. and how do i go back to a previous version?
[19:43] <superm1> if you've got some general ideas where things need to be changed, but dont know the final details, we can help you walk through implementing it
[19:44] <superm1> the best way for regression testing is with multiple hard drives
[19:44] <superm1> you dont need to have two 500 gig drives to do it
[19:44] <superm1> just some basic tests would suffice.
[19:44] <superm1> have a working 7.10 install on one drive
[19:44] <superm1> and when you would like to do some regression testing, pop in the other drive instead
[19:44] <superm1> do a test install, and see what has changed and/or stopped working
[19:44] <laga> it's also a good idea to keep backups - both of our database and of your whole Mythbuntu install.
[19:45] <superm1> well if you're going to test an upgrade install - yes
[19:45] <superm1> if you are just doing hardware regression testing, you can just do a quick test install to that second drive
[19:46] <laga> Please remember that schema upgrades might be performed when a newer version of MythTv is introduced into an existing install. So: think twice before you connect your testing install to your existing master backend. :)
[19:46] <superm1> next q?
[19:47] <Daviey> Any questions people?
[19:49] <superm1> okay well looks like we're finished up here then.  Anyone that would be interested in joining our development, we're going to have a short meeting in #ubuntu-mythtv-dev in 10 minutes.
[19:49] <superm1> thanks again for coming and listening.
[19:49] <Daviey> Thanks superm1
[19:50] <mzungu> superm1, many thanks!
[19:50] <brobostigon> thanks
[20:06] <jelmer> hi class
[20:07] <laga> hi jelmer
[20:07] <jelmer> I'll be hosting the next session, which will be about Bazaar, the distributed version control system
[20:08] <jelmer> I'm Jelmer Vernooij, a regular contributor to Bazaar
[20:08] <jelmer> Bazaar is a distributed version control system
[20:09] <jelmer> it keeps track of the changes to a source code tree
[20:09] <jelmer> and you to share changes you make to that tree with other developers
[20:10] <jelmer> it allows you to browse the history of the tree and particular changes made at each point in history
[20:11] <jelmer> Bazaar is packaged in Ubuntu and most other Linux distributions
[20:11] <jelmer> and always works very well on Windows and Mac OS X
[20:11] <jelmer> if you have Ubuntu, you can install the "bzr" package
[20:13] <jelmer> I'll give a short introduction of how to make a directory versioned
[20:14] <jelmer> To create a new Bazaar branch (a directory structure of which Bazaar keeps history), run "bzr init <directory-name>"
[20:15] <jelmer> #ubuntu-classroom-chat betreten
[20:15] <jelmer> <hendrixski> QUESTION: if I make a personal branch from let's call it branch A and my friend makes a personal branch from branch A as well... is it possible for me to merge with my friends branch without having to merge back with branch A?
[20:16] <jelmer> hendrixski: If you mean integrating his changes without having to run "bzr merge" and then "bzr commit": you can run "bzr pull" if you have no additional changes in your tree that he doesn't have
[20:17] <jelmer> hendrixski: otherwise, you will have to run merge and commit your changes explicitly
[20:17] <jelmer> ok, on with the session
[20:18] <hendrixski> :-) jelmer sorry. the question is about if two child branches can merge across each other without having to merge back with the parent?
[20:18] <jelmer> once you have create the new branch, you can add files to it
[20:18] <jelmer> hendrixski: Yes, they can
[20:19] <hendrixski> :-) thanks: I had some trouble with this, just wanted to make sure it _is_ possible
[20:19] <jelmer> so, say you created a branch with the name "foo", you can now add a new file "bar" in that directory
[20:20] <jelmer> by running "bzr add bar"
[20:20] <jelmer> <Mez> QUESTION: is ther eany plans so that bzr-svn can branch from a local repository (a quick branch) instead of having to pull the full repo down, I want to use br - but with 16000 commits, the net breaks before it branches
[20:22] <Mez> NOTE: I will be acting as relay for this session
[20:22] <jelmer> Mez: As of version 0.4, you should already be able to do that without copying the contents of all the revisions. It will still need to fetch the metadata though, but that should be relatively quick.
[20:22] <Mez> what version is current of it in gutsy ?
[20:23] <jelmer> Mez: 0.4.1, which is pretty old actually. 0.4.4 will be released in a few weeks
[20:23] <jelmer> so, to get on with the session
[20:24] <jelmer> once you have added that new file, you should be able to store the changes by running "bzr commit"
[20:24] <jelmer> Bazaar will then ask you for a description of the changes you've made
[20:26] <jelmer> You now have the first "revision" of your directory
[20:27] <jelmer> run "bzr log" to have a look at the history
  QUESTION: are bzr branches sensitive to which version of bzr one is using?  For example, would it pose problems if I'm using version .15 and try to merge with someone using the latest version?
[20:29] <jelmer> Bazaar is backwards compatible, so new versions can read all older branches
[20:29] <jelmer> New versions may support branch formats that are not supported yet by older versions
[20:30] <jelmer> but they will not automatically upgrade branches
 QUESTION: what is the best gui for bzr? Does something exist similar to tortoisesvn?
[20:30] <jelmer> but leave the choice to upgrade to you
[20:31] <jelmer> newer formats are usually faster and support more features, but they may not be supported by older versions
[20:31] <jelmer> stani: there is a project called tortoisebzr, which aims to provide an equivalent to tortoisesvn on Windows
[20:32] <stani> but for ubuntu?
[20:32] <jelmer> it's wiki page is here http://bazaar-vcs.org/TortoiseBzr
 (of course i mean on ubuntu)
[20:32] <jelmer> There is also NautilusBzr, which is Bazaar integration for Nautilus
[20:32] <jelmer> more info can be found here http://bazaar-vcs.org/NautilusIntegration
[20:32] <Mez> jelmer: nothing in the KDE range yet ?
[20:32] <jelmer> It needs some love though
[20:33] <jelmer> Mez: There is a Qt Bazaar frontend, but no integration for Konqueror yet
[20:33]  * Mez will poke around later ... do carry on jelmer ;)
[20:34] <jelmer> ok, now that you've got a simple branch with one file you should be able to make change or two and commit those
 QUESTION: one of the biggest critics on bzr is the speed. Is there any progress on that?
[20:34] <jelmer> simply edit the file "bar" and run commit again - this change should also show up in "bzr log"
[20:35] <jelmer> stani: yes, performance is the #1 thing we're working on at the moment
[20:35] <jelmer> we've recently merged a new data format called packs that is significantly faster
[20:36] <jelmer> Especially network operations will be several orders faster
[20:36] <jelmer> and bring performance very close to git or mercurial
[20:37] <Mez> QUESTION: we currently use svn at work, containing ~ 160k commits.... how can I best convince them to switch to bzr ?
[20:38] <jelmer> Mez: 160k commits in a single branch or across several branches?
[20:38] <Mez> single branch, theres, ~ 400k in total
[20:38] <Mez> sorry
[20:38] <Mez> svn revision number is 260k
[20:39] <jelmer> wow :-)
[20:39] <imbrandon> windows kernel ?
[20:39] <imbrandon> heh
[20:40] <Mez> hehe, it's a 9 year codebase ;)
[20:40] <Mez> (includnig converted stuff from CVS)
[20:40] <jelmer> Mez: performance will still be the biggest issue there I think
[20:40] <Mez> jelmer, :(
[20:40] <jelmer> Mez: and it may not be feasible to work with that history until shallow branches land
[20:41] <Mez> jelmer, ah well, I'll try when we do the rewrite
 QUESTION: For a project I want to be able to retrieve the version number of a branch with python. So that I can name a tar automatically like eg. package-0.1.bzr123.tar.gz (if 123 is the revision number) Is there a simple API cal for that?
[20:41] <jelmer> Mez: packs are a really big improvement and may be fast enough, but I haven't tried repositories that large yet
[20:42] <jelmer> MeZ: packs work well with the mozilla tree, which is 200k revisions iirc
[20:42] <jelmer> stani:
[20:42] <jelmer> from bzrlib.branch import Branch
[20:43] <jelmer> print Branch.open("/path/to/branch").revno()
[20:43] <Mez> QUESTION: whats the ewasiest way to merge in a branch to my local branch as it was at a revisiion (I want to merge in what they had at r60)
[20:44] <jelmer> bzr merge -r60 <path-to-their-branch>
 QUESTION: at work we haven't set up a version control set up yet (it's a startup) and we'll be doing some proprietary development as well as using a few small parts that we tear out of an upstream project that uses SVN.  Is it worth it for us to start out using a distributed vcs like bzr, or would you recommend we stick with a centralized system like SVN just because it seems like the corporate standard?.
[20:45] <jelmer> hendrixski: Bazaar can be used in a centralized model, very much like Subversion
[20:46] <Mez> http://bazaar-vcs.org/Tutorials/CentralizedWorkflow
[20:47] <jelmer> hendrixski: If you need integration for an editor that doesn't have Bazaar integration or for the Windows explorer, I'd recommend Subversion
[20:47] <jelmer> or perhaps if you need support for svn-like keywords or the ability to version very large (gigabytes) files
[20:48] <Mez> QUESTION: why is python-paramiko not listed as a dependency in the ubuntu packlage ?
[20:48] <jelmer> you should be able to pull changes out of upstream Subversion using bzr-svn or (if upstream is free software) request a vcs-import for it in launchpad
[20:49] <jelmer> Mez: paramiko is only required when using Bazaar remotely with sftp:// or bzr+ssh:// urls
[20:50] <jelmer> Bazaar: which I agree are pretty common, but Bazaar is perfectly usable without them
[20:50] <Mez> jelmer, which is needed for LP integration - which is a big push surely ?
[20:50] <jelmer> for example, you can work locally only, use bundles, or ftp
[20:52] <jelmer> Mez: yes, and it's marked Recommends for that reason. We can argue whether the extra disk space required for those few users that don't need is a fair tradeoff
[20:52] <jelmer> for those that get confused by the fact that sftp or bzr+ssh doesn't work out-of-the-box
[20:53] <jelmer> and I can certainly see the point for that, but let's have that discussion on the packaging list
[20:54] <jelmer> So, now that you've got a simple Bazaar branch, you can publish it
[20:54] <jelmer> Launchpad provides hosting for Bazaar branches
[20:55] <jelmer> but you can also push to any host that's running an ssh or ftp server
[20:56] <jelmer> you should be able to upload your branch to Launchpad using the push command
 QESTION: I had trouble publishing to an FTP server, and I understand it's probably because my host doesn't accept certain FTP protocols (or something)... I understand that a future version of BZR will also fix this.  When is that planned to be rel
[20:57] <hendrixski> s/rel/released
[20:57] <jelmer> for example: bzr push bzr+ssh://bazaar.launchpad.net/~jelmer/+junk/foo
[20:58] <jelmer> I don't see any pending fixes for ftp for 0.92
 QUESTION: how does brz compare with git?
[20:59] <jelmer> hendrixski: Do you remember what exactly it was breaking on?
[21:00] <jelmer> I see several open bugs regarding ftp: https://bugs.launchpad.net/bzr/+bugs?field.searchtext=ftp&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=
[21:00] <hendrixski> jelmer, no but I can pastebin it to you after the session: I'd like to hear about Rudd-O's question while there's still time
[21:00] <jelmer> ok
[21:00] <jelmer> Rudd-O: So, each has it's advantages
[21:01] <Rudd-O> so what are they?
[21:01] <jelmer> This answer may be a bit subjective, so you're warned :-)
[21:01] <jelmer> Bazaar has focussed on correctness and UI
[21:01] <jelmer> initially
[21:01] <jelmer> and has now started working on performance
[21:01] <jelmer> for git, it's the other way around
[21:02] <jelmer> There are also a bunch of other differences
[21:02] <jelmer> Git doesn't track directories as far as I know, while Bazaar does
[21:02] <jelmer> Bazaar handles a bunch of corner cases for merge better
[21:03] <jelmer> Git does one working tree per repository
[21:03] <jelmer> Bazaar does one working tree per branch
[21:03] <jelmer> Bazaar's command set is more similar to that of Subversion or CVS
[21:04] <jelmer> and should be easier to grasp for "normal" users
[21:04] <jelmer> Both will have support for nested branches/submodules in future versions
[21:06] <jelmer> There is actually work going on on supporting git's data format in Bazaar - the bzr-git plugin
[21:06] <jelmer> Bazaar has very good Windows support
[21:06] <jelmer> Git has some, but it's very slow (Bazaar is actually significantly faster than Git on Windows last I checked)
[21:07] <jelmer> Ok, to wrap up
[21:07] <jelmer> so now that you've pushed your branch to launchpad, other people should be able to clone it locally
[21:08] <hendrixski> jelmer thank you for answering our questions.. reading manuals only paints so much of a picture, being able to ask questions gives priceless perspective.  Thanks :-)
[21:09] <jelmer> by running something like: "bzr branch http://bazaar.launchpad.net/~jelmer/+junk/foo launchpad-foo"
[21:09] <Mez> hendrixski, and you can always ask questions in #bzr
[21:10] <jelmer> and you can also view the details of that branch by opening it in your browser
[21:11] <jelmer> ok, that was my first open week session :-)
[21:11] <jelmer> thanks for all those attending
[21:11] <jelmer> more information on bazaar can be found at http://bazaar-vcs.org/
[21:11] <jelmer> questions are also welcome in our IRC channel, #bzr on this server
[21:11] <imbrandon> jelmer, great session , thanks
[21:11] <jelmer> or on the mailing list, bazaar@lists.canonical.com
[21:12] <mzungu> jelmer, thanks - gonna start using bazaar now!
[21:14] <imbrandon> OKIES, Hows everyone doing this $timeofday ? Ready to get started with some Package Patching ? ....
[21:14]  * mzungu ready
[21:15] <imbrandon> I'm not the best at switching IRC channels to see #ubuntu-classroom-chat so if you do talk to me in there please hilght my name, lets get started
[21:15] <imbrandon> I'm Brandon Holtsclaw ( https://launchpad.net/~imbrandon ) , Ubuntu MOTU and "core-dev" I work with Kubuntu mostly but touch alot of diffrent things.
[21:15] <imbrandon> I'm going to be giving a primer on Patching Ubuntu packages today. At any time feel free to stop me and ask questions ( no need to Use the #ubuntu-classtroom-chat channell for this session, we'll save that for the next one if needed )
[21:15] <imbrandon> On that Note I had a file system corruption and lost some of the nots I had prepared for this session but I'm sure with what I ahve left and your questions we can just wing it. Soooooo onto the fun stuff.
[21:16] <imbrandon> notes* , man if i could type today it would be good too
[21:16] <imbrandon> In earlier times, people just applied patches inline (i. e. directly in the source code tree). However, this makes it very hard to extract patches later to modify them, send them upstream, etc.
[21:16] <imbrandon> Also this means that new upstream versions are a pain, since they generate a lot of rejections when applying the package diff.gz to them.
[21:17] <imbrandon> The ideal state is an unmodified tarball from upstream, plus clean and separate patches.
[21:17] <imbrandon> What patch system you use largely depends on the package you are working on, for now lets assume you are working on a existing debian/ubuntu package.
[21:18] <imbrandon> When working with packages in Ubuntu we try to keep the Diff or "Delta" with Debian small so for that reason its often best to use what ever patch system is already in palce in the package most of the time.
[21:19] <imbrandon> ( only exception to that being if something is broken and you are working directly with the Debian Maintainer to make the patch system changes)
[21:19] <imbrandon> Some of the patch systems you will come accross are dpatch, cdbs simple-patch-sys, diffs in debian/patches with special debian/rules and so on. There are many many many diffrent patch systems and we would not have time to cover them all here
[21:20] <imbrandon> So i'll be touching on some of the more common ones, like cdbs simple-patch-sys
[21:20] <imbrandon> one of my personal favorites
[21:20] <imbrandon> ( unless someone prods me about another one , *hint* )
[21:21] <imbrandon> [15:19] <hendrixski> QUESTION: you mentioned the diff or delta... as something other than patches where changes can be made... can you explain that? because I thought the only way to add stuff to upstream was to add a dpatch.
[21:22] <imbrandon> no , the diff or delta in this case is changes that ubuntu has made to packages seperate or ontop of what debian has
[21:22] <imbrandon> not nessesiarly upstream
[21:22] <imbrandon> so say we are working with x-chat as an example
[21:23] <imbrandon> x-chat in debian has a very simple patch to make #debian and irc.debian.org the default server and channel when installed
[21:23] <imbrandon> well in ubuntu that would not be correct, so we make a change to the patch for irc.ubuntu.com and #ubuntu as the channel
[21:24] <imbrandon> THAT is the "delta" i refered to, the change between ubuntu and debians package we try to make as small as possible
 QUESTION: so is it like the %patch directive in RPM specs?
[21:24] <imbrandon> thus we use the patch system that they may have in place for each package
[21:25] <imbrandon> Rudd-O, well I'm not at all familiar with RPM creation other than it requires a .spec file :) so i'm not qualified to say, but I would imagine
[21:25] <imbrandon> they are very similar
[21:25] <imbrandon> using cdbs simple system as an example might clear this up a tad
[21:26] <imbrandon> it is one of the easiest for new packagers to understand
 in RPM you distribute the patches in a single srpm along with the tarred package source, and the %patch directive applies them in order before compilation
[21:26] <imbrandon> Rudd-O, yes, sounds very much the same
[21:27] <imbrandon> the way patches are distributed in ubuntu is in the source.deb file , normaly under debian/patches directory, each split out
[21:27] <Rudd-O> IC
[21:27] <imbrandon> into small self contained patches
[21:27] <Mez> imbrandon source deb file?
[21:27] <imbrandon> err
[21:28] <imbrandon> yes i totaly messed that up, in the source package ( its not a deb untill compiled into a binary ) heh
[21:28] <imbrandon> thanks Mez
[21:28] <Mez> np
[21:28] <imbrandon> one half second ( mt dew on keyboard )
[21:29] <imbrandon> ok sorry about that fellas
 imbrandon: get an ibm model m keyb, they have coffee drains at the bottom.
[21:29] <imbrandon> heh , i like my apple keyboard ;)
[21:30] <imbrandon> ok soo, for a tiny overview of the steps to add a small patch to say amarok from a svn commit upstream
[21:30] <stani> when I look to the source package of xchat there is a diff.gz file and debian/patches. How do they relate?
[21:30] <imbrandon> ok we'll use that
[21:30] <Mez> stani - #ubuntu-classroom-chat please ;)
[21:31] <imbrandon> the diff.gz is part of the source package stored in the repos, they consist of a
[21:31] <imbrandon> package.dsc and diff.gz and a orig.tar
[21:31] <imbrandon> the orig.tar.gz is the * hopefully ) pristine upstream tarball
[21:32] <imbrandon> with no packaging information stored inside
[21:32] <imbrandon> the diff.gz is the contents of debian/ ( and anything else ) thats not in the upstream tarball including patches
[21:33] <imbrandon> the dsc is the information dpkg uses to have meta info and recreate the source directory with the debian/ dir intact
[21:33] <imbrandon> so when you apt-get source x-chat , what it actualy does is grab those 3 files and
[21:34] <imbrandon> un-tars the upstream tarbal then applies the diff.gz , thus creating the x-chat_version directory
[21:34] <Mez> s/x-chat/schat
[21:34] <Mez> s/schat/xchat/
[21:35] <imbrandon> so now you have what you need to recreate the debian package infront of you
[21:35] <imbrandon> let me grab x-chat and see what patch system it uses and we'll keep using that for an example
[21:36] <imbrandon> you'll see when you apt-get source it , it also tells you that its doing just what i said, untaring it
[21:36] <imbrandon> and applying the diff
[21:37] <imbrandon> dpkg-source: extracting xchat-gnome in xchat-gnome-0.18
[21:37] <imbrandon> dpkg-source: unpacking xchat-gnome_0.18.orig.tar.gz
[21:37] <imbrandon> dpkg-source: applying ./xchat-gnome_0.18-0ubuntu3.diff.gz
[21:37] <imbrandon> brandon@hood:~/files/dev/x-chat$
[21:37] <imbrandon> so now you can cd xchat-gnome-0.18, and notice the debian/ dir and specificly the debian/patches dir
[21:38] <imbrandon> inside the patches/ dir you'll notice they are numbered .patch files
[21:39] <imbrandon> one specificly i used called 04_autojoin_ubuntu_chan.patch
[21:39] <imbrandon> that i just spoke of
[21:40] <imbrandon> if you open this file you'll notice its a small diff for src/common/servlist.c
[21:40] <imbrandon> to have it autojoin #ubuntu
[21:41] <imbrandon> say i was trying to get it to join #ubuntu-classroom instead , i just need to edit this patch and make my changelog entries in debian/changelog ( dch -i is good for this )
[21:41] <imbrandon> then rebuild the package, the upstream tar is preserved and your changes will appear in the diff.gz
[21:42] <imbrandon> so this added benifet will let you forward small changes to upstream bug trackers when needed if it was to fix a bug,
[21:42] <imbrandon> or in this case its a ubuntu only patch, we dont want every gentoo x-chat user to join #ubuntu so we keep this in out own package
[21:43] <imbrandon> not included in a "big diff" one would normaly have to sift through if they sent everything upstream
[21:43] <imbrandon> [15:41] <Rudd-O> QUESTION: if I make changes in the patched source, how do I pull the changes with a single command, short of diffing manually with a separate copy?  Is there a tool like rpm's patch build (I keep forgetting the name) tool?
[21:44] <imbrandon> well in this case where it uses a simple patch system, not dpatch or cdbs edit patch yes, you make a seperate diff
[21:44] <imbrandon> err diff a seperate copy
[21:44] <imbrandon> diff -ruN or similar is what i personaly use
[21:45] <imbrandon> the easy way to do this imho is when you `apt-get source xchat-gnome` first thing you do is mv  the directory it creates to a -new
[21:46] <imbrandon> and then `dpkg-source -x *.dsc` , this just tells dpkg to untar the orig again and reapply the diff
[21:46] <imbrandon> then you have a pristine and a -new directory to work with
[21:47] <imbrandon> no, i mean mv, but cp -Rav would also work if you havent touched the source dir at all
[21:47] <imbrandon> the first way i stated because sometimes you wont do that untill after changes were made
[21:47] <imbrandon> also ..
[21:48] <imbrandon> there have been a few MOTU school sessions by pitti and others using real world examples of diffrent patch systems ( since there are so many )
[21:49] <imbrandon> you can find those ( and other packaging School subjects ) at https://wiki.ubuntu.com/MOTU/School/
[21:49] <imbrandon> and also poke any of us in #ubuntu-motu at any time
[21:50] <stani> how do you "rebuild a package"?
[21:50] <imbrandon> ok, sorry for the lack of details as I said I lost most of my notes for this session and only recovered a fwe, but feel free to grab me or any MOTU / core-dev anytime
[21:51] <imbrandon> stani, normaly after all changes are done you can rebuld the binary with the simple command "debuild"
[21:51] <imbrandon> but sometimes you want to prepare it diffrent ways, such as to upload to a PPA then you would use debuild -S -sa , this creates a source package upload
[21:52] <imbrandon> man debuild for all the normal options, but 99% of the time it will be a simple debuld or debuild -S -sa
[21:53] <imbrandon> any Questions before we run out of time ( even though I'm running the next session too , heh , how did that happen )
[21:53] <stani> before you said that a source package consisted of three files, are they unified by debuild -S -sa?
[21:53] <imbrandon> stani, no they are recreated based on the working directory when you run -S -sa
[21:53] <imbrandon> they are unified when you simply run debuild into a .deb
[21:54] <stani> so a source package is not one file, it is always three?
[21:54] <imbrandon> in ubuntu and debian yes, with one exception ( not very often it happens )
[21:55] <imbrandon> where a source package is only 2, this is called  a "native" package and has no .diff.gz
[21:55] <stani> and if you upload to ppa, you upload all three of them?
[21:55] <imbrandon> this is because there is no upstream for the prooject , e.g. ubuntu IS the upstream, like kubuntu-default-settings is a good example
[21:56] <imbrandon> so no diff is needed or made
[21:56] <imbrandon> yes if you upload to a PPA you use the command `dput <ppa-name> *.changes` this changes file tells dput where to find the other 3
[21:56] <imbrandon> to upload them
[21:56] <imbrandon> automatic like
[21:57] <stani> thanks
[21:57] <geser> please dput only the *_source.changes to ppa
[21:57] <imbrandon> err yea, i'm used to building with -S -sa where only a _source .changes is created
[21:57] <imbrandon> but i should have specified
[21:58] <imbrandon> thanks geser
[21:59] <imbrandon> OK well if we dont have any more Questions right off I'm gonna wrap this session up ( the next one is run by me also and is a MOTU Q & A so some of the sme questions will fall under that too )
[21:59] <imbrandon> I'm gonna take a quick 3 minute break to grab a soda and we'll get started with soem MOTU Q & A
[22:00] <imbrandon> geser, feel more than free to stick arround and help field Q's with me if you feel like it :) brb
[22:01] <geser> sure
[22:05] <imbrandon> OK , back, how is everyone, we got quite a few people here for the MOTU Q & A ?
[22:06] <imbrandon> Lets start off with a small blurb about just what MOTU is ....
[22:06] <imbrandon> MOTU are the Masters of the Universe ( a HE-MAN refrence for those that dont know ) that help maintain the Universe and Multiverse Repos
[22:07] <imbrandon> for Ubuntu, we are almost 100% made up of volenteers like your self and just do it for the love of Ubuntu
[22:07] <imbrandon> you dont have to be a uber programer or even know how to program for that matter to be an effective MOTU although it does help
[22:08] <imbrandon> its a 100% diffrent beast
[22:08] <imbrandon> you can spend as little as 1 hour a week , or like some of us wayyyyyyy to much time at it ( /me looks over at LaserJock )
[22:09] <imbrandon> with that said we'll go a head and start taking some Q's and do our best, LaserJock and geser are both here to help field questions also and I'll let them intro them selfs
[22:09] <imbrandon> as for me , I'm Brandon Holtsclaw ( https://launchpad.net/~imbrandon ) , Ubuntu MOTU and "core-dev" I work with Kubuntu mostly but touch alot of diffrent things.
[22:10] <imbrandon> any questions to get us started off ?
[22:11] <stan1> still a question of previous session: the diff.gz gets generated by the debian/patches when using debuild?
[22:12] <imbrandon> well not JUST debian patches, it is a diff of everything thats not in the orig.tar.gz
[22:12] <imbrandon> so basicly debian/*
[22:12] <imbrandon> but yes includes debian/patches
[22:12] <geser> no, the other round the diff.gz contains also debian/patches (instead of one big patch without a patch system)
[22:13] <imbrandon> umm thats what i said correct ?
[22:13] <geser> yes, that no was an answer to stan1's question
[22:14] <geser> should have used a hilight
[22:14] <imbrandon> ahh :)
[22:15] <stan1> what is the role of python-central? Probably to make python packaging more easy, but what does it do in more details?
[22:15] <LaserJock> yeah, the .diff.gz is a representation of all changes made to the .orig.tar.gz to get to a Ubuntu source tree
[22:17] <imbrandon> yes python-central is there to help not only make python packages easier , but also help you adhear to the debian python packagin policy ........
[22:17] <geser> stan1: before python-central (and python-support) python-packages had the supported python versions in the package name which meant for every new python version the packages need to be modified
[22:18] <geser> stan1: with python-central/python-support it's now easier as the packages get byte-compiled on the host (and not inside the package anymore)
[22:20] <stan1> I noticed that if a 100% python deb package from feisty is not able to run edgy, although edgy has all the dependencies except python-central. Would there be an alternative way which would be backwards compatible to edgy as well?
[22:21] <imbrandon> are you talking about the binary packages ? they probably require a rebuild with the dependancys updated is all
[22:22] <imbrandon> you never want to run the binary package built for another sytem on your, always re-build
[22:22] <imbrandon> same goes for any programing language except maybe bash
[22:23] <stan1> ok
[22:24] <LaserJock> there are also changes that came along when python-central and python-support were created
[22:24] <LaserJock> which required versioning the dependencies
[22:24] <LaserJock> that can cause some difficulty when backporting
[22:25] <imbrandon> Do we have any aspiring MOTU's attending ? anything about the process that you dont understand quite yet ?
[22:26] <stan1> if I am both upstream and packager of a program, would it possible to automate the packaging (eg update changelog from bzr history) or would that be unwise?
[22:27] <imbrandon> you can, although it is advised most of the time to keep the debian packagin seperate from the source
[22:27] <imbrandon> 'and a seperate CHANGES file
[22:27] <LaserJock> I would personally have two branches
[22:27] <imbrandon> this is to allow others to help work on your package too , as MOTU group maintains packages in ubuntu
[22:28] <LaserJock> one for the source code that can be exported to the .orig.tar.gz
[22:28] <LaserJock> and the other for the packaging, i.e. debian/
[22:28] <LaserJock> stan1: you might also be interested in bzr-builddeb
[22:28] <stan1> thanks
[22:29] <imbrandon> or svn-builddeb or cvs-builddeb if your not as fortunate to use bzr
[22:29] <LaserJock> the problem that I would see just doing it straight from bzr history would be that we tend to keep the changelogs to just the big stuff
[22:30] <LaserJock> having a 2 page history of every commit would be kinda hard to dig through
[22:30] <LaserJock> for each debian/changelog entry
[22:30] <imbrandon> unless its the kernel :)
[22:30] <stan1> yes, but i give prefixes to my commit messages, so i could do: "deb: message" and filter them out
[22:31] <imbrandon> stan1, now that cuold work but also rember not everyone that works on your package in ubuntu will use the main bzr
[22:32] <imbrandon> say you upload it , and 2 months later i decide to "fix somehting small" in the packaging, i would just fix it and re-upload as there is no concept of maintainer in ubuntu
[22:32] <imbrandon> now i'll most likely email you
[22:32] <LaserJock> stan1: that sounds reasonable, I'd probably go with a bash script to grep/sed those
[22:32] <imbrandon> and let you know of the change BUT you still have to take that into account
[22:33] <imbrandon> [16:30] <peppych> [QUESTION]  Hi I have followed the MUTO and packaging sessions this week and I think I got a good image of the overall tools. But I'm not sure to have got the job done right though. You finally make apps ubuntu compatible which is applying patches, new upstreams and resolve dependences or did I miss some thing?
[22:33] <imbrandon> peppych, yes that sounds about correct with the exception of bug tracking in LP
[22:34] <imbrandon> other than that you have a grasp of the basics
[22:35] <peppych> but how are bugs handled I mean if they are application related ?
[22:36] <peppych> you send them to the dev team ?
[22:36] <imbrandon> peppych, if they are application related then they are forwarded upstream
[22:36] <imbrandon> yes
[22:36] <peppych> oh ok I think I got it right then :D
[22:36] <peppych> thanks
[22:37] <imbrandon> and if you feel confy with doing so and its the correct time in the cycle you can then get fixes from svn and apply them as patches
[22:37] <imbrandon> comfy*
[22:38] <imbrandon> also of note there are MANY resources at https://wiki.ubuntu.com/MOTU/
[22:39] <imbrandon> and anyone is alwasy welcome at #ubuntu-motu to ask questions
[22:42] <imbrandon> OK , I think I'm gonna do a "Last Call" for any questions you might have for the MOTU
[22:42] <peppych> I have to put my hands in it which will get it clearer to me ;) thanks for the answer and the great work you all do
[22:42] <imbrandon> np
[22:42] <LaserJock> peppych: yes, actual experience really helps
[22:43] <LaserJock> I didn't really understand a lot of packaging until after I was a MOTU
[22:43] <stan1> thanks!
[22:43] <LaserJock> geeze, that's some cloak
[22:44] <imbrandon> No problem, thanks everyone for Comming and hopefully we'll see you arround #ubuntu-motu, thanks LaserJock and geser for helping out, if we dont have any more questions I'm gonna wrap this up a bit early for the night
[22:51] <mzungu> imbrandon, thanks
[22:53] <peppych> thanks for the session good night all
[22:54] <destructive> hi all :)