[08:15] Ovenwerks, zequence: Is the new wallpaper in? [09:13] smartboyhw: Don't worry about it. If we don't add it, we just dont. [09:14] zequence, OK. [11:14] OvenWerks: Just updated ubuntustudio-menu with new icons [11:15] micahg: Do you have time? We'd very much like to get lp:ubuntustudio-menu uploaded if possible :) [13:33] zequence: did you also need to update the debian/copyright file? Your name is not in there for icons. [13:35] It may be ok to leave Mish as the CR holder too. [13:37] OvenWerks: Yeah, I don't care about the copyright. It's enough his name is in htere [13:37] I just changed coloring pretty much. Some minor details [13:40] Continuing reorganizing our projects and blueprints. Things will be quite different from now on [14:00] OvenWerks: Get yourself an account on github.com, if you haven't already [14:01] OvenWerks: Let me know your username once you're done [14:01] OvenWerks: Another insurance, in case I get hit by a bus [14:01] I should just make a list of things first.. [14:02] zequence: remind me tomorrow or email. today is busy as I have a gig after work. [14:05] OvenWerks: Sure. I need to do this properly later anyway. Might as well send you a complete list instead [14:26] Hi all : ) [14:28] hello madeinkobaia [14:28] Hi cub. [14:29] keeping busy? ;) [14:29] cub: Yep :) [14:31] cub: Do you know the required size (or ratio) for our default wallpaper ? [14:36] cub: Now maybe we don't have clear specifications about that. In that case I will make a 2560x1600 and a 1920x1080... [14:39] ...or maybe I could make a complete set-up with all ratio sizes (like that no problems of cropped picture). That brings another question : do we have any file size limits for our wallpaper package ? [14:47] hmm I saw a guideline for that somewhere [14:48] I even got a gimp template to try them out in different ratios and set up. But I can't find the link .. [14:48] cub: no worries, take a look on that if you have the time. [14:49] well I should have the link somewhere, it's just a matter of finding out how i categorised it when I saved it. :D [14:49] :D [14:54] nope can't find it. I might be xfce specifications though since it was when I was planning to do a xfce theme. All wallpaper I did then was according to the guideline I read and they are 2560x1600, so I'd go with that. [14:58] cub: Ok, lets go for the 2560x1600 ! About the xfce theme, did you planned to use a specific tool for create it, like a widget factory ? [14:59] I never got that far. I started out with wallpaper, then to set window colouring, then I started to put in time in this group instead. :P [14:59] I want a Solarized theme on my computers and there is none for xfce. [15:00] Maybe next summer! [15:00] ;) [15:01] So, when the WP is set we might set a look for the youtube vidoes? [15:04] For sure cub. No problems. In that way I would like to have all graphics specifications for that, mainly the required dimensions. I insist on that because Gimp don't allow to have a different size for export. So the native working size must be the export size. [15:06] Or...the opposite ;-) [15:06] yeah, it's in the PDF I sent you, umm some weeks ago. But 1280x720 it is. To conform with the 720p quality on youtube. [15:06] zequence also started up https://wiki.ubuntu.com/UbuntuStudio/YoutubeVideoFormat [15:06] Really ? Goin to see that... [15:07] Ok, I got all the info I need : ) [15:07] did you find the email? Otherwise I can just forward it [15:08] I sent it to your gmail-address though. [15:08] oh crap, I'm late. :D gotta run [15:09] :D See ya ! [15:17] madeinkobaia: 1600x1200 is what we have been using lately [15:18] zequence: Hi Kaj, hum this ratio is really outdated now (check out on the web). [15:18] madeinkobaia: Which one do you propose? [15:19] zequence: The most usual now is a 16:10 ratio (size from 1440x900 to 2560x1600). [15:19] madeinkobaia: Ah, right. I meant 2560x1600 [15:20] zequence: Ok ;p [15:20] madeinkobaia: Did you make new versions of your wallpaper? [15:22] zequence: I tried few stuffs but the first I showed on the list stay the best one. I will test tomorrow morning a version including your suggestion to add a little colored part. [15:23] madeinkobaia: Ok. Tomorrow we really need to get it in, so we can get the package uploaded [15:27] zequence: No problems, you will have a 2560x1600 with .png (for a better quality) tomorrow. About the color : a blue touch could be certainly good. Now my first idea was to make a monochrome one for please to "everybody". [15:29] madeinkobaia: Blue always works :). There are so many shades of it too.. [15:29] Maybe better to try something else for 14.04 though :P [15:32] zequence: As I planned to do it, all will be anyway new for the 14.04. A complete and coherent brand new graphical design...a revolution :D [15:36] madeinkobaia: Many things will change for 14.04 :D [15:37] zequence: Now, we need to plan all that first...then I hope my enthusiasm will be catching ;p [15:37] zequence: For sure :) [15:40] madeinkobaia: I'm currently reorganizing all of our projects, source, blueprints and planning [15:41] There will be an announcement on the mail list shortly. Some things will change from before [15:41] zequence: Great. [20:40] zequence: I missed madeinkobaia, I would suggest that whatever the size, the two sides should be non-critical content. I am not sure to what ratio... we can probably skip 4:3 I don't know that any computer/monitor made late enough studio will run on has vga... Although I am using one as a second screen on my netbook :) [21:46] OvenWerks: I was investigating projects, blueprints, series and milestones today. LP is slow. Takes many hours to just try some stuff [21:46] I was going to use different branches for different releases, but then thought about bzr tags [21:47] we haven't been using them. We should [21:47] each time we do a release of a source, we tag it [21:47] bzr tag 0.118 [21:47] and to see the tags: bzr tags [21:48] commits can already fill that function, but it's easier to keep track of tags for releases [21:53] With all our source, we could basically use milestones based on Ubuntu version releases, instead of the traditional source version releases. [21:54] -controls was organized after source version releases. One branch for each version. lp:ubuntustudio-controls/0.4, etc [21:55] I was going to do the same for all our source, except use Ubuntu versions, like lp:ubuntustudio-controls/14.04 [22:02] since, we don't know in advance which software version will be the ultimate released version. [22:02] hmm, however, now I just remembered [22:02] it's the problem with release based maintenance [22:04] either we fix bugs directly on the actual debian packages, that we get doing pull-lp-source, or apt-get source.., not doing any commits in the bzr source at all for stable Ubuntu release packages [22:04] ..or we keep different branches for different Ubuntu releases [22:06] for instance lp:ubuntustudio-menu/13.10, lp:ubuntustudio-menu/14.04 [22:06] We might as well. But, for the development branch, we just keep the trunk branch [22:06] and, we make tags for each released version of a package [22:09] Sounds like a lot of overhead :) I was using letters for my snapshots. So if wer are woring towards 14.04 we might have 13.10+1a 13.10+1b etc. [22:10] release would be 14.04, bug fixes could just be letters or 14.04.1 etc. [22:11] So all commits up to release would be the old release +1. [22:12] OvenWerks: I think you're mixing up two things now [22:12] package versions is still the same [22:12] but, we could have different bzr branches for stable releases [22:13] so, for instance, ubuntustudio-meta-0.117 is the upcoming stable release for saucy [22:13] If you prefer. [22:13] that would end up in a branch called lp:ubuntustudio-meta/14.04 [22:13] sorruy [22:13] that would end up in a branch called lp:ubuntustudio-meta/13.10 [22:14] then, if we do a bugfix to that package, we could work off the bzr branch, and the new released version would be 0.117-1 [22:14] So we would start that branch (14.04) right after 13.10 was relesed? [22:14] Or even after FF... [22:15] somewhere like that. [22:15] or, we dont keep branches for stable releases. We just do bugfixes directly to the debian packages [22:15] Ya that was what I meant [22:15] I think... [22:16] the trunk is always the development release [22:16] we only create a new branch when there is a stable release [22:16] feature freeze is a good time to do that [22:16] But if the version doesn't increment then it won't move or update [22:17] -1 -2 would be fine. [22:18] Yeah, or -ubuntu0, or whatever is the standard [22:18] dch kind of does that one automatically :P [22:20] I think I'll try doing release based branches for 13.10. Then we'll see how that works out [22:20] ok [22:21] for 14.04 we keep working off the trunks as usual [22:21] right. That is making sense. [22:25] I'm taking over maintenance for linux-lowlatency for the devel release now [22:25] going to work on getting upload rights early during 14.04 cycle [22:26] we should both get that [22:26] would make things a lot simpler for us