launchpad development|
Size: 15758
Comment:
|
Size: 14848
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| == IRC session: "Getting started with Launchpad development" == ''Graham Binns conducted an IRC session entitled [[https://wiki.ubuntu.com/MeetingLogs/devweek0909/LPDevelopment|Getting started with Launchpad development]] on 2 September 2009, as part of Ubuntu Dev Week. Here's a transcript:'' {{{ <gmb> My name's Graham Binns. I'm a member of the Launchpad Bugs development team. <gmb> I'm going to talk today about getting started with Launchpad development, in the hope that it might make it easier for you guys to contribute patches to scratch your least favourite itches. <gmb> Hopefully you'll have all completed the instructions at http://dev.launchpad.net/Getting so that you can follow along with this session. If not, you might struggle a bit, but you can always go back once the session is over and follow it through on your own time. <gmb> If you've any questions, please shout them out in #ubuntu-classroom-chat and prefix them with QUESTION so that I can see them easier :) <gmb> Okay, so, first things first, we need to find us a bug to fix. For the purposes of this session I've filed a made-up bug on staging for us to fix https://staging.launchpad.net/bugs/422299. I've gone with this because: <gmb> 1) It's fairly simple to fix. 2) It's easy to demonstrate our test-driven development process whilst we fix it, which is why I didn't pick a bug in the UI. 3) There were no really trivial bugs available for us to try this out on :). <gmb> When you're working on fixing a bug in Launchpad, you nearly always want to be doing it in a new branch. <gmb> We try to keep to one bug per branch, because that means that it's much easier to review the patches when they're done (because they're smaller, natch :)) |
<INTRO> IRC session "Getting started with Launchpad development" <INTRO> Given 2 September 2009 by Graham Binns (gmb) as part of Ubuntu Dev Week; see https://wiki.ubuntu.com/MeetingLogs/devweek0909/LPDevelopment. <INTRO> Take it away, Graham!... <gmb> My name's Graham Binns. I'm a member of the Launchpad Bugs development team. <gmb> I'm going to talk today about getting started with Launchpad development, in the hope that it might make it easier for you guys to contribute patches to scratch your least favourite itches. <gmb> Hopefully you'll have all completed the instructions at http://dev.launchpad.net/Getting so that you can follow along with this session. If not, you might struggle a bit, but you can always go back once the session is over and follow it through on your own time. <gmb> If you've any questions, please shout them out in #ubuntu-classroom-chat and prefix them with QUESTION so that I can see them easier :) <gmb> Okay, so, first things first, we need to find us a bug to fix. For the purposes of this session I've filed a made-up bug on staging for us to fix https://staging.launchpad.net/bugs/422299. I've gone with this because: <gmb> 1) It's fairly simple to fix. 2) It's easy to demonstrate our test-driven development process whilst we fix it, which is why I didn't pick a bug in the UI. 3) There were no really trivial bugs available for us to try this out on :). <gmb> When you're working on fixing a bug in Launchpad, you nearly always want to be doing it in a new branch. <gmb> We try to keep to one bug per branch, because that means that it's much easier to review the patches when they're done (because they're smaller, natch :)) |
| Line 43: | Line 27: |
| <gmb> If you've set up the Launchpad development environment properly according to http://dev.launchpad.net/Getting, you should be able to run the following command: |
<gmb> If you've set up the Launchpad development environment properly according to http://dev.launchpad.net/Getting, you should be able to run the following command: |
| Line 53: | Line 35: |
| <gmb> but I've also given the branch a useful name to help me remember what it's for if I have to leave it for a while. <gmb> rocketfuel-branch takes a few seconds, so I'll just wait a minute for everyone to catch up. <gmb> (By the way, if anyone has any problems with rocketfuel-get or any other part of this lesson, please come find me afterwards in #launchpad and I'll try to help you out) |
<gmb> but I've also given the branch a useful name to help me remember what it's for if I have to leave it for a while. <gmb> rocketfuel-branch takes a few seconds, so I'll just wait a minute for everyone to catch up. <gmb> (By the way, if anyone has any problems with rocketfuel-get or any other part of this lesson, please come find me afterwards in #launchpad and I'll try to help you out) |
| Line 71: | Line 49: |
| <gmb> you'd ideally have a chat with a member of the Launchpad development team about your intended fix. <gmb> We normally do this either on IRC or on Skype, depending on your preference. <gmb> You can usually find a Launchpad developer in #launchpad-dev on Freenode who'll be available for one of these calls. <gmb> The call gives you a chance to ensure that what you're doing is actually sane. <gmb> For some bugs there's only one possible fix, complex or otherwise. For others there may be many ways to do it, and it's important to pick the right one. <gmb> If your solution is particularly complex or you need to demonstrate *why* you want to do things the way you do, it may help to write some tests to reproduce the bug before you have the call. |
<gmb> you'd ideally have a chat with a member of the Launchpad development team about your intended fix. <gmb> We normally do this either on IRC or on Skype, depending on your preference. <gmb> You can usually find a Launchpad developer in #launchpad-dev on Freenode who'll be available for one of these calls. <gmb> The call gives you a chance to ensure that what you're doing is actually sane. <gmb> For some bugs there's only one possible fix, complex or otherwise. For others there may be many ways to do it, and it's important to pick the right one. <gmb> If your solution is particularly complex or you need to demonstrate *why* you want to do things the way you do, it may help to write some tests to reproduce the bug before you have the call. |
| Line 94: | Line 63: |
| <gmb> you shouldn't make any changes to the actual code until you've had the pre-implementation call or chat with an LP developer. |
<gmb> you shouldn't make any changes to the actual code until you've had the pre-implementation call or chat with an LP developer. |
| Line 107: | Line 75: |
| <gmb> Under lib/lp you'll find most of the Launchpad code, split up into its applications. <gmb> So, `ls lib/lp` in your new getting-started-with-lp-bug-422299 branch should give you something like this: |
<gmb> Under lib/lp you'll find most of the Launchpad code, split up into its applications. <gmb> So, `ls lib/lp` in your new getting-started-with-lp-bug-422299 branch should give you something like this: |
| Line 115: | Line 81: |
| <gmb> answers archiveuploader buildmaster coop registry soyuz <gmb> app blueprints code __init__.py scripts testing <gmb> archivepublisher bugs codehosting __init__.pyc services translations <gmb> Now, we know that we're working in the bugs application, so lets take a look in there to see where to put our tests: |
<gmb> answers archiveuploader buildmaster coop registry soyuz <gmb> app blueprints code __init__.py scripts testing <gmb> archivepublisher bugs codehosting __init__.pyc services translations <gmb> Now, we know that we're working in the bugs application, so lets take a look in there to see where to put our tests: |
| Line 129: | Line 91: |
| <gmb> adapters emailtemplates help model stories windmill <gmb> browser event __init__.py notifications subscribers xmlrpc <gmb> configure.zcml externalbugtracker __init__.pyc pagetests templates <gmb> doc feed interfaces scripts tests <gmb> There are three types of test in Launchpad: doctests, which live in lib/lp/$app/doc; stories, which live in lib/lp/$app/stories and unittests, which live in lib/lp/$app/tests. <gmb> In this case we want to add to an existing doctest, so I'll stick with that for now and we can come back to what the others are for later. <gmb> So, in lib/lp/bugs/doc/ you'll find a file called externalbugtracker-trac.txt. <gmb> This is the test we want to modify, so feel free to open it in your text editor and take a look at line 110, which is where we're going to add our test. <gmb> For the sake of making this quicker, I've already created a diff of the change that I'd make here: http://pastebin.ubuntu.com/263869/plain/ <gmb> You can save that to disk somewhere (e.g. /tmp/diff) and then apply it as a patch using `bzr patch /tmp/diff` in the root of your new Launchpad branch. |
<gmb> adapters emailtemplates help model stories windmillnnn <gmb> browser event __init__.py notifications subscribers xmlrpc <gmb> configure.zcml externalbugtracker __init__.pyc pagetests templates <gmb> doc feed interfaces scripts tests <gmb> There are three types of test in Launchpad: doctests, which live in lib/lp/$app/doc; stories, which live in lib/lp/$app/stories and unittests, which live in lib/lp/$app/tests. <gmb> In this case we want to add to an existing doctest, so I'll stick with that for now and we can come back to what the others are for later. <gmb> So, in lib/lp/bugs/doc/ you'll find a file called externalbugtracker-trac.txt. <gmb> This is the test we want to modify, so feel free to open it in your text editor and take a look at line 110, which is where we're going to add our test. <gmb> For the sake of making this quicker, I've already created a diff of the change that I'd make here: http://pastebin.ubuntu.com/263869/plain/ <gmb> You can save that to disk somewhere (e.g. /tmp/diff) and then apply it as a patch using `bzr patch /tmp/diff` in the root of your new Launchpad branch. |
| Line 166: | Line 113: |
| <gmb> It passes 'frobnob' to the convertRemoteStatus() method of a Trac instance (which is just an abstraction that lets us talk to an actual Trac server) |
<gmb> It passes 'frobnob' to the convertRemoteStatus() method of a Trac instance (which is just an abstraction that lets us talk to an actual Trac server) |
| Line 176: | Line 121: |
| <gmb> This part is very important: your tests should always fail first and only after they fail do you write the code to make them pass. <gmb> That means that you can use the tests to build a good spec of how your module / class / function / whatever should behave. <gmb> It also means that, like I said before, you can use the failing tests to demonstrate what your fix will actually change to whoever you have a call with. |
<gmb> This part is very important: your tests should always fail first and only after they fail do you write the code to make them pass. <gmb> That means that you can use the tests to build a good spec of how your module / class / function / whatever should behave. <gmb> It also means that, like I said before, you can use the failing tests to demonstrate what your fix will actually change to whoever you have a call with. |
| Line 190: | Line 131: |
| <gmb> That might take a short while to run (Launchpad's test suite can be frustratingly slow sometimes, but don't let that put you off; the payoff is worth it) <gmb> The output from which should look something like this: http://pastebin.ubuntu.com/263874/ |
<gmb> That might take a short while to run (Launchpad's test suite can be frustratingly slow sometimes, but don't let that put you off; the payoff is worth it) <gmb> The output from which should look something like this: http://pastebin.ubuntu.com/263874/ |
| Line 199: | Line 137: |
| <gmb> File "lib/lp/bugs/tests/../doc/externalbugtracker-trac.txt", line 111, in externalbugtracker-trac.txt |
<gmb> File "lib/lp/bugs/tests/../doc/externalbugtracker-trac.txt", line 111, in externalbugtracker-trac.txt |
| Line 210: | Line 147: |
| <gmb> File "/home/graham/canonical/lp-sourcedeps/eggs/zope.testing-3.8.1-py2.4.egg/zope/testing/doctest.py", line 1361, in __run |
<gmb> File "/home/graham/canonical/lp-sourcedeps/eggs/zope.testing-3.8.1-py2.4.egg/zope/testing/doctest.py", line 1361, in __run |
| Line 216: | Line 151: |
| <gmb> File "<doctest externalbugtracker-trac.txt[line 111, example 35]>", line 1, in ? <gmb> File "/home/graham/canonical/lp-branches/lesson/lib/lp/bugs/externalbugtracker/trac.py", line 265, in convertRemoteStatus |
<gmb> File "<doctest externalbugtracker-trac.txt[line 111, example 35]>", line 1, in ? <gmb> File "/home/graham/canonical/lp-branches/lesson/lib/lp/bugs/externalbugtracker/trac.py", line 265, in convertRemoteStatus |
| Line 227: | Line 159: |
| <gmb> This tells us that the test failed, which is exactly what we wanted. |
<gmb> This tells us that the test failed, which is exactly what we wanted. |
| Line 232: | Line 163: |
| <gmb> nvertRemoteStatus() raised an UnknownRemoteStatusError instead of giving us back the status we wanted. |
<gmb> nvertRemoteStatus() raised an UnknownRemoteStatusError instead of giving us back the status we wanted. |
| Line 241: | Line 171: |
| <gmb> Again - I can't emphasise this enough - the fact that your test fails is a Good Thing. If it didn't fail, it wouldn't be a good test, since we know that the bug actually exists in the code. <gmb> Now that we have a test that fails, we want to add some code to make it pass |
<gmb> Again - I can't emphasise this enough - the fact that your test fails is a Good Thing. If it didn't fail, it wouldn't be a good test, since we know that the bug actually exists in the code. <gmb> Now that we have a test that fails, we want to add some code to make it pass |
| Line 250: | Line 177: |
| <gmb> Now, as it happens, I knew that before I started, but you can work it out by looking at the top of the doctest file that we just edited. <gmb> So, open lib/lp/bugs/externalbugtracker/trac.py now and take a look at line 258. We'll add our fix here. <gmb> The fix is really simple, and we can pretty much copy line 255 and alter it to suit our needs. <gmb> We want 'frobnob' to map to 'Fix Released', so we add the following line: |
<gmb> Now, as it happens, I knew that before I started, but you can work it out by looking at the top of the doctest file that we just edited. <gmb> So, open lib/lp/bugs/externalbugtracker/trac.py now and take a look at line 258. We'll add our fix here. <gmb> The fix is really simple, and we can pretty much copy line 255 and alter it to suit our needs. <gmb> We want 'frobnob' to map to 'Fix Released', so we add the following line: |
| Line 265: | Line 187: |
| <gmb> I'll not go into the nitty-gritty of how status lookups work here, because it's unimportant. <gmb> Suffice it to say that in Trac's case it's a simple pair of values, (remote_status, launchpad_status). |
<gmb> I'll not go into the nitty-gritty of how status lookups work here, because it's unimportant. <gmb> Suffice it to say that in Trac's case it's a simple pair of values, (remote_status, launchpad_status). |
| Line 287: | Line 207: |
| <gmb> (Note that this is a lame description of the fix; you should use something more descriptive). |
<gmb> (Note that this is a lame description of the fix; you should use something more descriptive). |
| Line 294: | Line 213: |
| <gmb> Launchpad developers use the Launchpad code review system to review Launchpad branches. |
<gmb> Launchpad developers use the Launchpad code review system to review Launchpad branches. |
| Line 301: | Line 219: |
| <gmb> And it also acts as a sanity check to make sure that the developer hasn't done something unnecessarily odd in their fix. <gmb> So at this point, you need to push your branch to Launchpad using the `bzr push` command: |
<gmb> And it also acts as a sanity check to make sure that the developer hasn't done something unnecessarily odd in their fix. <gmb> So at this point, you need to push your branch to Launchpad using the `bzr push` command: |
| Line 309: | Line 225: |
| <gmb> Once the branch has been pushed up to Launchpad it gets its own page in the Launchpad web interface, which you can look at by running: |
<gmb> Once the branch has been pushed up to Launchpad it gets its own page in the Launchpad web interface, which you can look at by running: |
| Line 317: | Line 231: |
| <gmb> Now that you've fixed the bug and pushed the branch to Launchpad you need to request a review for it. <gmb> To do this, go to the branch page in your browser and click the "Propose for merging into another branch" link. |
<gmb> Now that you've fixed the bug and pushed the branch to Launchpad you need to request a review for it. <gmb> To do this, go to the branch page in your browser and click the "Propose for merging into another branch" link. |
| Line 327: | Line 239: |
| <gmb> In the "Initial comment" box, you need to type a description of the branch. |
<gmb> In the "Initial comment" box, you need to type a description of the branch. |
| Line 332: | Line 243: |
| <gmb> "This branch fixes bug 422299 by making Trac.convertRemoteStatus() map the "frobnob" status to Launchpad's Fix Released status." <gmb> After you've typed in your description, hit the "Propose merge" button and you should see a page that looks something like this: https://code.edge.launchpad.net/~gmb/launchpad/lesson/+merge/11068 <gmb> You then need to head on over to #launchpad-reviews on Freenode and ask if anyone's available to review your branch. |
<gmb> "This branch fixes bug 422299 by making Trac.convertRemoteStatus() map the "frobnob" status to Launchpad's Fix Released status." <gmb> After you've typed in your description, hit the "Propose merge" button and you should see a page that looks something like this: https://code.edge.launchpad.net/~gmb/launchpad/lesson/+merge/11068 <gmb> You then need to head on over to #launchpad-reviews on Freenode and ask if anyone's available to review your branch. |
| Line 344: | Line 251: |
| <gmb> We have a reviewer schedule: http://dev.launchpad.net/ReviewerSchedule, so someone should take a look at it withing 24 hours. |
<gmb> We have a reviewer schedule: http://dev.launchpad.net/ReviewerSchedule, so someone should take a look at it withing 24 hours. |
| Line 354: | Line 259: |
| <gmb> Once the reviewer has signed off on the changes, they'll submit the branch for merging for you. |
<gmb> Once the reviewer has signed off on the changes, they'll submit the branch for merging for you. |
| Line 363: | Line 267: |
| <gmb> But it's likely that someone else will take care of it if you're not around at the time |
<gmb> But it's likely that someone else will take care of it if you're not around at the time |
| Line 368: | Line 271: |
| <gmb> Are there any questions? Please shout them out in #ubuntu-classroom-chat <gmb> < ahe> QUESTION: When will launchpad be available as a package in the standard distribution? <gmb> ahe: At this point, there aren't any plans for that. We released the code for Launchpad because we wanted to let people help to improve the service, but we've no plans as far as I'm aware to distribute it as a package. <gmb> < Andphe> question: have you planned guys, offer launchpad in another languages than english, example spanish ? <gmb> Andphe: It's something that we've considered and that we would like to do at some point, at least for certain parts of the interface. <gmb> The problem is that launchpad is meant to be a global collaboration tool, and if we translate it wholesale into other languages that automatically means that a certain amount of collaboration will be lost <gmb> For exampel, if a user reads the interface in Spanish and files a bug in Spanish, how am I, an non-Spanish speaker, going to be able to deal with that bug report? <gmb> However, internationalisation would work quite well for the Answers application, and it's already built with that in mind. <gmb> < ahe> QUESTION: Do you deploy launchpad manually or are there some helper scripts or stuff like that to ease the deployment in a production environment? |
<gmb> Are there any questions? Please shout them out in #ubuntu-classroom-chat <gmb> < ahe> QUESTION: When will launchpad be available as a package in the standard distribution? <gmb> ahe: At this point, there aren't any plans for that. We released the code for Launchpad because we wanted to let people help to improve the service, but we've no plans as far as I'm aware to distribute it as a package. <gmb> < Andphe> question: have you planned guys, offer launchpad in another languages than english, example spanish ? <gmb> Andphe: It's something that we've considered and that we would like to do at some point, at least for certain parts of the interface. <gmb> The problem is that launchpad is meant to be a global collaboration tool, and if we translate it wholesale into other languages that automatically means that a certain amount of collaboration will be lost <gmb> For exampel, if a user reads the interface in Spanish and files a bug in Spanish, how am I, an non-Spanish speaker, going to be able to deal with that bug report? <gmb> However, internationalisation would work quite well for the Answers application, and it's already built with that in mind. <gmb> < ahe> QUESTION: Do you deploy launchpad manually or are there some helper scripts or stuff like that to ease the deployment in a production environment? |
| Line 404: | Line 291: |
| <gmb> edge.launchpad.net is deployed by a script every night, as is staging.launchpad.net. <gmb> The production servers are updated manually by our sysadmins at least once per cycle (though it's usually more than that since we discover urgent bugs that need to be fixed). <gmb> < Andphe> question: if answers already support another languages, how can we help to translate it ? <gmb> Andphe: It's built with translation in mind, but I don't know what work needs doing to make it translatable. <gmb> Andphe: Your best bet would be to join the Launchpad Developers mailing list (http://launchpad.net/~launchpad-dev) and post a question about it there. |
<gmb> edge.launchpad.net is deployed by a script every night, as is staging.launchpad.net. <gmb> The production servers are updated manually by our sysadmins at least once per cycle (though it's usually more than that since we discover urgent bugs that need to be fixed). <gmb> < Andphe> question: if answers already support another languages, how can we help to translate it ? <gmb> Andphe: It's built with translation in mind, but I don't know what work needs doing to make it translatable. <gmb> Andphe: Your best bet would be to join the Launchpad Developers mailing list (http://launchpad.net/~launchpad-dev) and post a question about it there. |
| Line 423: | Line 303: |
| <gmb> If you've any further questions, please feel free to join the Launchpad Dev list (above) |
<gmb> If you've any further questions, please feel free to join the Launchpad Dev list (above) |
| Line 431: | Line 310: |
| }}} |
1 <INTRO> IRC session "Getting started with Launchpad development"
2
3 <INTRO> Given 2 September 2009 by Graham Binns (gmb) as part of Ubuntu Dev Week; see https://wiki.ubuntu.com/MeetingLogs/devweek0909/LPDevelopment.
4
5 <INTRO> Take it away, Graham!...
6
7 <gmb> My name's Graham Binns. I'm a member of the Launchpad Bugs development team.
8
9 <gmb> I'm going to talk today about getting started with Launchpad development, in the hope that it might make it easier for you guys to contribute patches to scratch your least favourite itches.
10
11 <gmb> Hopefully you'll have all completed the instructions at http://dev.launchpad.net/Getting so that you can follow along with this session. If not, you might struggle a bit, but you can always go back once the session is over and follow it through on your own time.
12
13 <gmb> If you've any questions, please shout them out in #ubuntu-classroom-chat and prefix them with QUESTION so that I can see them easier :)
14
15 <gmb> Okay, so, first things first, we need to find us a bug to fix. For the purposes of this session I've filed a made-up bug on staging for us to fix https://staging.launchpad.net/bugs/422299. I've gone with this because:
16
17 <gmb> 1) It's fairly simple to fix. 2) It's easy to demonstrate our test-driven development process whilst we fix it, which is why I didn't pick a bug in the UI. 3) There were no really trivial bugs available for us to try this out on :).
18
19 <gmb> When you're working on fixing a bug in Launchpad, you nearly always want to be doing it in a new branch.
20
21 <gmb> We try to keep to one bug per branch, because that means that it's much easier to review the patches when they're done (because they're smaller, natch :))
22
23 <gmb> So, let's create a branch in which to fix the bug.
24
25 <gmb> If you've set up the Launchpad development environment properly according to http://dev.launchpad.net/Getting, you should be able to run the following command:
26
27 <gmb> $ rocketfuel-branch getting-started-with-lp-bug-422299
28
29 <gmb> Note that I've appended the bug number to the branch
30
31 <gmb> so that I can always refer to it if I need to
32
33 <gmb> but I've also given the branch a useful name to help me remember what it's for if I have to leave it for a while.
34
35 <gmb> rocketfuel-branch takes a few seconds, so I'll just wait a minute for everyone to catch up.
36
37 <gmb> (By the way, if anyone has any problems with rocketfuel-get or any other part of this lesson, please come find me afterwards in #launchpad and I'll try to help you out)
38
39 <gmb> s/-get/-branch/ there, sorry.
40
41 <gmb> Okay.
42
43 <gmb> Now, at this point, once you'd decided how to fix the bug
44
45 <gmb> but - importantly - before you start coding
46
47 <gmb> you'd ideally have a chat with a member of the Launchpad development team about your intended fix.
48
49 <gmb> We normally do this either on IRC or on Skype, depending on your preference.
50
51 <gmb> You can usually find a Launchpad developer in #launchpad-dev on Freenode who'll be available for one of these calls.
52
53 <gmb> The call gives you a chance to ensure that what you're doing is actually sane.
54
55 <gmb> For some bugs there's only one possible fix, complex or otherwise. For others there may be many ways to do it, and it's important to pick the right one.
56
57 <gmb> If your solution is particularly complex or you need to demonstrate *why* you want to do things the way you do, it may help to write some tests to reproduce the bug before you have the call.
58
59 <gmb> Note that the tests should always fail at this point;
60
61 <gmb> you shouldn't make any changes to the actual code until you've had the pre-implementation call or chat with an LP developer.
62
63 <gmb> Okay, so that's the info-dumpy bit of this session over for now :)
64
65 [*** gmb accidentally drops from channel for momentarily ***]
66
67 <gmb> Sorry about that, all.
68
69 <gmb> I have a rather flaky connection today :)
70
71 <gmb> As I was saying...
72
73 <gmb> Under lib/lp you'll find most of the Launchpad code, split up into its applications.
74
75 <gmb> So, `ls lib/lp` in your new getting-started-with-lp-bug-422299 branch should give you something like this:
76
77 <gmb> $ ls lib/lp
78
79 <gmb> answers archiveuploader buildmaster coop registry soyuz
80
81 <gmb> app blueprints code __init__.py scripts testing
82
83 <gmb> archivepublisher bugs codehosting __init__.pyc services translations
84
85 <gmb> Now, we know that we're working in the bugs application, so lets take a look in there to see where to put our tests:
86
87 <gmb> $ ls lib/lp/bugs
88
89 <gmb> adapters emailtemplates help model stories windmillnnn
90
91 <gmb> browser event __init__.py notifications subscribers xmlrpc
92
93 <gmb> configure.zcml externalbugtracker __init__.pyc pagetests templates
94
95 <gmb> doc feed interfaces scripts tests
96
97 <gmb> There are three types of test in Launchpad: doctests, which live in lib/lp/$app/doc; stories, which live in lib/lp/$app/stories and unittests, which live in lib/lp/$app/tests.
98
99 <gmb> In this case we want to add to an existing doctest, so I'll stick with that for now and we can come back to what the others are for later.
100
101 <gmb> So, in lib/lp/bugs/doc/ you'll find a file called externalbugtracker-trac.txt.
102
103 <gmb> This is the test we want to modify, so feel free to open it in your text editor and take a look at line 110, which is where we're going to add our test.
104
105 <gmb> For the sake of making this quicker, I've already created a diff of the change that I'd make here: http://pastebin.ubuntu.com/263869/plain/
106
107 <gmb> You can save that to disk somewhere (e.g. /tmp/diff) and then apply it as a patch using `bzr patch /tmp/diff` in the root of your new Launchpad branch.
108
109 <gmb> The test we've just added is really simple.
110
111 <gmb> It passes 'frobnob' to the convertRemoteStatus() method of a Trac instance (which is just an abstraction that lets us talk to an actual Trac server)
112
113 <gmb> and expects to get "Fix Released" back.
114
115 <gmb> Of course, it doesn't since we haven't implemented that yet :).
116
117 <gmb> Once we've written the test, we run it to make sure it fails.
118
119 <gmb> This part is very important: your tests should always fail first and only after they fail do you write the code to make them pass.
120
121 <gmb> That means that you can use the tests to build a good spec of how your module / class / function / whatever should behave.
122
123 <gmb> It also means that, like I said before, you can use the failing tests to demonstrate what your fix will actually change to whoever you have a call with.
124
125 <gmb> To run this specific test only, we use the `bin/test` command:
126
127 <gmb> $ bin/test -vvt externalbugtracker-trac.txt
128
129 <gmb> That might take a short while to run (Launchpad's test suite can be frustratingly slow sometimes, but don't let that put you off; the payoff is worth it)
130
131 <gmb> The output from which should look something like this: http://pastebin.ubuntu.com/263874/
132
133 <gmb> Note the important bit:
134
135 <gmb> File "lib/lp/bugs/tests/../doc/externalbugtracker-trac.txt", line 111, in externalbugtracker-trac.txt
136
137 <gmb> Failed example:
138
139 <gmb> trac.convertRemoteStatus('frobnob').title
140
141 <gmb> Exception raised:
142
143 <gmb> Traceback (most recent call last):
144
145 <gmb> File "/home/graham/canonical/lp-sourcedeps/eggs/zope.testing-3.8.1-py2.4.egg/zope/testing/doctest.py", line 1361, in __run
146
147 <gmb> compileflags, 1) in test.globs
148
149 <gmb> File "<doctest externalbugtracker-trac.txt[line 111, example 35]>", line 1, in ?
150
151 <gmb> File "/home/graham/canonical/lp-branches/lesson/lib/lp/bugs/externalbugtracker/trac.py", line 265, in convertRemoteStatus
152
153 <gmb> raise UnknownRemoteStatusError(remote_status)
154
155 <gmb> UnknownRemoteStatusError: frobnob
156
157 <gmb> This tells us that the test failed, which is exactly what we wanted.
158
159 <gmb> (Yes, copying and pasting in IRC makes me a bad man.)
160
161 <gmb> nvertRemoteStatus() raised an UnknownRemoteStatusError instead of giving us back the status we wanted.
162
163 <gmb> Which was, of course, the 'Fix Released' status.
164
165 <gmb> At this point, you might want to commit the changes:
166
167 <gmb> $ bzr commit -m "Added tests for bug 422299."
168
169 <gmb> Again - I can't emphasise this enough - the fact that your test fails is a Good Thing. If it didn't fail, it wouldn't be a good test, since we know that the bug actually exists in the code.
170
171 <gmb> Now that we have a test that fails, we want to add some code to make it pass
172
173 <gmb> We want to add this to lib/lp/bugs/externalbugtracker/trac.py.
174
175 <gmb> Now, as it happens, I knew that before I started, but you can work it out by looking at the top of the doctest file that we just edited.
176
177 <gmb> So, open lib/lp/bugs/externalbugtracker/trac.py now and take a look at line 258. We'll add our fix here.
178
179 <gmb> The fix is really simple, and we can pretty much copy line 255 and alter it to suit our needs.
180
181 <gmb> We want 'frobnob' to map to 'Fix Released', so we add the following line:
182
183 <gmb> ('frobnob', BugTaskStatus.FIXRELEASED),
184
185 <gmb> I'll not go into the nitty-gritty of how status lookups work here, because it's unimportant.
186
187 <gmb> Suffice it to say that in Trac's case it's a simple pair of values, (remote_status, launchpad_status).
188
189 <gmb> Here's a diff of that change: http://pastebin.ubuntu.com/263882/
190
191 <gmb> Now that we've added a fix for the bug, we run the test again:
192
193 <gmb> $ bin/test -vvt externalbugtracker-trac.txt
194
195 <gmb> This time, it should pass without any problems...
196
197 <gmb> and it does
198
199 <gmb> http://pastebin.ubuntu.com/263885/
200
201 <gmb> So, now we commit our changes:
202
203 <gmb> $ bzr ci -m "Fixed bug 422299"
204
205 <gmb> (Note that this is a lame description of the fix; you should use something more descriptive).
206
207 <gmb> So, we now have a branch that fixes a bug. Hurrah and all that.
208
209 <gmb> Now we need to get it into the Launchpad tree.
210
211 <gmb> Launchpad developers use the Launchpad code review system to review Launchpad branches.
212
213 <gmb> You can't land a branch without having it reviewed first
214
215 <gmb> This allows us to ensure that code quality stays high
216
217 <gmb> And it also acts as a sanity check to make sure that the developer hasn't done something unnecessarily odd in their fix.
218
219 <gmb> So at this point, you need to push your branch to Launchpad using the `bzr push` command:
220
221 <gmb> $ bzr push
222
223 <gmb> Once the branch has been pushed up to Launchpad it gets its own page in the Launchpad web interface, which you can look at by running:
224
225 <gmb> $ bzr lp-open
226
227 <gmb> This should open the page in your default browser.
228
229 <gmb> Now that you've fixed the bug and pushed the branch to Launchpad you need to request a review for it.
230
231 <gmb> To do this, go to the branch page in your browser and click the "Propose for merging into another branch" link.
232
233 <gmb> This will take you to a page that looks like this:
234
235 <gmb> http://people.ubuntu.com/~gbinns/propose-merge.png
236
237 <gmb> In the "Initial comment" box, you need to type a description of the branch.
238
239 <gmb> For example, for this branch I'd write something like:
240
241 <gmb> "This branch fixes bug 422299 by making Trac.convertRemoteStatus() map the "frobnob" status to Launchpad's Fix Released status."
242
243 <gmb> After you've typed in your description, hit the "Propose merge" button and you should see a page that looks something like this: https://code.edge.launchpad.net/~gmb/launchpad/lesson/+merge/11068
244
245 <gmb> You then need to head on over to #launchpad-reviews on Freenode and ask if anyone's available to review your branch.
246
247 <gmb> If there's no-one available at the time, don't worry.
248
249 <gmb> We have a reviewer schedule: http://dev.launchpad.net/ReviewerSchedule, so someone should take a look at it withing 24 hours.
250
251 <gmb> The reviewer may ask you to make changes to your branch
252
253 <gmb> To bring your fix into line with our coding standards
254
255 <gmb> Or maybe to fix a bug that they've spotted in your fix.
256
257 <gmb> Once the reviewer has signed off on the changes, they'll submit the branch for merging for you.
258
259 <gmb> When a branch gets merged, the entire test suite is run against it
260
261 <gmb> If any of the tests fail
262
263 <gmb> The reviewer may ask you to help fix them
264
265 <gmb> But it's likely that someone else will take care of it if you're not around at the time
266
267 <gmb> And that's about all there is to simple Launchpad development :)
268
269 <gmb> Are there any questions? Please shout them out in #ubuntu-classroom-chat
270
271 <gmb> < ahe> QUESTION: When will launchpad be available as a package in the standard distribution?
272
273 <gmb> ahe: At this point, there aren't any plans for that. We released the code for Launchpad because we wanted to let people help to improve the service, but we've no plans as far as I'm aware to distribute it as a package.
274
275 <gmb> < Andphe> question: have you planned guys, offer launchpad in another languages than english, example spanish ?
276
277 <gmb> Andphe: It's something that we've considered and that we would like to do at some point, at least for certain parts of the interface.
278
279 <gmb> The problem is that launchpad is meant to be a global collaboration tool, and if we translate it wholesale into other languages that automatically means that a certain amount of collaboration will be lost
280
281 <gmb> For exampel, if a user reads the interface in Spanish and files a bug in Spanish, how am I, an non-Spanish speaker, going to be able to deal with that bug report?
282
283 <gmb> However, internationalisation would work quite well for the Answers application, and it's already built with that in mind.
284
285 <gmb> < ahe> QUESTION: Do you deploy launchpad manually or are there some helper scripts or stuff like that to ease the deployment in a production environment?
286
287 <gmb> It's a combination of the two.
288
289 <gmb> edge.launchpad.net is deployed by a script every night, as is staging.launchpad.net.
290
291 <gmb> The production servers are updated manually by our sysadmins at least once per cycle (though it's usually more than that since we discover urgent bugs that need to be fixed).
292
293 <gmb> < Andphe> question: if answers already support another languages, how can we help to translate it ?
294
295 <gmb> Andphe: It's built with translation in mind, but I don't know what work needs doing to make it translatable.
296
297 <gmb> Andphe: Your best bet would be to join the Launchpad Developers mailing list (http://launchpad.net/~launchpad-dev) and post a question about it there.
298
299 <gmb> I think that's about all we've got time for.
300
301 <gmb> If you've any further questions, please feel free to join the Launchpad Dev list (above)
302
303 <gmb> And ask there.
304
305 <gmb> Everyone's welcome to contribute.
306
307 <gmb> Thanks very much for your time.
