[00:05] hi RAOF [00:05] hi TheMuso [00:06] Hey rickspencer3. [00:06] Morning rickspencer3 [01:04] good night all, time for a bit of a break === almaisan-away is now known as al-maisan === oubiwann is now known as oubiwann-away === oubiwann-away is now known as oubiwann [07:26] good morning [08:21] Good morning [08:22] Guten Morgen pitti [08:31] pitti: I didn't see seb128 yesterday evening. I think e-d-s hasn't been copied to -updates [08:32] ok, will do that [08:33] thanks pitti :) [09:17] pitti, hey [09:17] bonjour seb128 [09:17] pitti, do you have any opinion on what to do with GNOME 2.30.2 updates which only have translation updates? [09:17] is that worth doing sru uploads for those? [09:18] hm, good question [09:18] in theory we could just upload the .po files to rosetta [09:19] that would avoid a rebuild/SRU and should not be a lot of effort (one tar and one web ui upload per package) [09:19] ok [09:19] not sure, WDYT? [09:19] let me see if dpm can help me to get that done [09:19] I would agree with uploads [09:19] rosetta uploads I mean [09:19] dpm, hey [09:19] hm, I don't see an "upload" button on https://translations.edge.launchpad.net/ubuntu/lucid/+source/gnome-panel [09:20] I have one on my own project pages [09:20] seems that requires some super-powers? [09:20] seb128: so if you or dpm could just upload the tarballs, that seems easiest to me, and safe as well [09:20] pitti, ok, what I think as well, thanks [09:21] pitti, I will still do the gnome-desktop one to have the "about GNOME" version updated, I guess that's ok? [09:21] oh, sure [09:21] thanks [09:21] pitti, how are you otherwise? ;-) [09:22] I'm good, thanks! [09:22] had some fun with apt yesterday, I did what I'm best at and broke everything :) [09:22] hehe [09:22] and seems I'm now getting pulled into a second OEM project [09:22] I'm glad I'm still on lucid :p [09:23] pitti, getting busier every day? ;-) [09:23] seb128: oh, I broke the OEM projects, not Maverick [09:23] it was just because C++ sucks :) [09:23] pitti, I've a feeling they will not want to let you come back after 6 months once they see what you can get done ;-) [09:23] seb128: oh yes :) but that's a good thing [09:24] I recently created https://wiki.ubuntu.com/ReducingDiskFootprint [09:24] "Use XFCE instead of GNOME" [09:24] but seems I'm done with that topic now, and back to boot speed :) [09:24] ;-) [09:25] seb128: there are some focus changes for me right now, indeed :) [09:25] I was thinking about speed the other day [09:25] seems we stopped doing any chart for a while now [09:25] or a least watching how those are doing [09:25] right, would be interesting [09:26] seb128: hi, regarding papercuts and the gnome problem for maverick, we had decided to milestone more of non-gnome/non-gtk3-required bugs , so that will solve part of the problem.. [09:27] regarding gnome packages , how can we ensure the non-gtk3-required bugs get fixed in Maverick? you are probably not going to be backporting all those gnome changes from upstream regularly. is there some way to ensure they get patched in maverick? [09:28] vish, ok [09:28] vish, I can backport all the fixes to papercuts if they apply to the current codebase [09:28] vish, if upstream refactored the code it might not be as easy though [09:29] seb128: yeah, it would be awesome if you can backport the changes. shall i ping you regularly about the papercuts , or are you having a schedule to check those regularly? [09:29] seb128: hmm, seems bootchart stopped creating .pngs.. I just get the .tgz [09:30] vish, I will check the fix commited tasks [09:31] pitti, do you have pybootchart-gui? [09:31] seb128: cool , thanks. :) [09:31] seb128: yes; I'll run it manually now to see what's going on [09:33] seb128: ah, crashes [09:36] seems it's looking for something "RSDTZXW" in /proc and doesn't find it [09:37] weird [09:38] oh, that's the list of prossible process states [09:38] "RSDTZXW".index(flag) + 1 [09:38] i. e. some process is in a state which isn't contained there [09:40] ok, got it fixed [09:41] nice [09:41] pitti, https://wiki.ubuntu.com/ReducingDiskFootprint is interesting reading [09:43] seb128: http://people.canonical.com/~pitti/bootcharts/daniel-maverick-20100622-1.png [09:43] doesn't look that much different from lucid, I think [09:43] except that nm-applet seems to have regressed [09:43] hm, hang on; I think I set an empty keyring password this time, so it'd connect automatically [09:44] that might explain the difference [09:44] right [09:44] but the applet still seems to consume an inordinate amount of CPU [09:44] it should be wpasupplicant and N-M doing all the work [09:44] this is still the -4 kernel, but userspace should be current as of yesterday [09:45] I'm wondering if they do but that just reflects on the applet on the chart for some reason [09:46] hm, I don't think bootchart is that bad [09:46] they are just connected via dbus, it's not the same process or so [09:46] ok, so I've no clue why it's taking so much cpu [09:47] I don't think nm-applet changed since lucid and we did solve the icon loading issue [09:47] I'm going to trash the mini now and install something else, but this one has zero customizations, so I guess there's not much evidence to kill [09:47] well we do lazy load animation icons [09:47] but good to know that there are no obvious regressions by now [09:47] but if you autoconnect you do load those [09:47] still it should not create that much cpu use === ogra_ is now known as ogra [10:06] good morning everyone [10:16] hey chrisccoulson, how are you? [10:18] hi seb128, i'm good thanks (much better than yesterday). how are you? [10:19] I'm fine thanks [10:20] oh, you were not feeling ok yesterday? side effect from weekend gardening? [10:21] seb128 - yeah, i didn't feel too good yesterday. i got quite badly sunburnt at the weekend, and i ached a lot from doing gardening too === ara_ is now known as ara [10:22] chrisccoulson, so next weekend less effort and a bit extra relaxing ;-) [10:22] yeah, i intend to do nothing next weekend ;) [10:25] I just did a gnome-settings-daemon-2.30.2 release, can someone please upload it (we need it for u1), or should I submit a branch? [10:27] ? [10:27] to lucid or maverick? [10:28] you need the .pc there? [10:28] what is u1 doing with it? [10:43] seb128, to maverick [10:44] seb128, we need the .pc file changes because we're writing a gsd plugin [10:47] rodrigo_, to do what? [10:47] rodrigo_, I'm just being curious ;-) [10:47] rodrigo_, I will do the update today [10:49] morning [10:51] seb128, to listen for changes in config and notify users of quota exceeded in u1 server, and other things not yet defined [10:51] seb128, if you want, I can submit a branch with the changes? [10:52] rodrigo_, changes to what? g-s-d for the update? [10:52] lut huats [10:52] rodrigo_, I'm not sure I like adding things to g-s-d, it makes it fragile and slow desktop login [10:53] hmm, is it just me or is terminal background handling broken in lucid? selecting 'solid color' makes the background partially transparent? [10:53] while selecting 'transparent background' allows me to select fully opaque background? [10:54] it's a theme issue [10:54] try with an another theme [10:54] hello seb128 [10:56] seb128, I selected custom colors... anyway - checking with other theme === oubiwann is now known as oubiwann-away [10:56] zyga, known issue with the theming change done in lucid [10:56] "solid color" means "what the theme used define" === oubiwann-away is now known as oubiwann [10:57] seb128, yes [10:57] which is translucid background for the light themes [10:57] seb128, I see [10:57] rodrigo_, if you have it ready feel free to hand it to me for review [10:57] seb128, it's a very lightweith plugin, don't worry [10:57] seb128, we thought about having it as a separate daemon, but that would slow things more [10:57] rodrigo_, well I don't like much things watching files and servers, it means ios and that's often slow [10:58] rodrigo_, but let's see how it behaves in practice [10:58] seb128, it doesn't watch files or servers, it just listens to dbus signals [10:58] so you have another service running which sends those signal? [10:58] seb128, yes, syncdaemon [10:58] couldn't the said service displays the informations directly? [10:59] well, it's too heavyweight already to have more code added to it, and we don't want gtk usage there [10:59] ok [10:59] let's see how it goes in practice [11:00] anyway, you just reminded me that we should connect to dbus after a timeout long enough that we don't interfere with the desktop login [11:00] as the screensaver and other gsd plugins do === tkamppeter_ is now known as tkamppeter [11:06] rodrigo_, would be nice yes [11:07] rodrigo_, so where is your gsd update for review? [11:07] seb128, just a minute [11:07] ok, no hurry [11:08] I get this btw when branching: [11:08] Doing on-the-fly conversion from RemoteRepositoryFormat(_network_name='Bazaar pack repository format 1 (needs bzr 0.92)\n') to RepositoryFormat2a(). [11:08] This may take some time. Upgrade the repositories to the same format for better performance. [11:09] I hope it's not a problem, kenvandine had a hard time merging some of my branches for couchdb-glib and evo-couchdb [11:09] should not [11:17] seb128, ok, pushing, it takes time it seems, because of the different branch formats [11:17] ok [11:19] seb128, https://code.edge.launchpad.net/~rodrigo-moya/ubuntu/maverick/gnome-settings-daemon/2_30_2_release/+merge/28154 [11:27] rodrigo_, thanks, will review that after lunch [11:27] ok, thanks [11:45] seb128, maverick GTK package depends on recent version of libx* [11:45] seb128, is there a reason for that? [11:46] those libs are not in lucid [11:46] removed the versionned dep, rebuild on lucid, and it works fine... [11:49] seb128, we need gtk 2.21 for Empathy, so we are going to backport glib/gtk/dconf from maverick into our ppa. Is there any issue you think we could have? [11:59] pitti, seb128, sorry for the late reply. The "upload button" is here -> https://translations.edge.launchpad.net/ubuntu/lucid/+source/gnome-panel/+pots/gnome-panel-2.0/+upload [11:59] Zdra, hi [11:59] dpm: ah, nice; thanks! must have overlooked it [11:59] Zdra, not really, debian updated those requirement for the udeb changes, the udeb are special debs for the installer [11:59] mvo, good morning, did you get details from the Launchpad team on the archive index stuff? [12:00] Zdra, if you don't plan to build installation using the debian d-i you should have no issue [12:00] dpm, hi, thanks [12:00] seb128, cool thanks :) [12:01] dpm, will those upload count as upstream translations or ubuntu ones? [12:01] Zdra, you're welcome [12:01] pitti, it's a bit difficult to find, actually. You have to first click on " View template & all languages..." and then you get to the upload link [12:02] that's probably why you did not find it, it's a bit hidden, tbh [12:02] that's probably half of a feature to prevent accidental uploads ;) [12:05] dpm, ? === MacSlow is now known as MacSlow|lunch [12:05] seb128: those are ubuntu translations; upstream ones are lp.net/gnome-panel/+pots [12:06] pitti, right but I though there was a difference between strings coming from upstream and rosetta overrides [12:06] ah, I see what you mean [12:06] pitti, I want to make sure those are correctly flagged as upstream ones, ie will change in the next version if upstream change those [12:06] * pitti defers to dpm [12:07] pitti, rather than staying with what is uploaded because they count as ubuntu overrides of upstream strings [12:07] mvo, hi - are you familiar with a software-center but where authorization popup freezes and has to be closed by clicking on 'x' (lucid). Authorization works the second time you try [12:09] zyga: amd64? [12:09] seb128: if you can have a minute this afternoon, I'm stuck with a libtool issue for evo express branch (no hurry though) [12:09] james_w, yes [12:10] didrocks, tell me [12:10] seb128: http://paste.ubuntu.com/453328/plain/. Context is: plugins/sa-junk-plugin/em-junk-filter.c calls e_shell_get_default defined in shell/e-shell.h [12:10] zyga: it's a well-known bug with packagekit-gnome, I wonder if it's 64-bit specific, or more likely to happen on 64 bits. [12:11] seb128: em-junk-filter.c contains the right include, as -I../.., which makes it build successfully with gcc (first lines) [12:11] james_w, I experience it every time I try - I actually learned to work around it without thinking [12:11] seb128: however, nothing linked and available from libtool [12:11] zyga: debugging would be great, I can't reproduce [12:12] james_w, any hints on how to start? [12:12] I'm a little bit familiar with software-center [12:12] but I never used policykit [12:12] wait, did you say packagekit? [12:12] or policykit? [12:12] didrocks, in what object is e_shell_get_default defined? [12:13] zyga: I meant polkit [12:13] didrocks, you lack a -l [12:13] seb128: I think it should be built in libeshell_la-e-shell.lo [12:13] didrocks, do you likely need a -llibeshell [12:13] hello mvo [12:13] seb128: let me have a try [12:13] mvo, do you remeber the spec about installing updates on shutdown? [12:14] seb128: I should change the rpath to to point to shell/ directory too [12:14] seb128: it's not a shared library btw, from what I see [12:14] I don't know about rpath and never use those [12:14] what you need is -L../..../eshelldir -llibeshell [12:15] rather -leshell [12:15] seb128: and the difference with adding ../../shell/libeshell.la (which works?) [12:16] that should work as well [12:16] the .la will define those things for you [12:17] oh right, seeing in the header [12:17] ok, now I have to find the autofoo to get that working properly :) [12:17] do you think that I should add that in a separate patch than the express one? [12:17] but upstream likely fixed that in their express codebase [12:17] no [12:18] ok, I'll summit that upstream so [12:18] thanks seb128 :) [12:18] you're welcome [12:18] seb128, pitti, let me check something with the lp devs about upstream/ubuntu uploads and I'll come back to you [12:18] mvo, james_w: I ran software-center --debug, but it does not mention the policykit transaction, I still get to reproduce this every time I try [12:19] dpm, thanks [12:20] zyga: it's a race between polkit-gnome and polkit I think, so you need to look that those components [12:23] appindicator-cil fix is in maverick now, right? [12:23] so, I can submit a new tomboy package? [12:24] ok, fixed, thanks again ;) [12:27] didrocks, fixed the appindicator-cil thing you mean? or were you talking to someone else? :) [12:27] rodrigo_: was talking about the libtool issue I had (few lines before :)), sorry ;) [12:27] rodrigo_, yes [12:27] rodrigo_: but yeah, appindicator-cil is fixed normally now [12:27] rodrigo_, that got uploaded today [12:27] seb128, pitti, when uploading a tarball, all translations uploaded in that tarball are marked as upstream. So an option for those updates (if there aren't many, because the tarball uploads when not going through package uploads must be done manually - i.e. there is no API for that) would be to fetch them from git upstream, put them in a tarball along with the template and upload them through that form. The caveats I see though: a) if there are many su [12:27] ch updates, doing all this manually might be quite an overhead b) As we'll be uploading a POT template (otherwise the PO files won't be imported), that POT template must be the one from the Ubuntu package if there has been any string modification or addition in the package. I'm not too sure what implies the most overhead: the manual uploads or SRU'ing, what do you think? [12:27] didrocks, ah, ok, thus my confusion :) [12:28] seb128, ok, uploading tomboy then [12:28] seb128, we backported the patch to 1.2 btw, so we'll leave to you the decision to move to 1.3 :) [12:28] rodrigo_, ok, how come you didn't go for 1.3? upstream are not sure they will not depends on gtk3? [12:29] seb128, dpm: I think manually creating and uploading a tarball should not make too much work; less work than a full SRU, in any case [12:29] and we are speaking about an order of 5 packages here, not 50, right? [12:29] seb128, yes, they are sure, but just in case some other dep pulled gtk3 [12:29] dpm, pitti: hum, I'm unsure now, I think I will be lazy and let translation team pick those updated po if they want [12:29] pitti, yes, I've exactly 5 of those on my list right now [12:29] seb128, we have the patch for 1.3, so for alpha3 we might want to upgrade, but we really don't need it, thus our conservative behavior :) [12:29] they don't need to be from git upstream (although that wouldn't make much difference wrt. efforts involved), we'd just need to tar cv po/ and upload that, right? [12:29] rodrigo_, ok, thanks [12:30] pitti, tar wouldn't give us the right pot though [12:30] pitti, yeah, we'd need the pot as well [12:30] pitti, we need to apply patches and run intltool-update then do a tarball I think but yes [12:30] seb128: ah, right, because of the pot [12:30] either generating it or simply downloading the one from rosetta and putting it into the tarball [12:30] but you'd need to do that for an SRU as well [12:31] right, it's just that I know what I'm doing when I do a SRU [12:31] seb128: so, if you decide to do full SRUs [12:31] I feel less confident with tweaking launchpad [12:31] then it's fine, but it involves an additional verification step again, and the additional overhead of users having to download the package for zero changes (well, hopefully :) ) [12:31] right, I don't want to SRU those [12:32] I think I will just let things the way they are [12:32] seb128: since these aren't urgent, perhaps just try with one package for now, and see how it goes? [12:32] or ignore them, right [12:32] translation team can upload updated po files themself if they want [12:32] seb128, so, if someone can merge https://code.edge.launchpad.net/~rodrigo-moya/ubuntu/maverick/tomboy/1_2_with_proxy_support/+merge/28162 please? [12:32] rodrigo_, ok, doing that [12:32] thanks [12:33] dpm, pitti: thanks, I will let that on the side for now and might have a try to uploading a set of updated po later on to see how it goes [12:33] right [12:33] dpm: so if you just upload .po files it doesn't use the previous pot by default? that'd make a nice addition [12:33] because then we coudl even write a script which does git pull, bundle po/, and upload it to LP [12:34] lunch, bbl [12:34] well apparently rosetta is getting that feature of importing from upstream git [12:34] pitti, currently, you can only do that for individual PO files. When you upload a tarball, it needs to have a POT files to attach the PO files to [12:35] dpm, so can I do upload 5 po files rather than a tarball? [12:35] dpm, in which case do I need a pot as well? [12:35] dpm, and would translations still count as upstream ones? [12:37] individual po files sounds fine, as long as we script it [12:37] seb128, in general only translation team members can do that, but perhaps maintainers can do it as well. In order to mark them as upstream ones, you'd simply have to tick the "Imported translation" checkbox. We can try. Can you upload files there? -> [12:37] https://translations.edge.launchpad.net/ubuntu/lucid/+source/gnome-panel/+pots/gnome-panel-2.0/ca/+upload [12:37] dpm, pitti: ok, I think I've all the info, will figure what to do later on, thanks [12:38] ok, great [12:38] seb128, ugh, my tomboy upload was rejected, but I have permissions on that package AFAICS [12:38] where can I check my per package permissions? [12:40] rodrigo_: AFAIK only with the LP API [12:40] geser, ok, but how? [12:41] rodrigo_: ./edit_acl.py query -p from ubuntu-archive-tools [12:41] what API calls I mean? [12:41] lp:~ubuntu-archive/ubuntu-archive-tools/trunk [12:41] ok [12:41] you can also -s , but I don't know if that only should groups [12:41] seb128, pitti, just for the sake of completeness, there's more info on how to do manual uploads here: https://wiki.ubuntu.com/UbuntuTranslationsCoordinators/Actions/LpTemplateAdministration#Manual%20template%20upload For the lack of an API, there is also the lp-translations-tools project to automate a bit the upload part. cjwatson uses it to upload the d-i translations, but in the current state the script needs a bit of tweaking to log into LP. Ok, I [12:41] shut up and get something to eat now [12:41] because you're not for tomboy at least [12:42] dpm, thanks ;-) enjoy your lunch [12:42] chrisccoulson, hey! I have been testing some of the cases in Karmic, and some failed. Have a look when you can, and let me know any information you might need [12:43] ugh, it just shows permissions for couchdb-glib and evolution-couchdb [12:43] I'll talk to persia [12:43] hi ara - the ctxextensions issue is because i removed the updated version from the PPA [12:43] i will reupload a working version later [12:43] rodrigo_, I will sponsor the upload for this one [12:43] seb128, yes, please [12:43] chrisccoulson, OK, I will retest then [12:44] ara - i don't think that diggler worked before did it? [12:44] chrisccoulson, I am afraid I didn't try [12:44] ara, IIRC, diggler wasn't detected before, so I removed the update from the PPA [12:45] chrisccoulson, OK [12:45] ara - the same also for itsalltext [12:46] rodrigo_, or, merged and uploaded [12:48] rodrigo_, g-s-d the version should be -0ubuntu1 not -1ubuntu1, I'm fixing that before uploading [12:49] seb128, ah, sorry [12:49] rodrigo_: did we (the DMB) formal finish your application? I checked the minutes and two items got deferred to e-mail votes. But I don't remember if we did an followup :( [12:49] rodrigo_, no worry [12:50] geser, persia told me at UDS that I got the permissions, so I guess it was finalized [12:50] geser, I assumed it was done, but this is the 1st upload of the other packages that I do [12:53] rodrigo_: then talk to cjwatson as the DMB can decide on PPU but only TB members can implement them [12:54] geser, ok [13:02] well, the archive admin tool seems to tell that you should have the right [13:03] maybe somes dots are badly connected :) [13:04] evolution express backported to 2.30.2 \o/ [13:04] nice [13:06] it seems so… fast :) (non blocking ui) [13:07] didrocks, what do you mean non blocking ui? [13:07] ara - ok, ctxextensions is back in the PPA again. i will look at your other issues shortly [13:08] seb128: you know, sometime (and especially on slow machine), when evolution is scanning for your ldap account name for instance, you got a slowdown and you can't do nothing else in evolution. That doesn't happen in express mode [13:09] i've noticed that with evolution ;) [13:09] with the combination of evolution and U1, i can't do anything at all on my laptop for 5 minutes after logging on [13:09] didrocks, dunno about this one but I though issues were due to eds api being synchronous so I'm wondering how express can be different [13:11] seb128: that's a good question, it doesn't happen there (and no eds change)… but I didn't tried evo 2.30 yet on a netbook before express, so maybe it's in 2.30 as well [13:11] didrocks, that would make sense [13:12] seb128: I remember to have read about it somewhere, not sure if it was related to express or not [13:21] chrisccoulson: if you could have a quick look over the debdiff of https://edge.launchpad.net/~mvo/+archive/ppa/+packages?field.name_filter=flash&field.status_filter=published&field.series_filter= that would be nice. this should be enough to make the flash upgrade not fail === MacSlow|lunch is now known as MacSlow [13:57] mvo - thanks, i will take a look at that shortly [13:57] didrocks, seb: (fyi) since i moved to maverick, evo takes a long while to appear (often more than a minute). in lucid, the UI used to appear quickly, followed by a quite long sync of my folders. now, it takes a while just to see the UI, and even more time to update the folders. [13:58] fta2: more than a minute? I dont reproduce that here. evo happens in some seconds and then sync… [13:58] when did you upgraded? did you have the same issue with 2.30.1? [13:59] (just uploaded 2.30.2 yesterday) [14:01] chrisccoulson: thanks, it looks good in my test so far, I will probably upload shortly (test upgrade is at 94%) [14:01] didrocks, several weeks ago [14:03] fta2: hum, and does 2.30.2 changed anything? [14:05] didrocks, will tell you that when i'm back at home [14:05] fta2: ok, keep me posted [14:09] msg seb128 hi [14:09] msg chrisccoulson hi [14:09] hi rickspencer3 [14:09] how are you today? [14:09] lol [14:09] did I forget a couple of slashes there? [14:09] i think so ;) [14:09] * rickspencer3 sips coffee [14:10] i'm on red bull today, it's far too warm for coffee ;) [14:10] chrisccoulson, anyway I was wondering if you were coming to the meeting that beuno scheduled that's in 50 minutes? [14:10] rickspencer3, yeah, i planned to [14:11] since he works in online services, he'll handle some of the search engine integration stuff going forward [14:11] so this should alleviate a bit of work for you [14:11] cool :) [14:12] hey rickspencer3 [14:12] hi seb128 [14:12] seb128, I can only make the first 30 minutes of the team meeting [14:12] which, btw, I haven't created the wiki for yet, etc... [14:12] :( [14:12] rickspencer3, ok, seems it's plenty of time to cover your part, then I can take over for work items tracking etc [14:12] thanks seb128 [14:13] np ;-) [14:13] I'll just want to talk about guadec and distro sprint [14:13] after I dig out from my email, I'll get the page set up [14:13] ok [14:14] seb128: ok to convert evolution-indicator to "merge-upstream" mode? [14:14] hey rickspencer3 (without msg ;)) [14:14] didrocks, your call since you maintain it [14:15] didrocks, but yes [14:15] msg didrocks I think seb128 is going crazy, can you help him? [14:15] dang it! [14:15] seb128: oh, I won evolution-indicator too? ;) [14:15] rickspencer3: heh :-) [14:15] lol [14:15] seb128: damn, I know I should have never looked at evo :-) [14:23] didrocks, can I talk you into doing a quickly session at developer week? [14:23] actually ... [14:23] * didrocks checks when devweek is [14:24] didrocks, I moved it to #quickly [15:29] seb128, sorry to surprise you with this ... [15:29] but we should have Alpha 3 work items set up by eod this Thursday [15:29] (in 2 days) [15:30] rickspencer3, why? don't those start after alpha2 is released? [15:30] seb128, it doesn't need to be final, right [15:30] so this would be one week before [15:31] we mostly have those defined already I think [15:31] I need to tell Jane, Mark, and the community about what we will focus on [15:31] we should readjust next week, but we should scrub our A3 work items this week [15:31] ok, will check what is missing [15:31] right now we have about 76 work items targeted for A3 [15:31] I guess didrocks needs to set some [15:32] but that will be too many [15:32] or it might be [15:32] we should only put in as many work items for A3 as we got done in A2 [15:32] seb128: I'm going to trade between alpha2 and alpha3 + add last minute packaging ones [15:32] didrocks, ok [15:33] so, everyone should only have as many work items in A3 as they think they will get done in A2 [15:33] rickspencer3, so around an hundred [15:33] it's the best approximatin [15:33] 100? [15:33] yes [15:33] seb128, sure, if that's what we get done [15:33]