## page was renamed from MeetingLogs/OpenWeek UsingLaunchpad2
== Ubuntu Open Week - Using Launchpad = Thu, Nov 30, 2006 ==
see also [[MeetingLogs/openweekedgy/UsingLaunchpad|Tuesday Session]].
{{{
10:00	kiko	very well, take it away I must
10:01	kiko	hello everyone, and welcome to the second installment of the launchpad overview as part of UbuntuOpenDay
10:01	kiko	I'm happy to have had a great first session with a number of difficult questions
10:01	kiko	I've posted answers to those questions to launchpad-users, our very exclusive mailing list!
10:02	kiko	I've linked to the archives from the UbuntuOpenDay subpage for my talk, so if you were curious about any one which wasn't answered, just look there
10:02	kiko	I'm also going to tabulate them as faq entries
10:02	kiko	so they should be useful for a wider audience.
10:02	kiko	in the first section I covered Launchpad in general and then bug tracking, translating and the answer tracker in Launchpad.
10:03	kiko	I'll redo a quick overview today, and then talk about the remaining two applications: the blueprint tracker, and the bazaar branch hosting, import and introspection service
10:03	kiko	the branch part is really my favorite but I will try and save it for last!
10:04	kiko	so Launchpad is essentially a web service that is designed to make the work inside and between open source projects easier.
10:05	kiko	it contemplates some features which no other online tool has really done before -- and these features are mostly related to the way projects communicate between themselves.
10:05	kiko	for instance, Launchpad's bug tracker allows a single bug to be tracked in various different distributions, and in one or more upstream projects
10:06	kiko	this theoretically allows Ubuntu, Debian and Redhat to all use the same bugtracker to track the status of a fix in, say, upstream Linux kernel, and in other distributions.
10:06	kiko	the more projects using Launchpad, the better that collaboration aspect gets
10:07	kiko	another example of where cross-project collaboration is easier in Launchpad is with translations: translations for strings used in a project are offered as potential suggestions in other contexts where the same translatable string occurs
10:07	kiko	the context's translation review team can verify and decide whether the string is relevant or not.
10:08	kiko	if we are making comparisons, one of Tuesday's questions asked: is Launchpad similar to Sourceforge?
10:08	kiko	in some ways we are, and in some we aren't. we are similar in the sense that we do offer online services that you /should/ use for /your/ project
10:08	kiko	bug tracking -- community support -- translations -- specification tracking -- code hosting
10:09	kiko	in others, we are not so much: we don't offer mailing lists or web content hosting.
10:09	kiko	so there's some unique aspects to both Sourceforge and Launchpad.
10:09	kiko	so that's an overview of the web application, and I'll move on to some more specific examples inside two applications -- the specification tracker, and the code hosting service.
10:10	kiko	be sure to ask questions about other applications if you missed tuesday's Q&A, or if you are still curious -- I'm happy to help out!
10:10	kiko	XXX The specification tracker: blueprints.launchpad.net XXX
10:10	kiko	One of Launchpad's applications is a specification, or 'blueprint' tracker.
10:11	kiko	a specification is a general term used in software engineering that is essentially a document that describes something
10:11	kiko	moving from very vague to more specific, a specification usually will describe a change to existing software, a new feature to be implemented, a modification in an existing design, or a process that a team should follow
10:12	kiko	we use specifications a /lot/ in Launchpad and in Ubuntu
10:12	kiko	people that were at the Australian conference last year (UDU) can remember all the specs and post-its on the wall!
10:12	kiko	specifications are a great way of capturing history and rationale of your project
10:13	kiko	they help answer questions like "how exactly is that supposed to be implemented"
10:13	kiko	and also "why the hell did we decide to use a cronscript and not a trigger?!"
10:13	kiko	launchpad offers a specification tracker which is something of a unique service
10:13	kiko	the spec tracker essentially allows us to capture metadata related to a textual document
10:14	kiko	it's important to point out that the document is not actually hosted in launchpad
10:14	kiko	you can use any wiki (or other text document hosting -- even flat ascii via apache)
10:14	kiko	launchpad just stores metadata
10:15	kiko	this metadata allows you to track who is working on the document, who's doing the implementation, who's ok'd the document, and in what status the doc and the implementation are.
10:15	kiko	let's look at a live example to see what I'm talking about.
10:15	kiko	https://blueprints.launchpad.net/distros/ubuntu
10:15	kiko	this is the listing of specifications for Ubuntu
10:16	kiko	you'll see that the listing is ordered by priority (meaning that somebody in project management has made an explicit decision as to what is more important)
10:16	kiko	and that the spefication has a name and two statuses
10:16	kiko	the "definition" status describes the state of the document itself
10:16	kiko	the "delivery" status describes the status of the feature
10:16	kiko	in the example Ubuntu URL
10:17	kiko	you'll see that Tollef is assigned to the top essential priority specification -- network-roaming.
10:17	kiko	let's take a closer look at that specification so you can see the metadata for yourself!
10:17	kiko	https://blueprints.launchpad.net/distros/ubuntu/+spec/network-roaming
10:18	kiko	first, you'll see on the right-hand side of the page a set of attributes related to the specification
10:18	kiko	and that in this case the implementation of the spec has not even started yet!
10:18	kiko	the specification itself is approved,  and it's been accepted for feisty, so tollef should get busy soon to get it in <wink>
10:19	kiko	there's a dependency tree in the page content
10:19	kiko	when a spec depends on another, it is rendered graphically
10:19	kiko	(this feature was incidentally a gift from sabdfl himself)
10:19	kiko	so in this case, Kubuntu only gets networking if tollef manages to deliver network-roaming in time
10:20	kiko	the specification tracker is pretty simple to use
10:20	kiko	you can see how to register new specs and edit it using our staging server.. if I can get a working URL to it ;-)
10:21	kiko	the staging server is a box which holds an exact copy of the production database
10:21	kiko	but which allows changing data without concern -- the database is wiped and restored nightly
10:21	kiko	To add a new spec to Ubuntu on staging, use https://staging.launchpad.net/distros/ubuntu/+addspec
10:22	kiko	you'll see that it allows you to capture metadata, in particular a specification URL
10:22	kiko	that URL is the only link to the document -- which is why I pointed out it could be pretty much anything hosted anywhere.
10:23	kiko	the specification tracker has a number of features that are not immediately apparent
10:23	kiko	for instance, the dependency graph and prioritization allow a suggested to be automatically built from your specifications; the roadmap for ubuntu is at https://blueprints.launchpad.net/distros/ubuntu/+roadmap
10:24	kiko	the spec tracker also includes support for managing team sprints
10:24	kiko	where the sprints are essentially activities where people develop the specifications that will be implemented
10:25	kiko	(in Canonical, we essentially use sprints to capture specifications because we have little face-time together, being a distributed company, and capturing discussions and ideas in documents is a great way to record this historically)
10:25	kiko	to see sprints at the latest developer summit for Ubuntu, for instance:
10:25	kiko	https://blueprints.launchpad.net/sprints/uds-mtv
10:26	kiko	err -- I meant specs at the latest summit. blame hunger!
10:26	kiko	anyway, you can see there the overview of specs discussed there.
10:27	kiko	you can use the sprint feature to manage your own sprints, and we can even get you nicely formatted schedules that ensure that all the discussions you want to have occur
10:27	kiko	that's a whirlwind view of the Launchpad blueprints application, and feel free to ask away if there are bits I was unclear about or omitted
10:27	kiko	let's move on to my favorite app!
}}}

