[00:17] since i had the opportunity, went ahead and updated the icon/badge for https://launchpad.net/~ubuntu-doc - new one is this nice and crisp one: https://launchpadlibrarian.net/162165522/ubuntu-doc.png [00:18] old one for reference: https://launchpadlibrarian.net/1050489/images.jpg [00:18] that's much better ! [00:18] yep [00:20] Im doing a bit of RTFM on bzr branches .. lol [00:20] poke me if in doubt [00:21] basically, what you need to do if you want to make changes, is: [00:21] KI7MT: knome now I know my eye sight is no no longer 20:20.... but they are two really small icons? [00:22] 'bzr branch lp:branchname' (or 'bzr pull' if you have already branched) [00:22] then do your changes [00:22] 'bzr add .' [00:22] 'bzr push lp:branchname' [00:23] in the push, you'll want to push under lp:~lpnick/originalbranchname/my-fixes (replace my-fixes with something appropriate) [00:23] well, I don't want to have a repeat of the mistake I made today .. I have an MP pending, and I went on and worked another bug (form the same source tree), and tried to send that up with bzr bundle > test.file .. I've been told, I needed to pull another branch down and work it form there. [00:23] phillw, yep. [00:23] i don't know how bundle is supposed to work [00:23] you could've just updated your branch as if you were working with a normal/trunk/main branch [00:23] (that is, just push to the same location again) [00:24] Im not gonna use it again, just MP form no on. [00:24] *from now on [00:24] (in that case i think you'd need to do the merge proposal again) [00:24] merge proposals are good [00:24] I think for the setup we have, with only a few commiters, thats the best route [00:26] i don't know too much about ubuntu docs, but if you have some minor grammar edits only, i could be able to review and merge those [00:26] so, now all I should have to do is create a new dir for the new bull and work from there yes? like mkdir ./{r325,r326,r327} yes? then do a bran into each one for seperate MP's ? [00:27] i'm not sure i'm following on what you mean with the new directory [00:27] knome: and KI7MT please do go ahead!... My time is currently spent on a non-pae kernel for all to use :) [00:28] well I sent MP 326 today .. and want to work other bugs .. I can't work the bugs form the 326 source right ? [00:29] or at least until it's merged .. then I could I suppose. [00:29] KI7MT, you can; as i said, you can stack the changes on the same branch [00:31] This is why I was reading the docs, cuz today, I sent the MP, and then worked an LP bug from the same source, and them messed things up .. the guy in launchpad said I need a new branch as you can on have one pair at a time per branch. [00:33] or in other words, I can't have more than 1 MP pending form the same source tree. [00:33] *from [00:33] that's right [00:33] i don't know how other people want to review merge proposals... [00:33] but you could update your branch and just mention the new things in the same merge proposal [00:34] and it's correct: you can only have one merge proposal from one branch, nothing else would make sense [00:34] stacking changes to one branch is fine IMO, as long as they aren't huge changes [00:34] LP allows seeing useful diffs anyway [00:35] so your saying, work 3 or 4 bugs, all unrelated, and send that as MP [00:35] as long as it's not like rewriting have the book. [00:35] yes, i would say so [00:36] depends a bit *how* unrelated they are too [00:36] but as long as it feels possible that one person can review the changes... [00:37] if you're changing, say, server docs and xubuntu docs (isn't possible because they are in different branches, but let's play a mindgame), it would be highly likely there isn't anybody who can review both changes [00:37] well to be fare, most of the bugs are simple text edits, some require writing a new page, but form what I've seen, not many of those. [00:37] what Im doing right now is all in ubuntu-docs [00:37] but if you are changing two things that both only require basic knowledge of the ubuntu desktop... yes, please go ahead [00:38] ok [00:38] reviewing 3+ small requests and merging takes usually more time than reviewing one slightly bigger and merging that [00:38] just use common sense [00:38] and; do what you think is fair [00:39] if you think you have two bugs that are completely unrelated and are not sure if you can do one merge request; do two [00:39] That's why I was keeping the MP I just did all together, was all related to Online Accounts. [00:40] where the bug fix was something completely unrelated, so i was going to send that separately and that's where I got all jammed up. [00:40] that's fine [00:41] for that, you need a new branch [00:41] I'm not disk space limited, so I don't mind having multiple copies of the source tree to make things easier on the other end. [00:41] i guess you are saving some headache if you branch from the main branch again [00:41] both ways are possible though [00:42] I think its clean for those that have to review it. [00:42] yep [00:42] if you start to do a lot of merge reviews, you should at some point probably apply for -committers as well. [00:43] Maybe someday . I'd be happy just to get some things fixed for now, and learn as I go. [00:43] yep [00:43] do what scratches your itch :) [00:44] Indeed [00:47] So now I gotta pull 325 again, and do the patch for LP1222288 again :-), but form a new branch pull this time. .. All this was over a one line change in a file :-).. it's taken me all day to get it sorted :-) [00:48] that's how you learn things though [00:49] it's sounds nuts, but, yeah, I lean more from doing and well, re-doing .. lol.. [00:51] repetitio mater studiorum est [00:51] I spent allot of time on the bazaar site today >> User Guide >> Undoing Mistakes .. LOL [00:58] dsmythies, Got your email .. how to I update the MP, do I merely sent it again with the same name ? [01:07] * KI7MT goes to read about launchpad's merge process :-) [01:18] KI7MT: yes, I think so. It has been awhile since I had to send up a revsion myself, so I forget somewhat. [01:19] dsmythies, If you could, in the comments, add which files the comments are referring too .. Also, the built HTML look much better that yelp-build or raw .page files. [01:34] dsmythies, Oh I see, your reading the Diff's file, now your emails making more sense :-) [01:45] KI7MT: I was looking at and reading via the help system. Two windows open side by side, one with the unity help package as per 14.04 install and the other from the file browser to the proposed stuff and then I selected "open with" and then "help". [01:46] KI7MT: I don't actually know which file name I was looking at each time. [01:46] It's on the Diff's file on the MP [01:46] ... as I was navigating around. [01:47] KI7MT: "It's on the Diff's file on the MP" : I know, but I wasn't lookign there. [01:48] If you click on the MP .. I''ve never used 13.10 .. only 12.04 and now 14.04 [01:51] I had to open the diff's file because I couldn't follow where you were at, the diff file shows it pretty well. [01:52] dsmythies, How did you build the HTML, with make or yelp ? [01:53] KI7MT: I never ever deviate from the buidl wiki page. at the proper place on that page, I use "make". [01:54] KI7MT: I would have included screen shots with my MP notes, but it seems one can not put attachments into an MP. [01:54] Until later today, I could not make "make" work .. lol .. was using the wrong "make" of course :-) [01:55] dsmythies, No, you can't not without adding the images to bzr [01:56] How is this process normally handles with changes or adding a series of pages ?, [01:57] This MP is really small, the first one, that was allot. [01:59] KI7MT: Rev 324 has a file added. Have a look at it. Beyond that, I don't understand the question. [02:03] I just wondering about the whole review process, I'll figure it out over time. [02:12] dsmythies, looks like your the only one doing changes to server .. there all yours form 162 to 171 [03:22] KI7MT: Serverguide: No, the last 3 are from others. I am just the one that actually merged them. Some how Benjamin seems to know another way to do it such that the MP persons name stays. I do not know how to do it that way. I need to learn how Benjamin does it, and then makes changes to the serverguide documentation committers "how to" wiki. [03:24] dsmythies, And I found out we can bzr push updates to the MP .. Are you don't with comments on the merge ? [03:24] *are you done .. .. [04:35] KI7MT: I haven't looked at the html versions yet, nor had a chance to go back and look with the help system again. So, the answer is I don't know. [16:11] KI7MT: Just some notes... [16:13] KI7MT: if an MP is linked properly, then not need to add a note to bug report pointing to it. The branch will be linked automatically. (reference: bug 1222288 ) [16:13] Launchpad bug 1222288 in ubuntu-docs (Ubuntu) "addremove-install-synaptic.page minor fix" [Undecided,Fix committed] https://launchpad.net/bugs/1222288 [16:13] KI7MT: A bug report is not considered "Fix Committed" until the MP is accpeted and merged to the master code. [16:16] You referring to lp122288 ? [16:16] If so, I'll go fix it. [16:17] No need, I'm just saying for next time. [16:17] I changed it to in progress. [16:18] Also, I pushed an update to the merge proposal for accounts, fixed or explained the things you had quesitons on. [16:21] KI7MT: There is a potential bigger issue with the "online" changes. I am making screen shots of 3 help types: GNOME, Unity the way is was, Unity proposed, and will make an e-mail. The issue, we start to introduce deviation between look and feel of GNOME help Vs. Unity help. [16:22] KI7MT: I have not seen your updated MP yet. Oh... now I see the related e-mails. [16:23] There's lots of isses with that, we should Dash, not point and click in Unity .. at least for things that Dash can access ro launch. [16:23] should use Dash .. [16:27] Im really frustraighted with bzr .. it's just not working the way I need it too and it's still pulling in stuff I dont want it too, even with separate branches. [16:28] I think Im gonna stop using it to send changes, and jsut email them instead. I've spent more time Undoing issues realated to that than fixing things. [16:32] KI7MT: I get very frustrated with bzr also. I am NOT in favor of e-mailed changes, because it shifts the work onto someone else, and typically that someone is already overloaded. [16:32] KI7MT: I'll pull in your revised MP and start again with my screen shots. [16:33] I don like that either, shifting the workload, but there's no point is spending all day fixing something, then having to un-fix things it should have sent up. [16:33] *it should not have .. .. [16:34] The whole point of a distributed cvs is to lesson the workload, not increase it. [16:44] KI7MT: Oh crap... bzr reports a conflict when I pulled rev 328. [16:44] dsmythies, what's the conflict ? [16:46] dsmythies, I think I found the root cause of my issues though: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository says to init the repo, then pull branches, that relates everything in it. That doesn't work for doing single item merges proposals. [16:46] KI7MT: I don't know yet. (have you noticed how often I say "I don't know"?) it is in ubuntu-help/C/accounts.page. I'm just reviewing / remembering how to look into conflicts. [16:51] dsmythies, you should be able to see the conflicts with either bzr conflicts or bzr status [17:14] dsmythies, Any progress? [17:19] KI7MT: Yes, resolved. However, I did additionally change something. The problem now is I am out of time. I'll have to pick this up in a few hours. I'll add a note to the MP. [17:20] Ok [17:21] I dont really know what to work on now, if I should pull 325 and go work another bug or what. [17:22] I do know one thing, the bran is like 117M each time I pull it, thats allot .. [17:22] *branch === jono is now known as Guest51977 [19:42] KI7MT, branch one, then do copies *locally* of that "main" branch [19:42] KI7MT, saves the downloading each time [19:48] knome, GM .. ok, I ran into the same problem pushing an MP for a patch .. I'll try that method and see how it pans out. [19:49] knome, I think the root cause was, I followed the guide and created a shared local repo [19:51] what i'm proposing is [19:51] bzr branch lp:ubuntu-docs /repository/path/ubuntu-docs-base [19:51] then when you want to start working with a new bug, [19:52] cp -R /repository/path/ubuntu-docs-base /repository/path/ubuntu-docs-fix-for-bug-1234556 [19:52] and time and time, go to ubuntu-docs-base and run 'bzr pull' to update the 'base' repository [19:54] Yes, that's what I started setting up to work this morning. Doing the ubuntu-docs-dase branch now. [19:55] :) [19:55] Im not used to the Distributed + gatekeeper model at all :-) [20:06] knome, So now with that setup, when I do commits inside each clone of ubuntu-docs-base .. because it's not is a shared repo, those wont affect the other copies right? [20:06] that's correct [20:07] cool that's what I needed initially, cuze when I pushed an MP update this morning, it pulled a bug fix I did as well. [20:08] I think, but im not sure, that may have caused dsmythies to have the conflict when he pulled the updated MP [20:15] knome, Ok, got that part setup .. now if I want to bring a copy of ubuntu-docs to the level of an MP I can just pull that particular MP from within the copied directory ? [20:15] yes [20:15] Cool thanks. [20:15] or keep working with the already copied branch for that merge proposal, if you still have it locally. [20:16] yes, will do that going forward, but had to rebuild what I had for each at that time first. [20:17] I'll only keep those local copies until they get merged or rejected. At least this way I can keep going forward. [20:25] yep :) [20:27] I think we should probably update the Creating Repo section on the wiki, and propose that methodology for those that are new to bzr, as creating an shared local-repo sets up this problem from the start. [20:29] Although, the init-repo ubuntu-bzr is in the advanced section already, it's the section before that which could be made more clear I think. [20:33] can you link me to the wiki page you are referring to? [20:34] knome, https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository [20:35] knome, and whatever method we start out with, needs to gel with the submission: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Submitting [20:35] Using the cp -R method, would work wiht > bundle but ins a shared repo causes all sorts of issues. [20:35] mhm [20:38] With the master brash being in a Distributed + gatekeeper Model .. a shared local repo is a pit fall is you want to wokk multiple issues, and that's probably a bit more than a new help is ready to undertake. [20:38] *master branch [23:30] bkerensa: Are you around? [23:32] dsmythies, I figured out my root problem, can't have a shared repo, like in the repos section in the Docs Wiki .. [23:33] KI7MT: I saw your discussion with gnome from earlier. [23:33] I mean knome [23:34] :) [23:34] Yeah, so I now have the right setup. [23:37] bkerensa: (or anybody else that knows): You seem to have a method of executing a merge that: I was not aware of; Seems superior to how I do it. I noticed it last cycle also, and searched and searched and couldn't figure out how to do it... [23:38] dsmythies: How are you doing merges? [23:39] bkerensa: For example see https://code.launchpad.net/~ubuntu-core-doc/ubuntu-docs/trusty under recent revisions for revisions 325 and 324, where you did 325 and I did 324... [23:40] bkerensa: How I do it is detailed in: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation/Repository/Members-Serverguide [23:41] bkerensa: I am very curious as to your method, becuase I think it might be less labour. [23:41] godbyk: Hi. See link above. [23:42] 'bzr branch lp:serverguide' will get the branch in the serverguide directory [23:43] 'bzr branch lp:serverguide mp-10000' will get the serverguide branch to the mp-10000 directory [23:43] that's at least something you can do quicker [23:43] (no need to mkdir!) [23:44] dsmythies, does that answer your question at all? [23:45] dsmythies, and what's the thing you think is cluttered in the merge? [23:45] knome: No, but thanks. I knew that, but typically I need to specify a sub-directory becuase I have used the default name. [23:46] if you're more elaborate with the question, i might have an answer... [23:47] knome: Observe that the merge bkerensa did actually says that KI7MT did it. Observe that the merge I did says I did it, but it was actually an MP from someone else. [23:47] knome: I was wanting to learn the bkerensa way. [23:47] aha, right [23:48] no, i don't have the answer for that... [23:48] knome: I did give gunner credit in the comment line though. [23:49] knome: Thanks for chiming in. [23:49] dsmythies: I think I've managed to do that before, too, but don't recall how now. [23:49] (I've been using git much more lately, so I'm afraid I'd misremember any bzr-related stuff at the moment.) [23:50] dsmythies: Can you merge directly through Launchpad? [23:50] godbyk: if I learn how from bkerensa, then step 1 will to edit the wiki. Why? becuase I wouldn't remember after a few days. [23:50] dsmythies: you bzr branch the proposers branch [23:50] Then you cd to it [23:50] Bzr push lp:ubuntu-docs [23:50] And it will merge with their commit message [23:50] bzr commit --author "First Last " [23:50] And as them [23:51] aha, right, that's probably good as well ;) [23:51] * knome makes notes [23:51] bkerensa-mobile: Sneaky! :-) [23:51] * KI7MT takse nots too :-) [23:51] notes [23:51] launchpad doesn't suggest you to do that though [23:51] Anyways i must poof... Im travelling [23:51] but i guess launchpad is just launchpad [23:51] Launchpad is foobar [23:51] :) [23:52] bkerensa: Thanks very much. [23:52] So foobar that the kernal team uses Git [23:52] The Ubuntu Kernel Team [23:52] :) [23:52] Ttyl [23:52] so in review, bzr branch .. cd new branch .. bzr push lp:ubuntu-docs .. from within the new branch [23:53] Yep [23:53] Thanx [23:54] re: kernel gurus Mr. Torvalds had allot to do with the Git use choice .. seeing how it's his baby :-) [23:56] hmmm... might actually be slower than what I do now, since all 117 megabytes will have to be downloaded. I rarely have to do that anymore. I'll try it though. [23:56] But, it's a true distributed version control system :-) [23:57] about git. Yes I use it also for kernels from kernel.org. I am not very proficient though. [23:57] I was going to ask about that, why do we need such a long history for each new release ? 117m is allot. [23:58] KI7MT: I'd like to know the answer to that as well. [23:58] KI7MT: try downloading the help.ubuntu.com branch. It is enormous. (so actually, don't try.) [23:58] When I created the trusty branch, I branched it from saucy so it kept that history. [23:58] I did that because past branches were created the same way. [23:59] Why we don't start a fresh repository each cycle, I don't know. [23:59] that is all I know how to do also. [23:59] (For the manual project, I do start a fresh repository each cycle so we don't have to download as much data each time.)