=== mcasadevall is now known as NCommander === asac_ is now known as asac [19:59] Hello from Mer [20:00] lbt, hello from Ubuntu! [20:00] hello thar [20:00] <- here too [20:00] *bangs gavel, announces we'll probably wait a few minutes while everyone gets here* [20:00] * persia waves and rushes to paste some text [20:01] Oh, right, we have that meeting! [20:01] Ah, looks like YokoZar already pasted :) [20:02] hello hello [20:03] and we have maemo.org council chair (jaffa) listening in as well [20:03] Hey Jaffa [20:04] Hiya [20:04] At JavaOne, so mostly just reading :) [20:04] All right [20:04] Let's do introductions. Who's here for the meeting then? [20:05] * YokoZar is Scott Ritchie, an Ubuntu Developer [20:05] * persia is Emmet Hikory, an Ubuntu Developer [20:05] * lbt is the build/sdk/process/packaging/docs non-expert for Mer [20:05] * Stskeeps is Carsten Munk, Mer lead developer/faciliator/whatever (if you read my slides at the UDS meeting, twitter.com/stskeeps has the video + final slides) :P [20:05] * lbt is David Greaves [20:05] * NCommander is MIchael Casadevall, an Ubuntu Developer, and a Mer user [20:06] * ian_brasil me [20:06] :) [20:06] ;-) [20:06] GrueMaster - Ubuntu Mobile QA testing. [20:06] * Jaffa is Andrew Flegg, Maemo Community Council chair [20:06] * qwerty12_N800 is Faheem Pervez, a packager and hacker of code (my knowledge isn't extensive enough to say I'm a programmer) [20:07] Oh, Tobin Davis. (oops). [20:07] (is the meeting open, or restricted?) [20:07] open [20:07] (the meeting is open) [20:07] All Ubuntu meetings are, generally (except security issues) [20:07] * luke-jr is Luke Dashjr, a developer for the unofficial Gentoo N8x0 port [20:07] * lcuk is Gary Birkett, author of liqbase (n8x0 device ui) [20:08] * rgreening is lurking, but has $WORK in the way. need to restore broken network... [20:08] Ok, nice, we have quite a few people here [20:09] The great thing about IRC meetings, unlike real life meetings, is that work doesn't get too in the way (or vice versa). So, let's move on and talk a little bit about how we're going to be working together. [20:10] I got this as an outline http://pastebin.com/d7c524616 [20:10] lbt: yup, that's the agenda more or less [20:11] Everyone, please feel free to ask any questions you have as we bring things up, this meeting is about all of us learning [20:11] *nod* [20:12] I think a good first step is a review of the current Mer and Ubuntu MID projects, and what is needed to bring the former into Ubuntu [20:12] At Ubuntu, the typical workflow for a generic package is something like this: Upstream makes a tarball release (say, Wine 1.1.22 last Friday), Packager (me) downloads it and updates the package we already have (if only the source code has changed and not the build instructions, this is very easy to do). Then I upload it to the development release, and it gets out to the masses. [20:12] NCommander: I agree [20:12] Mer, as I understand, won't be a typical upstream like I just mentioned ;) [20:12] Instead we want to work a bit closer [20:12] I did a look over in an advance of the packaging of Mer, so I'll bring that up after the general upstream status :-) [20:13] YokoZar: process makes sense and aligns [20:13] but layered diffs is an interesting area... [20:13] our view is that we want to act in similar way, but we also have interesting issues like maemo's extended use of native packages :) [20:14] ideally ubuntu packaging would be == mer packaging [20:14] as in, the cleaned up ubuntu packaging ;) [20:15] In the typical workflow, the packaging (/debian) folder is kept entirely in Ubuntu while the source remains pristine; optional distro-level patches are put inside the debian folder itself and applied at build-time using a patching system like quilt [20:15] yes [20:15] we'd like that [20:15] although the maemo packages include /debian [20:16] lbt, Would having the packaging outside the Mer repos block your builds for the Mer cycles? [20:16] and that may need .... tweaking [20:16] (e.g. stripping the Maemo debian/) [20:16] stripping maemo debian/ should be possible [20:16] Stskeeps, well, OBS will build any package that Ubuntu can, so once the packaging is brought up to scratch, that will work fine [20:16] I'm just concerned about not blocking Mer test cycles by doing so. [20:16] I am looking at introducing a (git) VC system to do this [20:16] basically: we are in the midst of cleaning up our act, so we are -very- open to changes [20:17] and managing the seperation of src,diff,/debian [20:17] lbt: Yes, it's also possible to have the debian/ folder live inside a branch [20:17] indeed [20:17] we would also like to find a good way to deal with upstream (and we discussed this a bit with nokia) [20:17] http://wiki.maemo.org/Mer/Documentation/Mer_Package_Patch_Handling [20:17] lbt: indeed this is what much of the "use bzr for more things" push is about in Ubuntu [20:19] in principle the 1 branch per patch approach works for me [20:19] well, or simple quilt patch management [20:19] and 1 branch per packaging flavour [20:19] then export that into quilt [20:19] Quilt is very nice for this sort of thing [20:19] well, most top level packages should rely on the same dependencies and all, so the diff would be just about changelogs, no? [20:20] lower level packages have (or used to) different dependencies as maemo used different names [20:20] i'm open... was looking to setup VC for developers and take branches into quilt for /debian/patches [20:20] we have quite a few code and build patches [20:21] Stskeeps, YokoZar I'm not sure if your aware, but quilt can be intergrated into the package build process [20:21] NCommander: yes, in fact this is where I thought it most powerful [20:21] NCommander: the build script just applies the quilt patches at build time [20:21] (and then all the patches live in the debian/patches folder to allow a single bazaar tree for the Debian packaging, and bazaar stuff, and have a watch file so bazaar can auto-reconstruct a source package without any fiddling) [20:21] (and unapplies them at package cleanup time) [20:21] YokoZar, yup :-) [20:21] yes [20:22] and for me .... each /debian/patches/ file comes from a VCS branch [20:22] NCommander, Except we're dealing with stacked trees, because Mer itself is, in part, a set of patches against Maemo [20:23] persia, VCS import the Maemo trees, and then stack off that [20:23] If possible [20:23] yes... [20:23] master branch is .orig [20:23] we'd really really want to base on tar.gz's, you can't rely on the vcs [20:23] I think k-s's point is probably most interesting: in Ubuntu we really only want one debian/changelog entry per upload, but that doesn't necessarily meet Mer changelog requirements. Would VCS logs be sufficient for Mer developers? [20:23] Stskeeps, pristine-tar can help with coordination between tar.gz and VCS repos. [20:24] persia, we allow for debian/changelog to have non-relevant entries for Debian and other distributions as long as their series name does not conflict w/ Ubuntu ones to my knowledge. [20:24] persia: interesting, didn't know that (per upload) [20:24] NCommander, Yes, but we don't prefer it. [20:24] persia, this is a unqiue case ... [20:25] basically we are going to be doing a lot of fast-paced development where we will need to be doing within-mer package upgrades often [20:25] It's not too hard to have one changelog entry with a bunch of bits to it [20:25] we can however also work on a way to merge multiple versions into one upload for instance [20:25] big changelogs though... [20:26] we may need to manually summarise [20:26] we can however be happy we're at a stage where we aren't patching much anymore. [20:26] Indeed. That's supported, but I think a manual summary would be preferred. [20:26] Do you give version summaries already? [20:26] Or are your release changelogs just big lists of commits? [20:26] commit list [20:26] if anything :) [20:26] currently our packaging is occasionally a mess, and the changelog reflects the changes [20:27] My worry is for Mer developers to be able to effectively test changes per-Mer-cycle, which may require several builds, but I suspect we only want one or two Ubuntu uploads per Mer cycle. [20:27] well. we can always abuse that mer < ubuntu lexically.. [20:27] so ubuntu4 would wrap certain mer versions [20:27] This kind of release announcement could work for you very well: http://www.winehq.org/announce/1.1.22 (manual list at top, commits at bottom, the top goes into our package changelog the bottom doesn't) [20:28] (I mention this because it's exactly how I package Wine, and it comes out every 2 weeks) [20:28] we could do that [20:28] hmmm [20:28] we should do that [20:28] If I had to guess, I'd say the manual changelogs at the top are written by Julliard in about 5 minutes from memory, so shouldn't be much of a burden ;) [20:29] we are still building processe and supporting scripts [20:29] when dealing with the maemo packages we are mostly doing patches and not so much our own development (yet - it's getting there) [20:29] we only just transitioned to OBS [20:29] and I'm in the process of setting us up to handle logging these changes. [20:29] we don't use (AFAIK) the OBS commit messages [20:30] which are (in my case) cut'n'paste from local git repos [20:30] so we (I) need target specifications [20:30] Stskeeps: that's cool, there's no requirement that changelog entries be interesting ;) [20:31] Is swearing frowned upon in changelogs? [20:31] ah, yeah, we might want to filter some. :P spending too much time with maemo packages makes you do stupid things. [20:31] qwerty12_N800: heh -- probably not wise in the summary, but ok in commit messages ;) [20:32] persia you said : I suspect we only want one or two Ubuntu uploads per Mer cycle.... [20:32] * lcuk sighs with relief [20:32] did you mean 1 or 2 Mer cycles between uploads? [20:32] lbt, Just a loose guess. One right before the testing phase, and one at cycle completion. [20:32] Just remember that the eventual user-visible thing is the package changelog entry (which is why it can't be a giant list of commits or a bunch of profanity) [20:32] (they see this in update-manager) [20:33] Mind you, this changes at FeatureFreeze, but I thought it would be a good way to get the Mer code out to users for testing, and the final fixes pushed. [20:33] OK ... so upload when we promote our first :Testing [20:33] lbt, That was my thought, but I'm open to alternate suggestions. [20:33] YokoZar: yeah, I allowed my frustration to get the better of me. I'll try and find those changelogs... [20:33] persia.... why? [20:33] basically, what we hope to start with is simply to slowly start moving packages to "new" workflow. beginning with libosso and libhildon [20:34] THat's actually something I wanted to bring up [20:34] and getting also upstream relations going (libhildon is open to different packaging based off their git trees, and is open now.) [20:34] We do have libhildon in Ubuntu at the moment which is used as a base for the current Ubuntu MID (not sure on other rdepends) [20:34] lbt, Why which? Why two uploads, or why am I looking for alternate suggestions? [20:34] our :Testing can be quite... raw [20:35] so if you intend to publish to end users then it may be good to go for :Testing2 [20:35] We'll need to standardize the Ubuntu libhildon and what your currently working on, as well as remove all the hildonized packages that Mer doesn't want to help reduce workloads at transition times. [20:35] NCommander, current MID upstream doesn't support the current codebase anymore. I don't think we need to worry about it much. [20:35] persia, I'm more worried about libhildon's rdepends. [20:35] NCommander: our libhildon is mostly pure [20:35] StevenK, our libhildon is ancient [20:35] persia... l8r [20:35] I also don't think we want to *remove* the other packages, except where they either have no upstream, or can't be fixed. [20:35] lbt, Catch me anytime :) [20:36] persia, no, but we have hildonization patches on a *lot* of packages that I'm not sure we want to continue maintaining (and this also brings us to the question of packages that Mer and Ubuntu change that have been hildonized in the former) [20:37] if you're wondering if dates-hildon still work, it does :P [20:37] we have a transformational package to help support your naming, but it's not that nice [20:37] NCommander, Hrm. Probably worth a review of rdepends then, indeed. I suspect we'll want to keep some of them. [20:37] persia, agreed, but I can think a few we can toss as well [20:37] NCommander: wonder tha same [20:38] persia, Stskeeps, I think what we need to do as a first step is scrap all the Ubuntu MID stuff we don't want anymore (the current launcher being one), as well as the current meta-packages [20:38] packages like gnumeric and other hildonized... what todo? two versions that conflicts? [20:38] are these hildonisations not from Nokia? [20:38] nah, ubuntu mid ones [20:38] / moblin [20:38] NCommander, I'd rather get the Mer packages in, and then just change the metapackages and tasks. Saves going back to the TB for reapproval. [20:38] OK, so if you want to push these into Mer then they'd need maintainers I guess [20:39] persia, fair enough. We still have those packages to remove though, we need to go through the current seed list and prune it all out. [20:39] lbt, I think it's on a per-package basis: not all of them are useful, but some are nice. [20:39] * k-s hates the hildonization, it's the worst thing ever... pointless [20:39] k-s, +1 [20:39] NCommander, I do believe I'm actioned to do just that on https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer :) [20:39] A lot of the Hildonised apps from Ubuntu MID old would be good to go -> Mer, and maybe -> Maemo [20:39] So basically we're going to get a few orphaned packages that may conflict with the hildon we want from mer and we're not sure what to do with them? That sounds like Ubuntu's problem ;) (unless mer wants to take over them) [20:39] it's just there because Nokia used to want hildon as closed source extension [20:39] What we did for packages that we had to hildonize, we attached the hildon code to a pre-processor flag, and then built it twice, once with and once without [20:40] hildonization has it's plusses, but we are also interested in auto-hildonization. we spent a lot of time making normal GTK apps look nice in Mer too. [20:40] I think that is no longer a problem? [20:40] proper engineer would be to patch gtk to provide better widgets for finger use [20:40] brb, battery flashing signs of death [20:40] I think I like autohildonisation better. [20:40] k-s: The semi-sensible rationalisation is that a mobile UI needs to be rethought, so an incompatible API forces that. Not how I'd've done it tho :-/ [20:40] we encourage hildonization because there's a little more to it than just UI [20:40] Jaffa: ok, but then it's not hildonization as change toolbar or menu, but *new* ui [20:40] such as the libosso stuff [20:40] yes [20:40] Jaffa, Trick is in maintenance: we don't really want to have to carry two versions of e.g. the gnumeric codebase. [20:40] Stskeeps: libosso is also bs [20:41] very few apps are hildonised [20:41] Nb... Qt is trying to hildonise the framework [20:41] Stskeeps: yet-another NIH [20:41] lbt: yes, andthat is transparent to users [20:41] yes [20:41] k-s: admittedly things could have been better [20:41] but some of the signals that it gets are useful for mobile usage [20:41] anyway, most (or all) of this will be dead soon [20:42] care to elaborate on that? [20:43] BTW, I think another point worth bringing up is what architectures do we care about w.r.t to Mer [20:43] (side note but important) [20:43] Stskeeps: i see this going away, I have inside info on the topic, but cannot disclose much :-P [20:43] NCommander: agreed [20:43] (nb k-s I didn't catch your introduction) [20:43] k-s: ah, harmattan probably [20:43] NCommander: we're agnostic to architecture as such (if we see it on package level) [20:43] lbt: I'm Gustavo Barbieri, used to work at INdT, architect and lead developer of canola 1/2 [20:44] Well, this case is kinda special because of the way ubuntu-mid was handled [20:44] :) ta [20:44] Arch wise, we should focus on the two mid architectures (x86 & arm). [20:44] As it stands, the ubuntu-mid build has a hard coded assumption its going to be built on lpia, but lpia is officially un-maintained as of karmic. I think i386, arm [20:44] lbt: now owner of ProFUSION embedded systems, which do contract for Canonical and couple of other companies on embedded/mobile field [20:44] GrueMaster, i386 & armel ? [20:44] In otherwords, no IA64 ports for NCommander. [20:44] Right, I agree, but we're also going to get amd64, sparc, and ia64 for no added cost :-) [20:44] and powerpc [20:45] our wii port would be happy for powerpc ;p [20:45] \o/! [20:45] mobile wii? [20:45] * NCommander tried to run Ubuntu MID a long time ago on his wii [20:45] mer on wii: http://smg.photobucket.com/albums/v119/JohnX/?action=view¤t=CIMG5444.jpg [20:45] (missing background) [20:45] My Wii got mobile when my brother threw it against the wall in frustration. Anyway... [20:45] YokoZar: lol [20:45] but anyway, we are in no way restricting what archs to build on - all that stuff is in our HW support repos [20:46] (it should be noted for the record that there is an Ubuntu PS3 port so ....) [20:46] So, I think we covered 1.1 and 1.2 on the agenda. Shall we go to 1.3? [20:46] That's sexy :-) [20:46] For testing purposes, I am limited to i386/lpia, and arm. [20:46] persia: That was my thought. Any more questions on work flow? [20:46] GrueMaster, I thought you had an amd64 [20:46] (not that we really care but) [20:46] regarding Mer and work flow, lbt is the guy to talk to from us, he's in charge of developer tools etc :) [20:46] persia http://wiki.maemo.org/Mer/ [20:46] NCommander: It is dedicated to LSB testing. [20:47] that is the root for our info sources [20:47] so he'll gladly sit down with some of you and get a workflow worked out that suits us all [20:47] persia, where's the agenda? I don't see it on the wiki [20:47] yes indeed [20:47] I think the consensus seems to be (1: small changelog improvements, 2: use quilt whenever we can [20:47] agenda : http://pastebin.com/d7c524616 [20:47] NCommander: http://pastebin.com/d7c524616 [20:47] * lbt scores [20:48] YokoZar: I would like to work a git->quilt process too [20:48] lbt: Ok, that shouldn't be too hard (takes only a few commands when done manually I think) [20:49] regarding upstream libhildon info: https://garage.maemo.org/projects/hildon [20:49] I'm not sure we sorted the stacking issue [20:49] lbt: that way we could have a -ubuntu-karmic branch where we pull in specific bits and then move them into package quilt automatically? [20:49] yes [20:49] heck.... you could share gitorious [20:49] yes, the question is how to handle orig.tar.gz .. would they be the maemo source with debian/ stripped? :P [20:49] lbt: Are there scripts out there for that already? Because that sounds really cool [20:49] or setup a gateway [20:50] True [20:50] Stskeeps .... implementation..... but handled in master [20:50] (for their native packags) [20:50] and probably stripped to master-debian [20:50] and maybe branched from there [20:50] or forked [20:51] make sense? [20:51] Yeah [20:51] OK... does that handle stacking? [20:51] I worry about patches being patched [20:51] I do this [20:51] it hurts [20:52] okay, so, what do you mean about sources of information? [20:52] about/with [20:52] I think we can avoid the patching-patches issue by restricting Ubuntu delta to debian/changelog [20:53] OK [20:53] If git handles the merging of the stacked patches, then whatever git spits out should be handled by quilt I think [20:53] Except post-feature-freeze, when we use patching-patches *intentionally* to backport specific targeted bugfixes. [20:53] Yeah persia is right there [20:53] OK... I need to learn this.... [20:53] I see gtk2.0 [20:53] nm... l8r [20:54] l8r meaning that we'll look at it later, i presume, and not that you're leaving ;) [20:54] correct .. sorry [20:55] so... "sources of information" [20:55] For sources of information, I think Ubuntu folk are most curious about Mer outlines (link already posted) and Mer code repo. What information about Ubuntu would be interesting to Mer folk? [20:56] the question that keeps bugging me is simple: we're going to have really interesting times with maemo gtk vs no maemo gtk [20:56] I'm interested in how information flows between the projects too (eg we have a wiki and this IRC channel, which isn't the mer wiki or the mer IRC channel) [20:56] YokoZar: we have our wiki, irc channel, and we microblog to mer-chatter mailing list [20:57] microblogging when we move on something and people recieve in digests [20:57] persia: Roadmaps/blueprints/use-cases for karmic vs. Mer would be an obvious one [20:57] Stskeeps, If it's just patches against gtk, we might be able to create another flavour of gtk as part of the gtk package build process. [20:57] persia: you have other flavors? maemo gtk is sometimes considered an abdomination by some :) [20:58] yeah ... the maemo-ised 'upstream' packages tend to freeze [20:58] Jaffa, Well, at this point there's just the one blueprint (https://wiki.ubuntu.com/Specs/MobileMidKarmicUseMer) which will get fleshed out as we get detail. [20:59] On the Mer side everything should be reachable from http://wiki.maemo.org/Mer/ .... is there a similar UbuntuMID root? [20:59] persiia: I suppose I mean how strategic is UMID in karmic? Or is working in Mer and reshipping it going to be "OK"? [20:59] lbt: http://wiki.maemo.org/Mer is the canonical URL, btw. But I put in a redirect on "Mer/", IIRC [20:59] https://wiki.ubuntu.com/MobileAndEmbedded maybe [21:00] Jaffa: We like to avoid use of the adjective canonical to avoid confusion ;) [21:00] (oops ... paste-o) [21:00] YokoZar, rofl :-) [21:00] Jaffa, I don't think I can answer that question. Those of us here from Ubuntu are interested in adopting Mer for MID. I haven't heard anyone say this wasn't a good idea. That said, we're bound by all the freezes, etc. and if it's not good enough, we won't be able to release. [21:00] persia: fair enough [21:00] YokoZar: point taken ;-) [21:01] clarification.... do you intend to [21:01] ian_brasil, I should take that URL down at some point :) [21:01] apply all the Mer patches to Ubuntu, [21:01] or take Mer code and patch it [21:01] / branding? [21:01] lbt, apply all the Mer patches to Ubuntu [21:02] Stskeeps, Good point. I suspect we'll want at least some Ubuntu branding, and you may not want us to use Mer branding. Is branding abstracted in such a way that this can be easy? [21:02] fair, themes [21:02] err, fairly, - themes [21:02] we don't brand beyond themes so [21:02] lbt, To extend on that, there may be limits to which patches we may apply: MID comes fairly low in the stack of flavours, so we can't e.g. break Desktop. [21:02] it should be quite easy to apply themes from what i have seen [21:03] I'm worried about us not keeping up with newer versions than Maemo [21:04] Stskeeps, re: libgtk flavours: current flavours are directfb, shared, static, and (for armel) vfp. Obviously someone would have to investigate the build scripts, but I suspect it's possible to do something without duplication of the base code. [21:04] how do you plan to work with subsystems that are not present in ubuntu and AFAIK have no non-nokia backends [21:04] like the battery subsystem [21:04] mce;dsme we have; battery is hal [21:05] mce/dsme supports non nokia tablets? [21:05] By the way, for karmic I am making a branding-ubuntu (and branding-foo) type packages to contain arbitrary branding for particular apps. So if we want branding inside something that's not part of a theme (say, card backs on solitaire), it can be contained in that kind of package. [21:05] lbt: post fremantle release, rate of change upstream in Maemo should slow down (from Nokia, anyway) [21:05] that is my concern.... [21:05] so Ubuntu gtk will progress [21:05] k-s: powerlaunch yeah; dsme does non nokia hw with some changes [21:05] and we will slow [21:05] lbt: ah, I see [21:06] and then dependency hell bites [21:06] persia: atm maemo gtk is at 0.14 but 0.16 is in progress [21:06] YokoZar: i would like to build a web interface for that :) [21:06] and those patch sets are not small [21:06] Stskeeps, 2.16? [21:07] er, yeah [21:07] on n810 atm so [21:07] Stskeeps: is bme dead in favor of HAL (which is also dead...)? [21:08] k-s: no, but this doesnt relate much to ubuntu. we had meeting with nokia on hw support this weekend [21:08] with good results [21:08] good [21:08] lbt, I think we'll just have to carry/port patches anyway, especially if Nokia's Maemo updates slow post fremantle. [21:09] I'm asking just because hildonized/maemo/mer apps will try to use these systems and will not find them if they are not there [21:09] persia: I suggested to Nokia that we become 'upstream' for their hildon... [21:09] they may be able to help us port forward [21:09] so that the next release is easier [21:09] That works. [21:10] k-s: apps using libosso to listen to battery low events, etc? [21:10] 'suggested' [21:10] qwerty12_N800: yes, or directly talking to bme et al [21:10] lbt, So Mer would end up generating tarballs, which Maemo or Ubuntu could use as a basis for packages? [21:10] k-s, we plan to support mce etc in a cross platform manner [21:10] yes [21:10] I like that plan. Very sustainable. [21:11] and they want to open their development [21:11] cf Trolltech/Qt [21:11] on gitorious [21:11] qwerty12_N800: not that I like bme/mce/... they're mostly NIH stuff [21:11] so internally they point and say "like that" [21:11] k-s: mmm, same [21:11] noone speaks directly to bme-but thats a discussion for later. [21:12] Stskeeps: i'd not assume that, Canola for example do that (but we have plugin to talk to hal as well) [21:12] another place to look for bme info; nice [21:13] just looked at canola sources, we use icd (networking) as well [21:14] dbus wrapper, also taken care of [21:14] good [21:15] YokoZar: yeah, sounds like a good idea (branding package) [21:15] Stskeeps: all upstreams will need to do is just have images and such look for /usr/share/branding/whatever and then fallback to their own artwork [21:15] *nod* [21:16] YokoZar: are you going to do that in Mer? [21:16] YokoZar: that sounds nice [21:16] * lbt wasn't paying attention [21:17] anyhow.... 2) Implementation outline ?? [21:17] was that 2.1 done? [21:17] lbt: This can be done distribution level for whatever non-theme elements can be branded. All your code needs to do is poke /usr/share/branding/(some to be defined hierarchy standard) for its replacement image, then we just fill that image with a branding-ubuntu package [21:18] I'm not sure I understand how to generate the list of packages not already in Ubuntu (2.1), and I think that's a good place for Ubuntu folk to start on packaging. [21:18] yeah.... so I'm not aware we have multi-branding code atm [21:19] maybe this is a task? [21:19] Yeah, a task sounds good. [21:19] i would honestly start with libosso, libhildon and go from there - and integrate it with the cleanup process :) we have lists of packages on OBS that we override in ubuntu [21:19] which should give a hint of how much should go upstream ubuntu or whatever [21:20] Good point St [21:20] Stskeeps [21:21] OBS root is https://build.opensuse.org/project/show?project=Maemo%3AMer [21:21] (apologies for the novell login, they're doing openid too. :P) [21:22] and the interesting parts are in :Devel:Base, :UI, :MaemoCommon, etc [21:24] I am putting together a table that will describe each package's functionality, summarise Mer-isation and link to key places [21:24] lbt, That would be great! [21:24] we have spent some time making diffs in Maemo:Mer:Devel:MaemoCommon , so we can see what the Mer-specific package changes are [21:24] it'll appear on the wiki in the re-written Mer/Build area [21:25] anything else on this ....? or 2.2) Review of Mer cycles against Karmic schedule to define milestones ??? [21:27] https://wiki.ubuntu.com/KarmicReleaseSchedule [21:28] http://wiki.maemo.org/Mer/Sprints has the past: I don't know where to find the future. [21:28] http://wiki.maemo.org/Mer/Releases [21:28] yeah, we were discussing the future this weekend, just haven't been put online just yet. biggest hurdle atm: ui quirks, cross-platform consistent behaviour [21:29] and associated applications to make it a full desktop [21:29] Sprint ending 15 June matches well to preparation for Alpha 3 on 23 June. [21:29] http://bsd.tspre.org/~stskeeps/DSC00331.JPG is somewhat spec for 1.0 [21:29] (.. whiteboard picture) [21:29] Next interesting dates for Ubuntu are 13th August (Alpha 4) and 27th August (FeatureFreeze). I'm not sure how those should align. [21:30] and I have a higher res piccy to clear up arguments [21:30] Err. Oops. There's space for one more sprint between the current one and Alpha 3 [21:30] maybe we should talk about what you'd like to have in your karmic MID. [21:30] stable desktop is reachable - ui and such, and some apps and such [21:30] Stskeeps, That's simple: something that doesn't crash when one runs cat. [21:30] Stskeeps I'm also writing that whiteboard up [21:31] Frankly Mer is stable [21:31] mer is stable with some quirks. [21:31] it's just not that useful [21:31] lbt, Why isn't it useful? [21:31] applications by default [21:31] not many of the useful extras just yet :) [21:31] we do have entire ubuntu so it helps [21:31] and stability/functionality of them [21:31] and prettiness (missing translations) [21:31] ah, yes, translations [21:32] but it's not *bad* at crashing at all [21:32] our quirks are GTK quirks really and some theme things [21:32] we also have gpe [21:32] So, package list is (roughly): browser, email client, book reader, media player, text editor, photo viewer, calendar, address book, file manager, instant messenger, feed reader, alarm clock. [21:32] Rather, desired package list. [21:32] sure [21:32] We've bunches of apps in Ubuntu (it's what we do best), so I'm sure we can find something to meet most of these requirements. [21:33] but on small screen with fingers, not a mouse [21:33] browser: Tear (probably), email client (claws or modest if anyone ports it), book reader (fbreader), media player (gpodder or canola), text editor (maemopad+ etc), photo viewer (mirage), calendar (not sure), address book (not sure), file manager: finefm but it needs improvement. instant messenger (pidgin), feed reader (rss-reader), alarm clock is interesting [21:33] gpe-cal is working [21:34] so is gpe-contacts and file mgr [21:34] xchat too [21:34] we have no cron [21:34] * ian_brasil +1 canola [21:34] yeah.. alarm wakeups are interesting at the moment but it'll be better [21:34] meh... it'll never catch on [21:34] ;) [21:34] Well, we'll end up with cron, just as part of the Ubuntu base. I don't think we can safely omit it with the way germinate works. [21:35] that may not be good for powersaving [21:35] We have a hildonised alarm clock, but it's a bit buggy. [21:35] lbt, which is where mer may differentiate a bit [21:35] since we can wreck more in our own variant of ubuntu [21:35] persia, Stskeeps we have fbreader [21:35] lbt, anacron (or similar) can help with that. We don't *have* to do wakeups, but we do want to do things like log rotation. [21:36] see here for things we almost have : https://build.opensuse.org/project/show?project=Maemo%3AMer%3AExtras%3ADevel [21:36] overview : https://build.opensuse.org/project/monitor?project=Maemo%3AMer%3AExtras%3ADevel [21:36] noone said ubuntu mid should be 100% = mer, mer is closer to maemo in terms of power saving methods, and ubuntu mid usually target devices that can stand a little more beating than a arm processor :P but that's a different discussion [21:37] (regarding alarm wakeups and so on) [21:37] in mer (dist) we'd have alarmd instead of cron, no log files, etc for instance :P [21:38] but we would like to have same application API across the board (hildon, etc) [21:38] Right. I think there's some rationale for separating Mer(dist) from Mer(code). We'll want to align on code, but may make different dist choices. [21:38] *nod* [21:39] :Apps may be Mer (dist) [21:39] our hope is that we can take the same app and ideally compile it towards Maemo(Fremantle), Mer(dist), Ubuntu MID [21:39] From my biased viewpoint, I'll hope you won't need Mer(dist) in the future, but that's separable :) [21:39] we'll see where we end up, i can sometimes in my darkest dreams hope Mer would be Maemo6 eventually, but hey ;) [21:39] I was thinking about Mer (dist) being a default install [21:40] indeed... Mer is what you get when you install Harmattan+n and only get the open SW [21:40] Anyway, I think we're drifting again. [21:40] s/is/should/ [21:40] we are [21:41] So, cycle dates. [21:41] I'll do a list of apps [21:41] and allow us to track them [21:41] This Mer cycle ends soon. [21:41] reasonably we'll have some more apps and some work, and stable fremantle beta1 packages [21:41] I think Next Mer cycle would do well to try to end ~ 16th July to give time to push everything for Ubuntu Alpha 3. [21:42] Yes, the Ubuntu cycles are important to keep in mind -- they're surprisingly stricter than many upstreams are used to because of the time based release process [21:42] yeah, we had some discussions on that at the meeting :) [21:42] cycle+2 has a couple sensible targets: either a bit before the 31th (for Alpha 4) or a bit before the 27th (for FeatureFreeze). [21:42] s/31/13/ [21:43] Alternately, perhaps have a testing release around the 13th, and the cycle end around the 20th. [21:43] let me just see the sprint calendar, sec [21:43] After that, we'll diverge, and Ubuntu will only be able to accept backported bugfixes except in very special cases. [21:44] right, 13th july would be our release date [21:44] of 0.15 [21:44] OK. That works. Then we have two weeks to chase any features from 0.16 we *really* want for 9.10, even if they aren't quite polished. [21:45] if we work together to clean up packages, minor GTK fixes and such, we should be able to get a decent result in [21:45] We can pull the polish for 0.16 post FF. [21:45] persia: I'd expect those 2 weeks to be polishing 0.15 [21:45] Err, 0.17 [21:45] i'll say this again though: we need to really look at maemo gtk - it's one of those annoying things about Mer/Maemo code. a lot of apps rely on maemo gtk :) [21:46] so that should be one of the first priorities as well [21:46] Hrm? 0.14 comes out RSN, right? 0.15 in July (for Alpha 3), 0.16 in August (near Alpha 4), and 0.17 won't finish before FF, right? [21:46] seconded [21:46] persia: yeah, 15th june [21:46] Rght. So 0.17 will be what ends up in 9.10. [21:46] keep in mind that this is dist release. individual packages may reach stable releases quite often [21:47] Unless the goals for 0.18 can be bugfixes (no new features), in which case we can probably pull that [21:47] *nod* [21:48] so it looks like we sync pretty nicely [21:48] I wouldn't expect to be able to get 0.19 into Ubuntu, so that might be a good opportunity to catch up on feature development missed in 0.18, and we can resync with 0.20 in November. [21:48] * lbt is confused ... "0.17 won't finish before FF" "0.17 will be what ends up in 9.10" [21:48] 0.14 i think [21:48] OK. Let me try this again. [21:49] 0.14 should release RSN, and will probably roughly match the initial uploads to Ubuntu. [21:49] 0.15 should release in July, and ought to be the basis of the Alpha 3 images. [21:49] 0.16 should release in August, and ought to roughly match the Alpha 4 images. [21:50] 0.17 crosses feature freeze: with luck we can push affected bits of that in time, and so have that be the feature basis for 9.10 [21:50] sounds good to me [21:50] If 0.18 (releasing in September) focuses on bugwork, and doesn't include new features, we can probably pull it entire. [21:51] If there are new features, we'll have to backport the bugfixes, which is more work for all of us. [21:51] ah... pushing 0.17:Testing pre-FF then? OK [21:51] and it will make sense by then to have a bugfix cycle I'm sure! [21:51] 0.19 (releasing in October) is too late to get into Ubuntu, so it's a good time to work on experimental features skipped in 0.18. [21:52] lbt, Right. Bit of scheduling coordination needed, but I think we can do it. [21:52] we're not tightly locked to months, we change once in a while, so if need be, we adjust [21:52] Then, 0.20 should release in November, and we can pull that as the first import of Ubuntu 10.04. [21:52] That actually sounds like a great cycle. Odd, Experimental, Even Stable. [21:53] [21:53] ? [21:53] lbt: were you concerned by that? [21:53] not really :) [21:53] amusedf [21:54] old kernel numbering .... [21:55] Actually, it is still used in the kernel community, along with a lot of other development areas. [21:55] * persia notes that it's now 6am locally, and hopes to chase the agenda to *finish* the meeting. [21:55] persia... are you going to update the schedule as per comments [21:56] I'll do the Mer sprints page [21:56] and crosslink [21:56] lbt, I don't think the Ubuntu Release Team cares what schedule we use, but I'll update the spec to detail the correspondance. [21:57] ok, so where are we in outline? [21:57] OK [21:57] Stskeeps: we're at testing now I believe [21:57] 2.3) Image creation [21:57] Right. So, we've this big complex environment to create images. [21:57] It's easy for us to create .isos for i386. [21:58] It's perhaps less clear what (if any) images to create for armel. [21:58] (Mer has one too... we call it Stskeeps) [21:58] So, I thought we might just create .isos for armel as well, expecting the rootfs to be extracted by anyone wanting to do an install. [21:59] might work [21:59] can we auto-extract? [21:59] Saves thought, and probably scales better to the wide variety of armel devices that need kernels not included in Ubuntu. [21:59] should be easy enough [22:00] lbt, It's possible to write scripts that extract, but I'm not sure we can have autoextraction happen on the Ubuntu cdimage server. [22:00] OK, shall we leave that as an Ubuntu problem then? [22:01] I'll note as an issue [22:01] Sure. Just something to be aware of for the future. [22:01] I suspect that users will probably cross-post bugs and support requests, etc. [22:01] do you have a target list of machines? [22:02] like we have N8x0, Freerunner, SmartQ etc [22:02] auto-extract doesn't have to happen on the server [22:03] Theoretically, we'll support anything. In today's kernel meeting, it was indicated that there was an expectation for support for only one or two SoCs for karmic, which restricts the list. [22:03] k [22:03] For Karmic everything is compiled for ARMv6+vfp, so the freerunner won't work. [22:04] yeah, it already doesnt [22:04] Anyway, if nobody objects to my suggestion about images, let's do it that way and move on. [22:04] k [22:04] and again for testing does it make sense to pick a few targets to understand their needs [22:05] anyhow... we'll get to that I guess [22:05] Sure, although we've the kernel issues, which makes it tricky. [22:05] I think I'd rather focus on application and environment testing for now. We can get into the deep stuff once that's working. [22:06] Agreed (hardware wise, I'll be doing testing on the two pandoras I've ordered) [22:06] I don't think Meirziki is around [22:07] I also plan on ordering a Pandora, as soon as I get my replacement credit cards. [22:07] regarding devel and testing we will have 0 smartq5/7 rebates too [22:07] that many? [22:08] er [22:08] 10 [22:08] I've an i386 MID which I can use for testing. [22:08] GrueMaster: are you going to put up a target list of 'tested' hardware? [22:08] ubuntu mid developers will fit under this too [22:08] and are we going to pool test resources? [22:08] we'll test yours if you test ours [22:08] I only have limited hardware to test with, but I can. [22:09] lbt, Depends on how much testing you want for 0.20. If you're happy to pool, we certainly are. [22:09] Err, 0.19 :) [22:09] I think we need to start testing early unless you're up to speed [22:09] we're not! [22:10] do you have test processes for Ubuntu that work for MID ? [22:10] Some, but not much at the moment. [22:10] That comes to 3.2: we need some test plans. [22:11] OK... should you/we aim to start testing Mer 0.15 ? [22:11] I think we have some for installation, but nothing for any applications. [22:11] It really depends on the application. If it supports ATK, we can automate. [22:11] 0.15 / Alpha3 sounds like a good place to start integrated testing. [22:12] agreed [22:13] But we'll need test plans beforehand. Anyone up for writing some? [22:13] hmm I was going to say : GrueMaster are you the guy who's going to write the plans.... [22:13] ;) [22:14] I really have little experience with MER at the moment. I saw it in action at LinuxFest NW, but only briefly. If I can get it working here, I can start writing something up. [22:14] well its hard when not knowing what intended collection of components would be [22:14] OK... atm are we focusing on app plans? [22:14] More like basic functionality. [22:14] GrueMaster: was johnx presentingÂ:) [22:14] lbt, Do you think we should focus on something else? [22:14] and things like desktop/menu/statusbar [22:14] Might have been. I can't remember. [22:15] well, we have limited resource... the foundations should be stable [22:15] we need to focus on the areas we touch most [22:15] like keyboard integration things [22:17] we will definately know more when hildon desktop runs in mid [22:17] on the Mer side we have Merziki... but I really don't feel comfortable knowing how much time he has [22:17] lbt, Right. I don't think we need to touch much of the base Ubuntu stuff: just some basic tests to make sure that Mer works. [22:18] are you also interested in Mer/Ubuntu integration testing (whatever that means) [22:18] hmm [22:18] like package mgr [22:19] that's an interesting one :) [22:20] That would be part of the testing. Make sure the default apps sit well with the UI. [22:20] actually our application manager is a bit special AFAIK [22:20] lbt, Indeed. I know we have a hildonised update-manager, but I'm not sure we have a good package management UI. [22:20] Stskeeps will it even work on a normal repo? [22:21] yeah [22:21] and the categories etc [22:21] and what apps it shows? [22:21] hackable [22:21] it is very cut down [22:21] OK [22:23] so that's just an Ubuntu task then... hack the appmgr... [22:23] It feels a little like we've stalled on 3) Testing Review [22:24] do we defer to next time? [22:24] or will someone volunteer to have some testing answers by then? [22:24] Sorry, most of my previous testing experience has been automated hardware testing. I'm still shifting to software testing ATM, but coming up to speed fast. [22:25] I think we can safely defer: I believe we've covered most of the essentials, and at least know what needs doing. [22:25] well, if you want to volunteer GrueMaster then I can help... and maybe talk to MZ too === dyfet__ is now known as dyfet [22:26] That'll work. [22:26] The only last point is 3.3: once we get the test cases defined, we'll need to make sure we get full test coverage for all the published images for each milestore in Ubuntu (e.g. Alpha 3, Alpha 4, etc.) or we won't be able to be included in the release. [22:27] I think plars has that angle. [22:28] OK... I have a list of some actions and issues I can cut'n'paste... [22:28] OK. Anyone have anything else we *need* to cover? I think it's getting quite late in Denmark :) [22:28] lbt, Please do. [22:28] ISSUE: version tracking. Eg Maemo/hildon gtk will freeze [22:28] ISSUE: How should Ubuntu best produce images (eg ISOs are easy but may need rootfs or extractor script) [22:28] ACTION: Support/provide release commits like this : http://www.winehq.org/announce/1.1.22 [22:28] ACTION: Review objectves of Mer->Ubuntu upload and determine timing (:Testing2 or just :Stable) with persia [22:28] ACTION: Produce workflow to be quilt and git-branch based [22:28] ACTION: Contact Nokia re making Mer upstream for open development of Gtk (via gitorious cf Trolltech/Qt) [22:29] ACTION: Page listing apps for featureful release and status/links [22:29] ACTION: Update Mer Sprints page to show schedule sync and crosslink to KarmicReleaseSchedule [22:29] ACTION: GrueMaster to put up a target list of 'tested' hardware [22:29] TASK : Ubuntu code needs to poke /usr/share/branding/(some to be defined hierarchy standard) then filled with a branding-ubuntu package [22:29] TASK : Ubuntu taskto hack the appmgr to work as needed [22:30] nb... the tasks are mine for Mer unless there's a name [22:30] s/tasks/actions/ [22:31] branding is probably YokoZar [22:31] Yes [22:31] I'm happy to help with the package manager. [22:31] also work out workflow, git, packaging, mid people access to mer trees etc [22:32] Stskeeps that's already on my sprint page [22:32] k [22:32] (apart from mid people access) [22:32] I'll add that [22:32] I'll also help w/ package managerment [22:32] Wait, did we cover how we want to handle uploads into Ubuntu itself? To my knowledge, no one in Mer is MOTU [22:33] or, wait, nm, I see it [22:33] Right. Getting Mer folk upload rights is my task from the UDS session. I think it's best left until we've sorted some of the basics, and have a good workflow established. [22:34] I'm MOTU ;) [22:34] yep [22:34] actually we have an action to talk to persia about becoming devs [22:35] we will see if its even needed i guess [22:35] Stskeeps, I think it will be convenient, much as I suspect it would be useful for a few Ubuntu folk to have commit rights (once we sort out who is actually doing enough to use them) [22:36] yeah, I suspect the workflow will be pull but people may well have 2 hats :) [22:37] k [22:37] schedule timing for next meeting ? [22:37] whilst people digest [22:38] Well, do we need another big comprehensive meeting soon? [22:39] well.... I'm more thinking that we may need nagging [22:39] Personally, I'd rather chase the open TASKS, with discussion here, in #mer, on ubuntu-mobile@ and with mer-chatter@ [22:39] one on ones maybe; lbt and someone on workflow and packaging [22:40] If we bog down, we can schedule something. Otherwise, I think we're in good shape for three weeks or so. [22:40] Stskeeps, Absolutely: I suspect we'll need a bunch of those. [22:40] ok 3 weeks then... how does that fit to release cycle? [22:40] Stskeeps? [22:41] persia, commit rights to Mer's git trees? [22:41] NCommander: easily [22:41] NCommander: help me figure out the workflow and you're there... [22:41] we are open so [22:41] NCommander, for those that are doing enough that it becomes easier to grant commit than to review, why not? Same for uploads to Ubuntu. [22:42] persia, I was just asking for clarification; I missed a bit of the meeting, but it was my impression that everything was going to be in upstream git w.r.t to packaging unless I'm mistaken. [22:43] I thought we were doing separate branches for packaging, but I could be mistaken. [22:43] NCommander: I'm working on that... [22:43] I would like to do branches for packaging and patches [22:43] Well, LP is getting the ability this(?) or next week to do git imports [22:43] That's the workflow bit that needs to be sorted (but at a time that's more convenient to those of us not in negative timezones) [22:44] yes [22:44] NCommander: do you have opinions? [22:44] if so then I'll work with you [22:45] lbt, I can think of a few good ways we could do this. [22:45] OK... you're named in my action ;) [22:46] woo! [22:49] k, anything else im needed for? else im off to bed [22:49] YokoZar, Are we done? [22:49] I believe so [22:49] 23rd June? [22:49] Someone should log this [22:49] and save it somewhere [22:49] (especially the action items) [22:50] I've got logging enabled. Let me know where to post. [22:50] your wiki I guess [22:50] I think it's already logged. [22:50] The action items will go on the Mer wiki somewhere [22:50] * persia double-checks [22:50] http://irclogs.ubuntu.com/2009/06/02/%23ubuntu-mobile.html [22:51] bbl, thanks for the meeting, gf wants me to sleep nowÂ:P [22:51] good enough. [22:51] night Stskeeps [22:56] Cheers, thank you everyone [22:58] yep... g'night all and thanks