''<vyoman> are we supposed to login into the staging server?''

 yes. the staging server is an exact replica of the production server -- so much that you should log in to it to actually change it. your launchpad credentials will be the same as on production.

 ''[vyoman]	the _addspec is asking for a login <s>''

  right -- just use your launchpad account.

''<mruiz> I'm the ubuntu-cl team admin; when mass email will be enabled? (to contact all team members and coordinate)''

 so this is a question about a feature in which Launchpad teams would have an externally visible email address. currently, Launchpad teams are used to organize people into arbitrary groups. Launchpad can email these groups directly, and you've seen this in action for instance in bugs, where team subscribers all get notified of bug changes. there is currently, however, no way to externally email a team

 ''[mruiz]	but many LoCo Teams use LP, and sign as teams.''

  right.	so mruiz for instance would like to be able to contact his team through a specified email address and have the message relayed to the team members. we have a plan for this feature but it hasn't been a priority as of now

 I've written down your request to bump this one up (and I encourage other people that want features implemented to please let me know so I can take your requests into account when deciding what needs to be done next!)
{{{
10:32	kiko	XXX Launchpad code XXX
10:33	kiko	so some of you may be familiar with the most amazing VCS that has been under development for the past 2 years
10:33	kiko	that's Bazaar (bazaar-vcs.org) in case you were wondering!
10:33	kiko	bazaar is a decentralized (ddaa beat me until I agreed to say that) revision control system
10:34	kiko	so it has a similar pattern of working to git, darcs, arch, monotone, mercurial and (should I say it?) bitkeeper!
10:34	kiko	in particular, each developer has his own tree with history and is able to do commits to his local tree and see changes without needing to hit a central server
10:35	kiko	in this model, developers usually move code between each other and onto a specific branch which is maintained as a mainline
10:35	kiko	that's the 5000km view of decentralized RCS
10:36	kiko	Bazaar is an interesting new VCS, designed to be very simple, usable and fast
10:36	kiko	it's written in Python and #bzr is the place to go to learn more about the tool itself
}}}
''<bhale> does every developer run his own database and or web server?'  or the server config is dynamic enough to handle arbitrary branching.  ''

 each launchpad developer runs his own database and web server. I'm not sure what you meant about arbitrary branching, but it's impractical to depend on a central server if you're for instance developing offline. it also places a lot of stress on that server because everybody at some point wants to hit the database to fetch a list of whatnot

