[00:50] who do we talk to about wiki spam? [08:09] LaserJock: you get the account disabled in #launchpad [08:10] spammers? [08:11] Madpilot: right [08:12] fun [12:05] Hi all, I've just created a patch for bug 185892 , but since I still consider myself a newcomer, could someone please comment on it? :) [12:05] Launchpad bug 185892 in ubuntu-docs "instructions how to paste commands incorrect" [Undecided,Confirmed] https://launchpad.net/bugs/185892 === jono is now known as severedfifth === severedfifth is now known as jono [20:41] evening all [20:42] hi mdke [21:04] old school documentors reunite! [21:05] * LaserJock ^5s nixternal [21:05] wasabi LaserJock and mdke!?! [21:05] ouch, think I trhew out my shoulder [21:05] haha [21:05] bum [21:05] * LaserJock runs for the Bengay [21:06] come on, icey hot is way better [21:13] afternoon all [21:18] jjesse: wow, you must have offended nixternal :-) [21:19] LaserJock: i thought it was you [21:19] oh, that could be [21:19] must've been the Bengay vs Icey Hot comment :-) [21:52] whoops, sorry. Hi LaserJock, nixternal [21:52] hi jjesse too [21:52] hello mdke [21:52] mdke: so lifeless suggested starting from scratch for Intrepid? [21:53] yes [21:53] I've created the branches now, and pushed them to launchpad [21:53] it takes like 2 minutes to get one from scratch [21:53] :) [21:55] nice! [21:55] and they are the newer format? [21:56] LaserJock: yes [21:57] LaserJock: which means you can't download them into a shared repo with the old format... but I'm hoping to upgrade all the branches shortly [21:57] i branched my own intrepid last night :) [21:58] jjesse: from the launchpad one? [21:58] mdke: yeah did a bzr branch to get it locally and then i'll push to the shared branch [22:00] cool [22:00] everything work ok? [22:00] mdke: the old branche could go into a shared repo anyway, from what I understnd [22:00] mdke: yeah they did [22:00] it was super quick i didn't know what to do ;) [22:00] LaserJock: the non-intrepid branches are all the same format, so they can go into a shared repo with that format [22:01] LaserJock: the new one is a different format, so it can only go into shared repos with the new format [22:01] mdke: but I was told that their format wasn't supported by shared repos [22:01] LaserJock: which format? [22:01] old or new? [22:01] bah, I can't remember it exactly [22:01] old [22:01] dir-state-something [22:02] sure they can. I've had one since we started using bzr [22:02] huh [22:02] ok, #bzr told me I had to convert them before I could use them in a shared repo [22:02] maybe you mean that Launchpad doesn't support shared repos on the server-side? [22:02] no [22:02] well, that is definitely wrong :) [22:03] ok then [22:03] no biggie, other than I spent like 1.5hrs converting branches the other day to get a shared repo :/ [22:04] LaserJock: the shared repo instructions have been on our wiki page since we started [22:04] but anyway, there is value in converting your branches :) [22:05] you get the new format [22:05] yeah [22:05] so you upgraded with bzr upgrade? [22:05] well, I haven't used bzr much with the doc team [22:06] unfortunately edubuntu-docs is ... slow going [22:06] no [22:06] what I did was create a shared repo [22:06] then I branched my local branch into it [22:06] which did the conversion [22:06] ah, that's what I did too [22:07] I've been a bit worried about trying the upgrade on our lp branches, in case something breaks [22:07] it seems from hanging out in #bzr that upgrading formats should be pretty safe [22:08] but to be honest, I don't like how bzr keeps changing [22:08] it makes me feel like git is safer and more friendly :-) [22:08] it's a bit odd, yeah [22:09] it seems like I'm always in a "corner case" or something [22:10] what really has been a pita for us has been the bzr-svn import [22:10] because bzr-svn forces you to use a non-default format [22:10] due to something to do with how svn works, dunno what [22:10] yep [22:10] I wish they would have done a bit more work with us on that [22:11] I don't think there is a way around it [22:11] well, converting it to a good format would have helped [22:12] the new format didn't exist at the time [22:12] ours *was* the good format, I think [22:12] but there was a standard "old" for mat [22:12] well, #bzr told me that it was an experimental format [22:13] right, which couldn't be used because we used bzr-svn to import the repo [22:13] sure [22:13] but we could have had it converted [22:13] apparently not [22:13] from the bzr-svn import format to a standard knit format [22:13] you can't convert in that direction, apparently [22:13] well [22:14] to me that's why this stuff is less than ideal [22:14] but oh well, that's water under the bridge [22:15] with fresh branches we could do this "student branchs" thing [22:15] without it being a big ordeal [22:16] well, I still have the same concerns about that [22:16] single branches, sure, but a team branch, little bit more cautious [22:16] sure sure [22:16] that's what I meant [22:16] if a student undertakes a biggish project, a separate branch would work [22:16] I just couldn't imagine students pushing these hug branches around for a patch [22:16] *huge [22:17] * mdke nods [22:17] a patch is much easier [22:18] I still don't get the distributed VCS stuff, tbh [22:18] I like being able to work offline [22:18] but it still seems like sending a patch to a list is the way to go [22:18] as opposed to merging branches all the time [22:19] I think for bigger things, I can see how it would work [22:19] but for small things, no [22:21] mdke: oh dude, while you are here :-) [22:21] mdke: I would like to have the LTSP information that was in the Edubuntu Handbook transferred to ubuntu-intrepid [22:22] I'm not so sure it would fit in very well with TBH [22:23] we could trying to make it suitable or we could do a LTSP Guide [22:23] do you have an opinion? [22:23] LaserJock: I don't think the average desktop user will use that material, so I wonder if it wouldn't work better as a separate package? [22:24] I was gonna say we could put it in the Server Guide [22:24] but that's not right either [22:24] LaserJock: or move it to the wiki, it really depends on when it is used [22:24] well, we will probably have a online version on edubuntu.org [22:24] what's wrong with it in edubuntu? [22:24] it's not in Edubuntu anymore [22:25] LTSP is a part of Ubuntu [22:25] so it would be more logical to have it in Ubuntu [22:26] ah, I'm a bit hampered by not knowing what LTSP is [22:26] I guess a separate packages might work, though I'd probably want to build it out of ubuntu-docs rather than edubuntu-docs [22:26] I thought edubuntu was built on it [22:26] it is [22:26] but Edubuntu is now an addon CD [22:26] LTSP is server stuff [22:26] that is now in the Ubuntu Alternate CD [22:27] so that's why it's all confusing [22:27] it's mostly used by Edubuntu users at this point, but it's not edubuntu-specific [22:28] I guess we could ditch it altogether :/ [22:28] it's been an almost 2 year project though, I hate to just get rid of it [22:29] * mdke head swims [22:29] sorry [22:29] let's keep it around and decide what to do with it [22:29] but I don't think I can help much with that decision ;) [22:30] * mdke is busy smashing up the ubuntu-intrepid layout [22:30] well, I just wonder if you'd be opposed to having another "Guide" in ubuntu-docs [22:30] LaserJock: no, not in principle, at all [22:30] k [22:31] mdke: do you want me to smash edubuntu-docs after you're done? [22:31] it's quite fun... [22:31] but I won't be done fixing it for a while :) [22:32] I wondered if we could use prefixes for stuff in the common areas that are derivative-specfic [22:32] you mean derivative specific individual files? [22:33] yep [22:33] they should definitely have unique names [22:34] the only thing I might have a conflict with is maybe gnome-menus-C.ent from libs/ [22:35] but isn't it good to be able to merge the bits you want and keep the bits you don't separate? [22:35] actually nope [22:35] I have edubuntu-menus-C.ent [22:35] how do you mean exactly? [22:35] I don't plan on doing any merging [22:36] let me think about this [22:37] I just don't see how this would work other than having all the contents of the derivatives in ubuntu-* [22:37] these are divergent branches I think [22:38] yay, revision 2 pushed up [22:38] so a merge would cause me to get anything else that had changed in ubuntu-* [22:38] I don't follow [22:39] how would I merge changes to libs/ into edubuntu- [22:39] I would have to merge each individual revision [22:39] and they would have to not touch anything but libs/ [22:40] otherwise I'm going to get all the other stuff and the merge will fail [22:41] can't you merge from a specific location? [22:41] no [22:41] only a branch [22:41] really? [22:41] yep [22:41] i thought you could merge a specific file, I'm sure I've done that before [22:41] well hmm [22:42] well, you should be able to! [22:42] we will demand that it be implemented :) [22:42] I swear #bzr told me you couldn't but they eventually wanted to be able to do that [22:42] but now that I think about it, that seems a bit nuts [22:42] ah [22:42] let's try [22:43] man that sucks [22:44] didn't work? [22:44] does it tell you they are divergent branches? [22:44] "no common ancestor" [22:45] right [22:45] anyway, you can do it on the revision number [22:45] so like I said, we'd need to make sure that we only touch libs/ when we are making a change [22:46] and the derivates will need to do each revision individually [22:46] yes, but small commits are good anyway [22:46] wich isn't horrible, but not exactly trivial either [22:49] yes [22:49] but in the future... [22:49] we can try nesting a common branch in each of our derivative branches [22:49] and just updating that [22:49] the benefit of having this format [22:50] yeah [22:50] this way isn't too bad as long as everybody know about it [22:50] libs/ change rarely [22:52] yeah [22:52] ok, time for bed [22:53] nice to chat! cya [22:53] mdke: cya