[13:15] j1mc: hi. Was just checking in to see how things are going [13:15] j1mc: I've uploaded a package this morning, we'll see if it gets approved [13:16] j1mc: the add/remove software topic is still empty, is someone working on that? if not I might work on it if i get time over the next day or two [13:16] Hi there. [13:16] issyl0: heya! [13:17] issyl0: welcome to the team, you've joined at a rather frenetic time so things probably seem a bit confused... [13:17] Hah, that's alright! I like frantic - it gives projects personality. :-) [13:17] So, what's going on, and what can I help out with? :-) [13:17] I'm eager. [13:18] i'm not sure ours is the greatest personality right now but it will get better hopefully with some new contributors around [13:18] issyl0: essentially we are converting the Gnome 3 docs to fit with Unity at the last minute before natty releases [13:19] issyl0: there are probably plenty of things to help with, probably j1mc is the person to check with to see what is being worked on [13:19] Oooh, yes, I'd seen a mailing list post about that. Interesting! [13:19] OK, thanks. [13:20] good to have you aboard [13:20] :-) [13:26] mdke: thanks for your help. [13:26] Ah yes, you may have seen: http://bazaar.launchpad.net/~issyl0/ubuntu-docs/issyl0/view/head:/teamstuff/audience-analysis.xml , with a couple of edits referring to http://bazaar.launchpad.net/~ubuntu-core-doc/ubuntu-docs/natty/view/head:/teamstuff/audience-analysis.xml :-) [13:26] i'm sorting out the networking section, and should be able to wrap that up today. [13:27] that has been some interesting refactoring work because i wasn't sure how to get things to set things up how i wanted them. [13:27] i had to teach myself by looking at other examples. [13:28] (I read it, some of it didn't make sense, I realised I couldn't commit changes directly, I created my own branch of it. That's the correct procedure initially, I hope?) [13:28] hi issyl0 [13:28] Hi j1mc. I'm looking to increase my involvement, and as mdke says you're the person I should talk to... :-) [13:29] :) thanks. what is drawing you in to docs? any area where you are looking to contribute in particular? [13:31] Oh, I just love documentation and would like to help out in any way I can. I'm not so much of an author, but a keen editor. And a quest for further knowledge draws me in, too. [13:31] mdke: what do you think of the web stuff? [13:31] issyl0: sounds good. are you familiar with bzr and launchpad at all? [13:31] also, what version of ubuntu are you using? [13:32] mdke: by "web stuff" i mean the draft of the xslt file that shaunm put together. [13:32] j1mc: Natty, Beta 2 on my desktop machine. :-) [13:32] j1mc: I think it looks excellent. We can tinker with it later once we have the final package sorted [13:32] j1mc: And yes, familiar with launchpad and bzr - they're great. [13:33] (I'm involved in the Ubuntu Manual project as well.) [13:33] issyl0: wonderful... [13:33] issyl0: as for how you can help us now, we are porting over the help from gnome3 to unity... [13:34] ... so the best way to help is to grab the current mallard sources from bzr... [13:34] OK. [13:34] ...and view them in yelp to see if the text makes sense for unity [13:35] j1mc: what's the plan for the add/remove topic? [13:35] the branch that we're working on now is: https://code.launchpad.net/~ubuntu-core-doc/gnome-user-docs/natty [13:35] mdke: i was going to port-over the ad-remove topics from the older ubuntu help. [13:36] sounds good. do you think that is something issyl0 could have a go at? [13:37] probably. it might make for an interesting introduction to mallard. if issyl0 is comfortable with trying it, it is fine. if issyl0 wants to start on editing existing mallard pages, that would be an ok place to start, too. [13:38] issyl0: have you already written in mallard? [13:38] i ported over a few topics already... i just copied/pasted the plain text from help.ubuntu.com, and then converted them to mallard manually. [13:38] mdke: Not that I can remember, so no. [13:38] ah, perhaps it is too big a job then [13:40] better to read a few existing topics and make corrections for natty [13:40] OK, cool. Get to know it, then delve in with the other stuff at a later date. [13:40] issyl0: try getting the branch from launchpad, and we can walk through a few things... like how to view the help in yelp [13:40] some mallard basics, etc. [13:40] OK, will do - thanks. :-) [13:42] j1mc: fyi the latest branch now has the user-guide reinstated alongside gnome-help, for the reasons discussed on the mailing list. I don't propose we touch user-guide any further though [13:43] mdke: sounds good. thanks very much for your help with that. [13:44] np [13:44] we can remove it next release, assuming Ubuntu uses Gnome3 apps [13:45] yeah... it is interesting... differences between unity and gnome 3 will affect help even at the application level. [13:45] updates to empathy help, for example, will talk about chat windows appearing at the bottom of the screen, etc. [13:46] * mdke nods [13:46] frustrating, but really it's a bit odd to be using Gnome help where Ubuntu has departed so drastically from Gnome [13:46] Yes! [13:46] yeah [13:47] but for this release I think it's justified given that Gnome help was so far ahead of ours [13:47] and it is relatively easy to adapt topics where much of the structure, writing, linking, etc. already exists. [13:48] but i don't think we'll be following upstream closely in the future. [13:48] indeed [13:48] great shame [13:48] * issyl0 reads about Mallard - interesting - doesn't look too bad. :-) [13:50] issyl0: i hesitate to say that something is easy, but Mallard certainly has an easier learning curve than something like LaTeX. And once you see a few examples, hopefully you will be able to pick up on it. [13:51] LaTeX is lovely. :-) [13:51] for PDF output, there is certainly nothing better. [13:53] Right, branch obtained. [13:53] Finally. [13:53] * j1mc goes to look where we might need editing / porting help. [13:53] * issyl0 blames living in the countryside for the slow internet. [13:53] issyl0: cool. to view the help in yelp, navigate to the branch you just pulled [13:53] then do: yelp gnome-help/C/ [13:54] Ooh, nice. [13:55] the intro sections are still a WIP, but i would recommend checking out the other sections. [13:55] i'm looking to see if i can recommend an area to get started [13:56] i think, "user and system settings" would be a good place to start. [13:56] OK. [13:56] if you're in yelp, and you press Ctrl-l (that is an "L") you can see the name of the page that produces that document [13:58] Oh, yes. And then if I find any errors, I can edit that document, and then save it and view it in yelp again to check everything is fine before committing? [13:59] exactly [13:59] Cool. [13:59] when you launch yelp from the terminal, the terminal output will also give you warnings if there are errors in your document. [14:00] like, if you forget to close a tag, or use a tag that doesn't exist [14:00] Great. [14:00] we have had a few other contributors ... for now, we are having them submit patches for review. [14:01] is that ok w/you? you could either submit them by email, or you could propose merges on launchpad. [14:01] either is fine. patches by email should go to the mailing list, though. [14:01] Yep, I've noticed people submitting them to the mailing list. That's fine. [14:01] excellente. :) [14:01] thank you so much, issyl0 [14:03] it sounds like you are set up ok to get started... i will be on irc here for a bit. do you have any questions for now? [14:03] No, that's fine for now - thank you! [14:04] Actually, I do have one: what do you class as patches, i.e. how do I generate them? Is there a procedure, or do I just attach, say, a diff to the email? [14:06] you can use "bzr diff > patchname.diff" [14:06] Ah, cool, thanks. [14:07] yes. i think another way is to do: "bzr send -o mycode.patch" that will propose a merge request on launchpad. [15:12] j1mc, mdke: Just sent a small patch to the mailing list - hopefully it was decent and worthwhile for a first one. :-) [17:05] issyl0: cool. thanks! i will take a look [17:31] j1mc: Thanks for that. [18:12] issyl0: you are welcome. thanks again for the patch [18:14] No worries. I'm about to do another few, but will do it the way you suggested. [18:14] Will that mean I submit them all separately? [18:16] But no. I guess I just generate a .diff and then bzr send -o foo.diff ? [18:24] j1mc: ^ [18:26] Although, hrm, weird: bzr diff > foo.diff still diffs my previous stuff, the things that have already committed. Not that it knows that, even though I've pulled down the latest revisions. [18:27] All this is an experience, however. [18:41] issyl0: hmmm... weird, did you do bzr update? [18:41] sorry, i am a bit in-and-out of looking at IRC [18:41] j1mc: Yep, I did. [18:42] hm, frankly i know git a bit better than i know bzr. [18:42] Git is lovely. [18:42] maybe try bzr merge [18:43] As far as bzr goes, I definitely prefer just straight bzr commit / bzr push. But it's all a learning experience! [18:43] yeah... sorry, maybe ask in the #bzr channel [18:43] * j1mc lurves 'git pull --rebase' [18:45] what i typically do is "bzr bind lp:~path/to/branch" [18:46] i think that helps with doing 'bzr update' ... it processes the commit as a commit when the updates come through. [18:46] i need to step away for a bit, but . . . will be available via email. [18:46] thanks again for your help. [18:53] issyl0: howdy & welcome! [18:53] Hey! [18:55] bzr send -o patch.diff isn't working for me. Well, the .diff doesn't generate correctly based on *new* changes - it still records the old ones, even though I've pulled down those revisions that were committed... :-/ [18:55] It's weird. [18:56] you have to do bzr commit first [18:56] and you can do bzr status or bzr diff to see what it's about to commit [18:56] Oh, right. Of course - silly me! :D [18:56] Thanks. Should have realised that. [18:57] nah, bzr has a lot of buttons and it takes a while to figure out [18:57] * issyl0 is used to the bzr commit / bzr push cycle, not the bzr commit / bzr diff / whatever cycle - didn't occur to me! [18:57] Hah, buttons? THE COMMAND LINE. :-) [18:57] haha, same thing to me [18:58] But yes, cool: now I realise why: if you don't commit it, it doesn't know what to say about the changes when they're merged. :-) [19:04] So after I've committed, I do bzr diff > foo.diff and then bzr send -o foo.diff? That's logical. [19:05] jbicha: ^ [19:06] I've never used bzr send, I just attach the diff to my email manually [19:06] see, bzr has too many "buttons" [19:06] Hehe. [19:07] I've also been using bzr bundle to make a diff, not sure which is better for the reviewers [19:07] And OK. That's what I did this morning but was told to use bzr send later on - it's all a learning experience, delving into parts of bzr I've never delved into before. [19:07] OK. [19:08] and to make the merges easier on my end, I uncommit and revert after each patch I send, but once again I don't know if that's a good idea or not [19:09] Hrm. That sounds bizarre, but I can see why you do it - to avoid conflicts when you generate other diffs/commit more. Hrm. [19:10] that, and j1mc likes to "improve" my patches :-) so there's bound to be merge conflicts & I don't know how to resolve that very well otherwise [19:11] Mmhmmm. :-) [19:22] So I've just done bzr send -o patchone.diff - hopefully that'll work. [20:15] oops, that didn't work, my email patch was too big & is being held in the moderator queue [20:24] I guess I'll have to get @mdke to rescue it for me, lol [20:51] jbicha: Oops. [20:51] I was updating pictures so those files are big [21:36] issyl0: yes, you can do bzr push instead [21:36] to your private branch [21:37] I do bzr push lp:~jbicha/gnome-user-docs/name-of-my-branch [21:37] jbicha: Cool. I'll do that then. :-) [21:37] but j1mc already applied the patch you sent to the mailing list earlier anyway [21:40] Yep, I noticed. [21:45] jbicha: that really is a huge email, probably better not to allow it through to the mailing list. Can you do a merge request instead? [21:45] jbicha: just because we have a lot of people subscribed to the mailing list and that is quite a large download for som [21:51] jbicha: on your question above, one option is to push a new branch for every set of changes that you are working on. So you keep the main branch in your repository, and then just create a new branch off it for each task you are working on [21:51] then you can push that one to its own branch in Launchpad and do your merge request [21:55] I did wonder earlier, looking through the .po files, why there were files for, say, ES, but not for FR? [21:55] * issyl0 could help out with FR, if need be. [21:55] But I don't know how translations work for the GNOME stuff, admittedly. [21:55] issyl0: those are upstream translations of the Gnome 3 stuff; all the languages are at an early stage and I think FR hasn't yet got going perhaps [21:56] Ah, right. [21:56] after the release we will be calling for translation work on our amended material though, so you could well be able to help :) [21:56] it will be a big job [21:57] I'm up for trying! [21:57] * issyl0 lived in France for four years, to clarify... [21:57] very nice [21:58] what's your country now, UK? [22:00] Yep. [22:00] me too [22:01] Cool - anywhere interesting? [22:01] * issyl0 is quite near London. [22:02] nowhere interesting at the moment I'm afraid [22:02] Canada Water, south east london [22:02] right now I'm in Southern Italy though, a lot more interesting :) [22:03] mdke: can you approve my email in the ubuntu-doc moderation queue [22:03] jbicha: did you see my response to that above? [22:04] mdke: oh, no I didn't [22:04] have a look, if it's a problem I can approve it but I'd rather now [22:04] I don't understand how merging works, should I make a new branch for every small set of changes? [22:06] jbicha: you can do yes. It's very much a question of how you prefer to work though [22:06] jbicha: certainly for big changes it is worth doing so [22:06] mdke: Mm, Italy. [22:06] because I have like 5 different patches I've submitted to the mailing list, should I make one big changeset or stack them on top of each other in the same branch or just use different branches? [22:06] once the branch has been merged into the main one, you can discard it and move on to the next one [22:07] I want whatever's easiest for the guy reviewing them :-) [22:07] i would create a new branch for each set of changes that affect the same file or group of files with the same subject matter [22:08] i have to check out now, bed time [22:08] thanks both for your work so far, it's great to have some new faces [22:09] jbicha: if you haven't found another solution, just tell me and I'll approve the email in the morning [22:09] each is a different set of files [22:30] ah, there we go, giant merge request, we'll see how that goes tomorrow [22:31] and I'm out for the evening