[00:05] knome: Also, would you be fine with "Common Tasks", rather than "How to..."? [00:07] mmmmmh. [00:07] maybe. [00:07] the current title isn't meant to be final [00:09] Yeah, just looks and feels weird. [00:17] knome: "Bazaar is a version control system and is commonly referred to as Bzr." - what should I use for "Bzr" there? I see that flocculant uses '' for the QA docs, but that also makes the text bold. [00:18] hmm. [00:18] ? [00:18] makes it bold too, but meh [00:18] Also, was that a "Yes, meh, go ahead."? :P [00:19] i would probably put this inside a [00:19] i think Isn't that a bit too much? [00:19] nah, it's fine [00:19] it's not a section you are likely to read over and over again [00:19] at least from the beginning to the end [00:20] Alright, I'll do as you suggested then. [00:21] Just to be clear, that's on the top just under the "Bazaar" header. [00:21] yep [00:21] also, what about calling the howto section "Reference" ? [00:21] Hmm. [00:22] Well, I can just leave that to you for later. :P [00:25] Seriously though, I guess that'd be still be than "How to". :D [00:25] - be [00:26] "Common Reference" at least? [00:26] wfm [00:27] Alright. [01:16] knome: Fine if I rename "processes-release-cycle.xml" to just "release-cycle.xml", consistent to its title and HTML file name? [01:20] the filename is referring to a potential structure for the docs, so let's keep it as it is for now [01:20] Alright. [01:20] * krytarik reverts [01:21] time to go to bed [01:21] thanks for all the work :) [01:22] Well. :D [01:22] And night. [01:22] ttyl -> [01:36] And if no one wants to beat me to it, I might include command line instructions for the MP part. === mhall119 is now known as mhall119|fossetc [05:53] (Done.) [06:01] flocculant: This is just for again now, updated: http://paste.openstack.org/show/E3wgCHbwYFoQRZcJrpKf/ [07:38] krytarik - "tell me if you're fine with the some additional changes" can't tell the difference between green, darker green, pink, darker pink, if something changed, what changed on that pastebin thing - so no. [08:26] really can't see what's going on with the light green/pink stuff :( [08:31] I find MPs a whole lot easier to read :) [12:27] flocculant, actually, i find the pastebin better to read than the MPs in most of the places [12:27] flocculant, glossary: [12:27] flocculant, light pink -> line that has been changed or removed [12:28] flocculant, light green -> line that has been changed (the new version) or added [12:28] these are basically the pink/green colors of MP [12:28] flocculant, the dark pink/green areas highlight the spot in the line(s) that has been changed [12:28] flocculant, so you don't exactly have to review the whole line [12:49] krytarik - mmm actually what's "bzr commit --fixes" about and why the need to change that? Given that none of anything else I've read requires that [12:49] knome: but what about lines where there's no dark pink/green [12:49] flocculant, context, like in the MP [12:49] anyway - whatever - when there's actually an MP for it - I'll look then properly [12:51] knome: this is what's confusing me then - because there are at least 2 cases where there are changes and no dark green/red [12:51] yeah :) [12:51] anyway - whatever - when there's actually an MP for it - I'll look then properly :) [12:51] yep [12:51] until I see that I'm not approving anything from my side [12:52] lol [12:59] obviously I don't care about the yeah [13:01] too care about that I'd need an explanation of something that I don't care to know about :p [15:47] flocculant: "this is what's confusing me then - because there are a [15:47] t least 2 cases where there are changes and no dark green/red" - yeah, those are the annoying cases where it doesn't figure out what really changed, for some reason. :P [15:47] Bleh. [15:51] Also, the '--fixes' option for commits should set the referred bug report status to 'Fix Committed' automatically, while for the MP it just links it to the bug report - as mentioned in both text parts. [15:56] flocculant: And of course, I didn't do any *factual* changes, only DocBook syntax, link anchor texts as mentioned before, consistency, wording, and typos. [16:01] krytarik, did you push the MP yet? [16:02] Well, the bug status is only changed when the concerning commit is merged into the main branch, of course - and for no packages it should be set to 'Fix Released' then immediately. [16:03] slickymasterWork: Nope, just started the day. :P [16:03] good life :P [16:03] Well, 3 hours ago, but... :D [16:05] Also, just doing some minor improvements on my yesterday's changes/additions. [16:06] drop a link after you made them, please [16:07] Also, I have no particular idea yet how to include all the recent stuff in the commit message, or changelog even. :P [16:07] slickymasterWork: Nope, I'm never dropping a link to you! :D [16:07] whatever [16:07] * krytarik pats slickymasterWork [16:08] :P [17:14] krytarik: ok - so with --fixes definitely don't want to use that [17:14] flocculant: Umm, I don't get it. [17:14] "And of course, I didn't do any *factual* changes," yes you did ^^ [17:14] Where? [17:15] please leave that bzr line as I had it - thanks [17:15] *Changes*. [17:15] ^^ [17:15] other than that - the rest is fine with me once I'd fought my way through the pink and green :) [17:16] Heh, alright. [17:18] flocculant: So, you aren't fixing the bug you just reported with the changes you are doing? [17:18] krytarik: there is a reason - pretty much pointless marking it Commited - nothing really happens to anything until someone physically edits the tracker side - at that point it's immediately fix released [17:19] Alright - so for you, it's just not 'needed'. [17:19] so all that marking them committed does is annoy me with pointless LP messages as I'm subscribed to it - as it's more or less me dealing with it [17:19] krytarik: not interested in a discussion on it - please lose that change in my qa docs ;) [17:22] but thanks for all the other bits and bobs - helps the readability :) [17:22] \o/ [17:23] ha ha [17:23] it's always useful for someone else to read things - you never 'read' what you wrote, you 'read' what you think you wrote :) [17:24] krytarik: and ftr - nice to know about --fixes, just doesn't really do much more than spam mailboxes in this particular thing [17:24] Well, you can read it, but extra work. :P [17:25] So, I have 'bzr commit -m "Fix LP bug #BUGNO."' now - fine? [17:26] no idea - if that's what it said before then yep :) [17:28] Well, it says 'bzr commit -m "Change re bug#' right now. [17:28] ok - happy with that newer wording :) [17:29] \o/ again. [17:29] it was the " those are the annoying cases where it doesn't figure out what really changed" which completely threw me :) [17:30] Yeah, like I said, it's annoying. :D [17:30] yep [17:30] I might try and use a plain one the next time then. :P [17:30] hah [17:31] well others like it that way - so don't change on my behalf ;) [17:31] I found that if I pretended to reply it sorted those things out [17:34] Yeah, it kind of worked. :D [17:37] Added the '--fixes' part to the Common Reference now instead. [17:39] ok - that's probably useful stuff [18:30] ochosi: jenkins is getting closer for the image tests [18:47] flocculant: And sorry, I was more thinking there of how I'm mentioning the '--fixes' option in the MP part of the Common Reference - that was a factual change indeed. [18:48] krytarik: yea understand that - but Common Reference isn't something I'm too bothered about :) [18:48] You mean not? :D [18:49] Oh wait, no. :P [18:49] no - I mean what I said :D [18:49] :) [18:49] the QA pages isn't something I'm not too bothered about :D [18:50] Hence I didn't think of having changed the command there, that is. [18:50] :) [18:50] hahaha [18:52] flocculant: Noticed what I did with the 's there though? [18:52] ish [18:53] no - not really [18:53] if I was to be more honest :p [18:54] That is, rather than enclosing lists and such, just end it where the current paragraph ends. [18:54] yea sort of noticed [18:55] but as I'm unlikely to be doing much more didn't do more than *shrug* don't know why that is :) [18:56] It was fine on the other two pages though. [19:40] is there any known problem with the lock screen on Xubuntu Trusty? keeps tellng me "This session is locked, youll be redirected bla bla" on my Trusty VM after I unlock the session [20:52] sidi, you should know better that this is no support channel [21:56] ochosi: so is this a gtk3 fail? http://i.imgur.com/1KLCHmU.png [21:57] guessing so - got some updates for it today [21:58] Go to GTK3 they said, it'll be better they said... [21:58] :) [21:59] I'd report it if I knew which one out of thousands to report it against ... [22:00] calc is awesome :p http://i.imgur.com/guBwH2V.png [22:01] flocculant: How about 'gtk+3.0'? [22:02] Unless, the theme... [22:03] http://i.imgur.com/eWl3d8R.png [22:03] calc in numix [22:04] adwaita it's the same as greybird [22:05] krytarik: can't ubuntu-bug gtk3.0 [22:06] flocculant: With the plus even? [22:06] nope [22:08] knome: if you have some time this afternoon, I'm around [22:10] pleia2, "afternoon"? [22:10] :) [22:12] knome: well, whatever time it is right now :) [22:13] just past midnight [22:13] but i'm here [22:13] what are we supposed to talk about? [22:13] lol [22:14] wait, i'll untangle my headphones first [22:14] ok [22:15] so, i guess the first thing is getting the contributor docs live/online [22:15] ok [22:15] they are in the docs branch [22:15] we don't have a completely workflow yet for that [22:15] * pleia2 updates local copy [22:15] +ready [22:15] but krytarik is working on some last fixes for some of the issues [22:16] one question i have [22:16] as they are in the same branch/package as the regular docs, they are "release-specific" - even if they aren't [22:16] which branch? [22:16] lp:xubuntu-docs [22:16] i mean, not like wily/ [22:16] ^ that's xenial [22:16] so the newest [22:17] k [22:17] the wily branch has outdated stuff already [22:17] one of the cons of having them in the same branch [22:17] yeah [22:17] otoh, this way we can share the build stuff [22:17] and stylesheets [22:17] and everything docbook [22:17] * pleia2 nods [22:17] and only have to maintain one set of that [22:17] so, the question: [22:18] do we want to set up the online docs startpage so that we have a link, that we manually update, that points to the newest contributor docs? [22:19] different from the index of docs.x.o itself? [22:19] or - my preferred option - do we set up the Makefiles so that you can build the newest contributor docs directly in a subdirectory [22:19] no, that thing [22:19] my vision is that the contributor docs would be at http://docs.xubuntu.org/contributors/ [22:19] but obviously feel free to disagree [22:19] maybe if we have more stuff coming for developers, we could consider another location too [22:19] so, speaking to my own process, whenever I build docs I do it locally (build tools are local, not on the webserver) and then upload what I need [22:20] ok [22:20] so as long as I have instructions about how to build and what to upload, I don't really mind where we put things [22:20] well, actually [22:20] one option is this: [22:20] set up another subdomain, like contributors.xubuntu.org (or whatever), host it on the same server as the tracker [22:20] then the maintaining burden can be shared [22:21] I think docs.x.o makes more sense [22:21] yeah [22:21] in that case, on the building quickly: [22:21] "make" [22:21] :) [22:21] then see build/contributor-docs [22:22] so, just what I do for the regular docs [22:22] that's currently skewed - we need the stuff from krytarik before we are ready to "just do it" [22:22] basically so [22:22] the main change we are making is that both of the docs have the same depth [22:22] right [22:22] so that ../../libs-common is always the same place [22:23] this helps us build the contributor docs in the shipped package too [22:23] but that's kind of minutiae [22:23] once krytarik has done the merge proposal, and the stuff is merged, we'd like an initial push ASAP [22:23] so we can start ripping the wiki stuff down [22:24] and make the website more user-oriented again (and just link to this documentation) [22:24] I'm home through Tuesday of next week (fly out for the holiday on Wednesday), back on Nov 30 [22:25] we should have it up by then [22:25] that is, tuesday [22:25] ok, just lmk and I'll make time :) [22:25] related: https://wiki.ubuntu.com/Xubuntu/DeveloperDocumentation [22:25] basically, i'm trying to make most of the wiki useless :P [22:25] not all, but most of it [22:26] i've even ACK'd moving the strategy document there by simon [22:26] reminds me, https://wiki.ubuntu.com/Artwork/Official#Xubuntu [22:26] then we can have history and sensible diff's [22:26] link should be updated [22:26] i'll do that [22:26] thanks [22:26] so, anything else on this subject? [22:27] DD wiki page lgtm [22:27] I think that's it [22:27] great, we'll poke you when we need an upload [22:27] perfect [22:27] so the other thing is basically "plan/set up blueprints for community/marketing/website" [22:28] and i guess we could talk about that sticker giveaway idea for twitter [22:28] and get it done [22:28] * pleia2 nods [22:28] and with that, other potential social media campaigns [22:29] could be nice to do one giveaway for every biggish outlet [22:29] outlet, social media platform? [22:29] yeah [22:29] shorter [22:29] <- lazy [22:29] hehe [22:29] yeah, would be nice to do stuff for the lts [22:29] maybe G+, twitter, fb [22:30] so the question is: [22:30] right [22:30] what do we do with the xubuntu memories or whatever we ask [22:30] or #loveXubuntu [22:30] it could be with that [22:30] I'm inclined to collect our favorites in a series of blog posts [22:31] yes, something like that [22:31] I'd also like to collect a bunch of favorites, and then do a random drawing of which gets a prize [22:31] but we need an approval from the participants [22:31] to share? [22:31] well at least from those who "win" [22:31] * pleia2 nods [22:31] yeah [22:31] i'd think it would be fair [22:32] also, [22:32] if we do this, just collect any ones that we might want to use [22:32] we can just request that they write "CC BY-SA" on whatever they submit [22:32] and ask for permission to use in "any marketing for xubuntu" [22:32] so we can use them later [22:32] otherwise it's not eligible [22:32] without the need to ask/collect again [22:32] i'm thinking flyers too [22:32] yeah, that's why a license is nice [22:32] yes, wfm [22:33] so, should this be a blog article after all? [22:33] which bit? :) [22:33] the "competition" info [22:33] tell what we do, ask for the CC bit, etc. [22:33] yeah, probably [22:33] we should probably also mention which platforms we are looking at [22:34] and if we take submissions via email [22:34] (and in which list/address) [22:34] my inclination is to ignore facebook because it's so closed [22:34] you can view tweets and g+ things without logging in, not so with facebook [22:34] yeah... [22:34] http://pad.ubuntu.com/lovexubuntu [22:34] let's try to get something there [22:35] ok [22:35] hee, look at all that content so far [22:35] well... i just created it [22:35] we have some old pad with some content [22:35] yeah, I thought we did [22:35] i'll try to find that next [22:35] I have it, sec [22:36] * pleia2 lies [22:37] i have it [22:37] http://pad.ubuntu.com/Nl1LbS6DqL [22:37] i'm copying that over [22:37] sec [22:37] great name [22:37] :D [22:37] done [22:37] thanks [22:37] yes, isn't it [22:38] ok, I need to reprocess this, I'll work to add notes over the next few days [22:38] but lets add doing this to our blueprint [22:38] * pleia2 pulls up [22:39] yeah, i'm quickly trying to add the things we just talked about so there's something to build on [22:40] yeah... [22:40] now, talking about BP's [22:41] is there something else we want to set up for 16.04? [22:42] flyer, lovexubuntu and continuing "xubuntu at" may be enough [22:42] kind of related, how do *you* feel about a wallpaper contest? [22:43] oh, we should do one [22:43] ok [22:43] i should write mail about it [22:43] we learned some things from last time [22:43] but laaazyyy [22:43] should recommend resolution, license [22:43] we remembered license [22:43] but people... [22:43] we collected on a wiki page last time, right? [22:43] yes [22:43] that was kind of awful [22:43] ubuntu uses flickr [22:44] and we kind of recommended resolution too, at least we had a minimum [22:44] but people.. [22:44] heh, right [22:44] bluesabre said he'd look at creating a tool for us [22:44] even better :) [22:44] so, since you are our legal expert [22:45] that's a frightening statement [22:45] :) [22:46] if a form says with BIG RED letters [22:46] that's purple [22:46] whatever [22:46] hehe [22:46] that if you submit, you submit with a certain license [22:46] is that good enough? [22:46] I radio button would be better, even if it's default selected what we want [22:47] because surely bluesabre can make the tool autocheck the resolution [22:47] radio button with what alternatives? [22:48] or maybe just a checkbox saying they agree to our TOS [22:48] yeah [22:48] which is... agreeing to the license [22:48] hehe [22:48] and no titties [22:48] :| [22:48] agree to license, abide by CoC [22:48] yes [22:48] whatever terms we had the last time [22:48] we can work on the language for that [22:48] yeah [22:48] sounds good [22:49] do we want to work with this: [22:49] [xubuntu-website] Community fund funded hosting for the development area: TODO [22:49] that just made my brain explode [22:49] sorry :( [22:49] what's the development area? [22:50] currently, the tracker [22:50] and i would like to set up a wiki too... [22:50] ah yes, I hate wiki [22:50] hehe [22:50] (hosting them) [22:50] heh [22:51] doku isn't so bad if you need smaller. [22:51] yeah, i was trying to remember the name [22:51] upgrade management, spam/user authentication handling, it sucks [22:51] i would most likely go with dokuwiki, it's relatively easy to maintain [22:51] Sean and I both use it. [22:51] and i've used it [22:52] we could probably look at having multiple admins for the server [22:52] virtual, likely [22:52] definitely [22:52] so it wouldn't be that bad [22:52] bluesabre already needs to handle dokuwiki updates [22:52] and Unit193 already pokes him about them [22:52] soooo... [22:52] oh [22:52] is there another update? [22:52] :o [22:52] i don't know [22:53] :D [22:53] we're talking about setting one for xubuntu [22:53] gotcha [22:53] dokuwiki is nice [22:53] i'm also familiar enough with the theming so i could probably set up a sensible xubuntu-specific theme relatively quickly [22:53] No update notification, phew [22:54] but i don't want to push people to do things they don't want [22:54] so if it isn't realistic to have time/motivation for that, then we just postpone [22:54] or rethink stuff [22:54] the ubuntu wiki has been horrible lately :( [22:54] bluesabre: No you're good. [22:55] previously it has been just everybody else that has had problems with it [22:55] now i've been in problems too [22:55] brb [22:56] anyway, that action item sounds fine, I'm ok with being lead sysadmin on such a server as long as I have help with the service specific things [22:57] totally [22:57] and ideally, we'd move docs. and static. there too [22:58] so you would have less work in keeping them updated [22:58] ++ [22:58] having me not the only one with access would be great [22:58] (and it would all be smoother, the doc team could poke whichever admin is available) [22:58] and with a virtual server, we can probably dump some scripts server side [22:59] * knome hides from pleia2 and the rolling pin [22:59] well, we could install all the doc build tools, as long as they'll work on the lts [22:59] they should [22:59] and will, really [23:00] i can preliminary volunteer on taking care of some of the social side [23:00] https://www.linode.com/pricing is my recommendation [23:00] probably the 2G one if we're running a wiki [23:00]