{{{
10:38	kiko	so coming back to Bazaar
10:38	kiko	Launchpad is a great match for Bazaar in a number of ways
10:39	kiko	and I'll try enumerating some of the ways that I find most interesting and useful
10:39	kiko	first, Launchpad offers you a free Bazaar branch hosting service
10:39	kiko	anyone with a Launchpad account can push their branches onto the Launchpad supermirror
10:40	kiko	the supermirror is essentially an open, global code repository
10:40	kiko	let me dig out a tutorial so you can read more about this
10:40	kiko	http://ddaa.net/blog/launchpad/bzr-hosting
10:40	kiko	there you go
10:41	kiko	essentially, if you use bzr, you can host your project's sourcecode on Launchpad
10:41	kiko	and have your developers collaborate on that code.
10:41	kiko	you can even have shared branches, to which all of your team can commit:
10:41	kiko	http://blogs.gnome.org/view/jamesh/2006/08/17/1
10:41	kiko	jamesh tells us all about that (and western australia) in his blog entry
10:42	kiko	the supermirror is a great service, and I expect a lot of projects to host their main lines off it
10:43	kiko	there's no setup cost, and anyone can bzr branch it trivially.
10:43	kiko	okay
10:43	kiko	a second good example of Launchpad supporting bazaar
10:43	kiko	is in the VCS imports service
10:43	kiko	what are VCS imports?
10:44	kiko	essentially, I wish everybody in the world used Bazaar
10:44	kiko	unfortunately, there are historical reasons why this isn't the case YET
10:44	kiko	for those projects that use CVS and Subversion, how do we facilitate hackers using Bazaar to work?
10:45	kiko	answer: we host continuous imports of upstream version control into Bazaar
10:45	kiko	this is a really interesting service
10:45	kiko	say your upstream project uses CVS
10:45	kiko	say it's Bugzilla (I am so biased!)
10:45	kiko	and you want to hack on it using bazaar
10:46	kiko	well, easy -- the bugzilla project has an import already set up in Launchpad!
10:46	kiko	if you visit
10:46	kiko	https://launchpad.net/products/bugzilla
10:46	kiko	you'll notice that there's a branch registered in the bottom-most right-hand-side box
10:47	kiko	if you visit the branch registered there:
10:47	kiko	https://launchpad.net/people/vcs-imports/+branch/bugzilla/main
10:47	kiko	you'll notice that it lists all recent revisions committed to upstream bugzilla
10:47	kiko	if you want to hack on bugzilla a bit
10:47	kiko	or customize it locally while still preserving history
10:47	kiko	just do
10:47	kiko	bzr branch launchpad.net/products/bugzilla
10:48	kiko	and (after some 10 minutes or so) you'll have a branch containing the full history of the bugzilla project
10:48	kiko	imported into a conveniently packaged Bazaar branch
10:48	kiko	you can hack away locally
10:48	kiko	and when upstream changes, we import the changes into Launchpad, and you can simply issue "bzr merge" to get the new changes and merge it into your now-modified tree
10:49	kiko	this is a great way to start using Bazaar even through the upstream project hasn't decided to switch yet.
10:49	kiko	there are over 500 projects being imported continously into Launchpad
10:50	kiko	bugzilla is just one. gaim is another. be sure to register your own favorite projects today, and let's get VCS imports available to the mases.
10:50	kiko	there are yet other areas that Bazaar and Launchpad fit in well together
10:50	kiko	you can assign Bazaar branches to Launchpad bugs
10:50	kiko	when the branch status changes, the bug recipients are notified
10:51	kiko	and the next step in that integration is picking up commit log messages and automatically marking bugs closed.
10:51	kiko	specifications can also have branches assigned to them
10:51	kiko	so you can keep close tabs on how the code that others are working on is progressing
10:52	kiko	let me handle some questions!
}}}

''<vyoman> how do you commit to bazaar?''

 in bazaar, everybody has their own branch. what happens is that you (generally) create your own branch based on another one. so, most projects organize their work around a branch which is made publically available, and which is conventioned the "mainline." the pattern of use is that all developers branch off this mainline do their own work	merge in new changes from mainline periodically and when their work is ready for distribution. they merge /their work/ into the mainline. the mainline from that point on contains the full history of that branch that they developed locally.

 so, to answer your question directly:
  bzr branch launchpad.net/products/gaim # create a new bazaar branch of gaim
  cd gaim
  vi Makefile # hack away
  bzr commit
 will pop up an editor window to allow you to enter a description of your change at that point you will have one local change to your branch of gaim. 	you can use bzr merge to pick up new changes in gaim as they come along	which makes maintaining a long-lived branch a lot easier.

''<gumpa> it sounds to me like Launchpad hosts the trunk, each developer has their own branch. Is this correct?''

 essentially, Launchpad can host both trunk and developer branches. the thing is, anybody can host any branch on Launchpad. if you are a developer, you can hack on your branch locally, and then publish ("push") it to the world via Launchpad. bazaar makes it very easy to create and maintain remote copies of your branch	exactly for this functionality. so you could, for instance, "bzr push" your branch to your own location up on the supermirror. again, read more about this on http://ddaa.net/blog/launchpad/bzr-hosting

 essentially, the "trunk" is a convention. any developer can do the job of merging other people's work and offering a trunk for the project. many projects work like Linus does for Linux -- pulling people's changes in and offering them reviewed and merged as a mainline trunk. but all branches are technically alike. 

''<silwol> What do the commit messages have to look like in order for launchpad to recognize that a bug was closed?''

 very good question -- we haven't decided yet. I'd love to get your opinion on the matter in #launchpad or on launchpad-users. this feature is upcoming and I think it'll be a really neat one. so be sure to ping me about it

''<paran> Are there any way to use Bazaar to send your work back upstream when you use a bazaar branch from VCS imports?''

 not yet! that's a really good observation -- you need to produce diffs and communicate directly with upstream to get it submitted. you can work with upstream to get them to use certain Launchpad features to make the integration easier (for instance, the bug tracker, since you could pick out branches from bugs) and you can offer upstream with the address of your bazaar branch to make it easy for them to pull in your changes. there is a planned but not yet scheduled feature that would simplify this for at least Subversion-hosted projects, but it's a non-trivial endeavour and I've been suffering over that project of late.
{{{
11:01	kiko	well, wow, my hour is already up!
11:01	kiko	(I do talk a lot as you have realized by now)
11:01	kiko	if you have any further questions, /please/ drop by #launchpad and let me know
11:01	kiko	suggestions are equally appreciated
11:02	kiko	I'll post a rehash of questions to launchpad-users tomorrow so people that missed out on them can check them out
11:03	kiko	feel free to email me directly (kiko at canonical.com) or via launchpad-users (https://lists.ubuntu.com/mailman/listinfo/launchpad-users)
11:03	kiko	I'll be happy to follow up
11:03	kiko	thanks for being here and picking up all these electrons I'm sending out
11:03	kiko	I wish everybody a nice thursday evening and see you on #launchpad
}}}