[13:58] <seb128> hey
[13:59] <arges> hey
[14:00] <smoser> o/
[14:00]  * stgraber waves
[14:00] <skaet> o/
[14:00] <stgraber> #startmeeting Ubuntu 12.04.1 team meeting
[14:00] <meetingology> Meeting started Thu Jun 28 14:00:39 2012 UTC.  The chair is stgraber. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[14:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[14:01] <stgraber> NCommander, stokachu, jibel, jamespage: ping
[14:01] <stgraber> xnox: around by any chance?
[14:02] <stgraber> #topic Action items review
[14:02] <stgraber> arges to work on a 12.04.1 bug report, showing targeted bugs and information on status in development release, patches attached and branches linked
[14:02] <xnox> stgraber: yeap
[14:02] <arges> stgraber, i think the launchpad page is sufficient
[14:03] <arges> stgraber, i wrote a script for our team to see which bugs we have targeted via arsenal
[14:03] <stokachu> o/
[14:03]  * xnox o/
[14:04] <stgraber> arges: ok, I don't particularly like sorting/filtering bugs with Launchpad but it's true we don't have so many that it's not doable
[14:04] <arges> stgraber, i guess my other issue was not figuring out what exactly was needed
[14:06] <stgraber> arges: I was mostly interested in having a way of finding low hanging fruits, that's bug targeted to the point release, already fixed in the dev release or with patches/branches attached for dev+point-release
[14:06] <xnox> and or fixed in a linked debian bug...
[14:06]  * smoser mentions that jamespages is on holiday
[14:06] <arges> stgraber, ah. this makes more sense.   so in launchpad we can see the icons right? but it doesn't show us all the information
[14:07] <arges> just patch/branch
[14:07] <arges> stgraber, if this is still valuable, i will work on this and make sure I ask questions before the next meeting. ok?
[14:08] <stgraber> arges: right, it doesn't tell us whether it's fixed in the dev release (good indication that the patches are good)
[14:08] <stgraber> arges: sounds good
[14:08] <stgraber> xnox: linked Debian bug sounds good too
[14:08] <stgraber> xnox to liase with ballons, gema and jibel w.r.t. fs/storage testing
[14:09] <xnox> stgraber: blocked/postpone, pending UTAH development subscribed to the mailing list
[14:09] <stgraber> ok, will poke you again in a couple of weeks then ;)
[14:09] <stgraber> #topic Review of upcoming deadlines
[14:09] <stgraber> Not sure how relevant this topic actually is :)
[14:09] <stgraber> As far as I know we don't have any deadlines beside 12.04.1 itself. If you're aware of any upstream point release that needs to get in 12.04.1 and hasn't been released yet, now is the time to speak!
[14:11] <stgraber> moving on
[14:11] <stgraber> #topic Quick look through the current bug lists
[14:11] <stgraber> We're now up to 121 bugs targeted to 12.04.1.
[14:11] <stgraber> A quick scan through the list shows almost 50% of them having a branch or a patch attached.
[14:11] <stgraber> So please go through https://bugs.launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=49926 for packages your team is responsible for and review/upload these fixes!
[14:11] <stgraber> Out of these 121 bugs, 58 don't have an assignee. It'd be great if while reviewing the list, teams could assign these bugs to the team or to one of their team members.
[14:12] <seb128> (good part of that list is fix commited as well)
[14:13] <stgraber> right and that's pretty good to see :)
[14:14] <skaet> :)
[14:14] <stgraber> briefly went through pending-sru too, we don't seem to have a lot of old entries on there, so the verification work seems to be going quite well too
[14:15] <stgraber> most of the oldest entries are universe or are packages that we can't easily test at the moment (ubiquity being one of them)
[14:16] <stokachu> i got one that needs sponsorship
[14:16] <stokachu> bug #977964
[14:16] <seb128> stokachu, the libart-lgpl one?
[14:16] <xnox> i got two that need to be accepted
[14:17] <stokachu> seb128: ah yea
[14:17] <seb128> stokachu, I saw that earlier, I will sponsor it
[14:17] <stokachu> seb128: thanks :D
[14:17] <seb128> yw
[14:17] <stokachu> these next ones are ones on my todo list to get complete by next week
[14:18] <stokachu> bug #977952, bug #977947, bug #32860
[14:18] <seb128> I wanted to ask about the multiarch bugs progress ... but not sure, is there a "questions" part of the meeting I should wait for?
[14:18] <seb128> stokachu, it's about time we land the multiarch stuff, those need some testing so it's getting late
[14:18] <stgraber> there's a backlog of 30 packages in Unapproved at the moment, including xnox's packages. Hopefully that backlog will shrink post alpha-2 when people are a bit less busy releasing the alpha :)
[14:19] <stokachu> the main scope of my multiarch bugs to get complete is heavily influenced by third party needs
[14:19] <stokachu> but i am willing to work on others as well
[14:19] <xnox> stgraber: I don't mind the backlog, as long as they get approved and not kicked out.
[14:20] <seb128> I do mind the backlog, another issue I want to raise later ;-)
[14:20] <xnox> stgraber: i did test cases / bug template for all of mine, but I hope it will not be kicked out on the grounds of 'too hard to review'
[14:20] <seb128> the queue is stalling, 15 packages accept in a week is too low, it's impacting on our velocity...
[14:21] <xnox> stgraber: 2 packages, 8 and 1 SRU bugs respectfully
[14:21] <xnox> stgraber: 2 packages, 7 and 1 SRU bugs respectfully
[14:21] <stgraber> well, if you did the documentation and the diff is readable, it should be fine :)
[14:22] <stgraber> #topic Round table (status update from the various teams, what they're working on, where they need help, ...)
[14:23] <stgraber> will go in wiki order this time ;)
[14:23] <stgraber> didn't see NCommander being around, so will go directly with seb128
[14:23] <seb128> ok
[14:23] <seb128> great ;-)
[14:24] <seb128> so to be short
[14:24] <seb128> - desktop SRUs are going well (mostly)
[14:24] <seb128> - we got a round of compiz,libunity,bamf SRU this week (still in proposed)
[14:24] <seb128> - we should have an unity SRU in the next 2 weeks and probably another one toward the end of july
[14:24] <seb128> some issues,concerns:
[14:25] <seb128> - the multiarch changes are getting late, I saw very little activity on them
[14:25] <seb128> that's the sort of things we want to give some testing time to
[14:25] <seb128> - the SRU team is still lagging behind
[14:25] <seb128> we have a queue near 30 items, some stuff takes 2 week to get reviewed when they are trivial
[14:26] <seb128> that's impacting on velocity and blocking us to follow up with next rounds of fixes
[14:26] <seb128> ..
[14:26]  * xnox has no clue who is next
[14:27] <stgraber> me :)
[14:27] <seb128> oh
[14:27] <seb128> another issue raised:
[14:28] <seb128> - users feedback points that the number of whoopsie dialogs displayed makes the product looks buggy over what it is (often those are triggered for harmless issues in services that get respawned for example)
[14:29] <seb128> some people suggested we should consider turning off whoopsie with .1
[14:29] <seb128> ..
[14:29] <seb128> I'm done this time
[14:29] <seb128> not sure if we do questions or just keeps going and discuss stuff at the end ;-)
[14:29] <stgraber> skaet: I think you mentioned there was at least one SRU related meeting fairly recently, that's including re-staffing the SRU team right? (I seem to remember bdmurray and ScottK joining recently)
[14:29] <skaet> stgraber, yes,  there's a rotation been decided on for the SRU team
[14:30] <seb128> skaet, is the rotation schedule displayed somewhere?
[14:30] <stgraber> we can take questions as we go, so people don't have to keep lists ;)
[14:30] <seb128> so we can ping people on duty ;-)
[14:30] <seb128> displayed->published
[14:30] <skaet> seb128,  its in a google doc,  but I'll make up a page this afternoon after A2 is out
[14:30] <seb128> skaet, thanks
[14:30]  * skaet understands its needed.
[14:31] <seb128> it's very frustrating to see so little movement on SRUs reviews :-(
[14:31] <skaet> seb128,  doesn't quite solve the validation problem though.   So we need to figure that out.
[14:31] <seb128> well stgraber stated earlier that we don't have a validation issue so far?
[14:31] <seb128> ie by validation you mean verifying items in the queue
[14:32] <stgraber> right, verification is going quite well, I usually spend half a day a week verifying stuff and looks like the other members have been doing that too
[14:32] <skaet> we don't?
[14:32] <seb128> I didn't see anything concerned backlog or things staying for too long
[14:32] <skaet> ok.
[14:32] <seb128> skaet, well at least from the desktop side everything get validated before the week delay so far
[14:32] <skaet> seb128,  ok.   Will get that schedule of folks to ping posted.   See if that sorts it.
[14:33] <seb128> skaet, thanks
[14:33] <stgraber> skaet: most old entries are universe SRUs pre-testcase-era that I can't easily verify. I can't remember the reason for the others, but usually I try to verify > 6days old entries once a week at least
[14:33] <seb128> stokachu, reading your comment earlier the multiarch changes are being worked now right?
[14:33] <seb128> stokachu, i.e we should see progress on there in the next week?
[14:33] <stokachu> seb128: correct
[14:34] <stokachu> ive got sru's written for the ones i know about
[14:34] <stokachu> just need to finish the rest
[14:34] <seb128> ok
[14:34] <skaet> thank stgraber,  maybe we should brainstorm with ScottK and see if he has some ideas on how to make progress on those.
[14:35] <stgraber> skaet: I'm also wondering whether we should expire SRUs after a while, but that's a question for the SRU team really
[14:35] <stgraber> anyway, moving on a bit, feel free to continue pasting questions ;)
[14:35] <stgraber> stgraber:
[14:35] <skaet> stgraber, ok,  I'll carry it forward to them.
[14:36] <stgraber> I haven't been doing a whole lot of 12.04.1 stuff lately but did spend a day or so doing sru verification and I'm preparing a batch of network related SRUs
[14:36] <stgraber> there isn't anything critical in there but these are fixes I'm going to push to quantal so might as well SRU
[14:37] <stgraber> bug 1004775 is probably one for seb128 as it's technically a desktop package, but I'm affected and happy to help test any fix for it
[14:37] <xnox> for me the mdadm & e2fsprogs SRUs should get a much validation as possible & as long in -proposed as possible
[14:37] <xnox> as they are complex packages
[14:37] <xnox> and the deadline for 12.04.1 is fast approaching
[14:38] <seb128> stgraber, I will see if cyphermox can have a look
[14:38] <stokachu> roughly a month right?
[14:38] <stgraber> it's affecting everyone with an IPv6 network using NetworkManager in Automatic mode (default). It's not preventing people from working but it's spamming the syslog, seems to be spamming the routing table too and causes some DNS queries to fail
[14:38] <cyphermox> I'm working on it already
[14:39] <cyphermox> the routing table, I'm not sure it will change anything there.
[14:39] <ScottK> FWIW, the KDE version for 12.04.1 is in proposed for testing now.
[14:39] <seb128> cyphermox, thanks
[14:39] <stgraber> cyphermox: cool, thanks. The dnsmasq is really the annoying one, the routing table caching is weird but doesn't seem harmful
[14:39] <cyphermox> stgraber: right.
[14:40] <stgraber> ScottK: good to hear, no problem so far with verification?
[14:40] <ScottK> Not so far.  I'm running it here.
[14:40] <stgraber> cool
[14:40] <stgraber> stokachu:
[14:41] <stokachu> multiarch is the name of the game, continueing to get those bugs completed and sponsored
[14:41] <stokachu> ...
[14:41] <stgraber> arges:
[14:42] <arges> worked on 12.04.1 bugs, worked on milestone scripts for our team
[14:42] <arges> ..
[14:43] <stgraber> jibel:
[14:43] <jibel> automated testing reported broken oem installation
[14:44] <jibel> that usually occurs when the version of ubiquity on the CD and in the squashfs are different
[14:44] <jibel> will file a bug report
[14:45] <jibel> post-upgrade tests fail the obosolete config file check for everything bug oenric server while they usually pass
[14:45] <stgraber> oh, right, I have an AOB on that but might as well mention it now :)
[14:45] <jibel> I'll investigate next week this it started after we upgraded the auto-upgrader to python3
[14:45] <jibel> ..
[14:45] <jibel> s/bug oenric/but oneiric/
[14:45] <stgraber> cjwatson has been working on enabling -proposed for all precise dailies
[14:46] <stgraber> that's done for alternates but not working for live images
[14:46] <cjwatson> Yeah, sorry about that, it came down to something I thought about a year ago and then forgot
[14:46] <stgraber> which explain the out-of-sync issue you mentioned earlier
[14:46] <cjwatson> jibel: Indeed, there's no need for a bug report for the broken OEM installation in this case
[14:47] <jibel> cjwatson, ok, noted
[14:47] <cjwatson> If it persists next week I'd like to know
[14:47] <stgraber> jibel: I can't think of a reason why the python3 port would have broken th conffile check but let me know if you need some help there
[14:48] <stgraber> skaet:
[14:48] <jibel> stgraber, me neither but I don't like coincidences
[14:48] <skaet> working through bugs and milestoning some that should be considered for 12.04.1
[14:48] <skaet> from some of the ones that have come up from quantal mostly.
[14:48] <skaet> discussions about 12.04.2 schedules have started up.
[14:49] <skaet> but mostly working on quantal at the moment...
[14:49] <skaet> ;)
[14:49] <skaet> ..
[14:50] <stgraber> smoser:
[14:50] <smoser> - I'm not as current on our progress here as I need to be.  we clearly have a lot more bugs on the lists than other teams do.  I'll spend some time catching up
[14:50] <smoser>  with the teams and making sure we're getting some things done.
[14:50] <smoser>  - we did get a nova update into -proposed this week
[14:51] <smoser> i'm somewhat concerned that our list is so long.
[14:51] <smoser> but thats all. i'll poke around later today and we'll have more info next time.
[14:52] <stgraber> #topic AOB
[14:52] <stgraber> anything else people would like to mention/ask?
[14:53] <stgraber> doesn't look like it :)
[14:53] <skaet> :)
[14:53] <stgraber> well, thanks everyone, talk to you in two weeks then!
[14:54] <stokachu> thanks!
[14:54] <jibel> thanks stgraber
[14:54] <stgraber> #endmeeting
[14:54] <meetingology> Meeting ended Thu Jun 28 14:54:21 2012 UTC.
[14:54] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-28-14.00.moin.txt
[14:54] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-28-14.00.html
[14:54] <skaet> thanks stgraber
[14:54] <seb128> thanks
[14:55] <seb128> stgraber, skaet: nobody was interested to discuss the whoopsie on or off for .1 I guess then?
[14:56] <stgraber> seb128: oops, forgot about that one... did you discuss that with ev/pitti already? they're the most likely to have a strong opinion on that.
[14:57] <smoser> h.m.
[14:57] <smoser> stgraber, i have a bit of a feeling on it.
[14:58] <smoser> well..i'll look a bit beforr i comment and crate a more informed opinion.
[14:58] <smoser> the concern i have is just memory use in smaller server install (or vm)
[15:00] <Daviey> smoser: Well, the initial results from server have been null.
[15:00] <Daviey> smoser: As in, i don't think anyone has yet reported from an X-less box.. So it really is just a resource waste, until there is better exposure
[15:12] <seb128> stgraber, ev has a strong opinion on "we should fix the issues rather than turn it off"
[15:12] <seb128> in practice it's showing up badly on precise and we don't make enough progress with the resources we have to get in a good position soon on that front
[15:12] <seb128> so I think we should consider turning it of for .1
[16:15] <dholbach> ok, who's here for the MOTU meeting?
[16:16]  * coolbhavi waves
[16:17] <dholbach> coolbhavi, it looks like it's only the two of us
[16:17] <dholbach> nobody sent a reminder to the list I guess
[16:17] <dholbach> maybe we should just meet in 2 weeks instead with proper reminder beforehand?
[16:18] <coolbhavi> dholbach, yes right after meeting along with the minutes will help I think
[16:19] <dholbach> it'd be great if somebody (other than me) could do this :)
[16:19] <dholbach> I was just too busy to take care of this time
[16:19] <coolbhavi> dholbach, I can from next time if nobody beats me to it :)
[16:19] <dholbach> ok cool :)
[16:20] <dholbach> I don't have any updates for the meeting, but I just removed the "meeting times" bit from the agenda for next time
[16:20] <dholbach> it seems like there was little interest in moving it
[16:21] <coolbhavi> hmm I thought of freezing on motu school timings feedback so that we could have kick started motu school asap
[16:21]  * tumbleweed waves, but has to run
[16:21] <dholbach> ok, well then maybe we better clear out of the room and I'll just go update the agenda page with the proper date for next time
[16:21] <dholbach> coolbhavi, sounds good
[16:21] <coolbhavi> sure
[16:22] <coolbhavi> hey tumbleweed
[16:22] <dholbach> excellent - that was a very quick meeting then :)
[16:22] <coolbhavi> :)
[16:25] <coolbhavi> dholbach, anyways ll mail the list about proposed dates and times of MOTU school tomorrow and take discussion on list
[16:26] <dholbach> perfect, thanks a lot coolbhavi
[16:26] <coolbhavi> no mention dholbach
[16:32] <vibhav> .window 9
[18:00] <jono> alrighty folks
[18:00] <jono> #startmeeting
[18:00] <meetingology> Meeting started Thu Jun 28 18:00:20 2012 UTC.  The chair is jono. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:00] <jono> hey folks, and welcome to the very first Ubuntu Accomplishments meeting :-)
[18:00] <jono> who is here for the meeting?
[18:00] <notgary> I am o/
[18:01]  * cielak is here
[18:01] <highvoltage> "You've unlocked an accomplishment! Attending your first Ubuntu Accomplishments meeting!"
[18:01] <jono> highvoltage, LOL!
[18:01] <jono> well thanks folks for joining us
[18:01] <jono> there is not really a fixed agenda here, but I have a few topics I want to cover:
[18:01] <philipballew> 0/
[18:02] <jono>  * getting more accomplishments written
[18:02] <jono>  * getting more translation involvement
[18:02] <jono>  * testing
[18:02] <jono> does anyone else have any topics?
[18:03] <jono> ok then :-)
[18:03] <jono> maybe we can cover translations first
[18:03] <jono> so we have four projects -daemon -viewer -community-accomplishments and -desktop-accomplishments
[18:03] <jono> and then also the web gallery
[18:04] <cielak> I remember it was suggested that we bound some official translation groups to our project
[18:04] <jono> right now our translation coverage in the desktop app and daemon is pretty good
[18:04] <jono> but the accomplishments themselves is limited
[18:04] <jono> cielak, indeed
[18:04] <cielak> especially desktop ones, I wonder if they are available in more than 2 langs
[18:04] <hallino1> Me :)
[18:04] <jono> any thoughts on how we get more translators involved?
[18:04] <jono> it would be great if we had a translations leader who can help grow this community
[18:05] <jono> cielak, yeah
[18:05] <jono> is anyone interested in helping out with this?
[18:05] <cielak> I wonder whether we can't simply ask one of these translator organisations that translate everything in LP
[18:06] <cielak> like the Launchpad Translators
[18:06] <jono> cielak, like the Ubuntu translations groups?
[18:06] <jono> so maybe the next step is reaching out there
[18:06] <jono> I know some translators express concern about open permissions too
[18:06] <jono> so we might need to resolve that
[18:07] <cielak> we've had recently a case of translation mistake of griefing that coused a critical bug in viewer
[18:07] <jono> right
[18:07] <jono> ok, I will reach out to the translations groups to see if they can help us
[18:08] <jono> if anyone is passionate about this, do let us know
[18:08] <jono> we could definitely use some help here :-)
[18:08]  * gepatino is here
[18:08] <jono> hey gepatino, just the person
[18:08] <jono> gepatino, do you think it would be viable to provide a link in the web viewer so people can be linked to where they can translate opportunities?
[18:09] <jono> this might be a good way of getting more folks involved
[18:09] <notgary> How about writing some translation accomplishments -"You have make your first translation", "You have made 10 translations", "You have made 20 translations", etc. I have actually been thinking it would be cool to track Launchpad activity for acheivements, such as "You have merge X patches into Ubuntu". Perhaps this could be done for translations
[18:09] <jono> notgary, we would love to have that, but translations doesn't have an API in LP afaik
[18:09] <cielak> notgary: the problem with translations is that Launchpad API does not expose access to them
[18:10] <gepatino> jono, adding a link shouldn't be an issue
[18:10] <gepatino> should we check some rules? redirect so some specific language, etc?
[18:10] <jono> gepatino, cool - we would need to figure out how to generate a link to the correct strings, but we can look into that
[18:10] <cielak> notgary: and the problem with number-based accomplishments is that they often encourage pointless traffic
[18:10] <jono> gepatino, I am not sure of the details
[18:11] <jono> ok, so lets move on
[18:11] <jono> next I wanted to discuss testing
[18:11] <jono> cielak and I have been discussing this recently
[18:11] <gepatino> i was catching up... I meant it would be a problem to add link, thinking in linking to launchpad translations
[18:11] <jono> our codebase is growing, and so are our users, and thus the potential for bugs could increase
[18:11] <gepatino> then I've read about the translation groups not being open...
[18:11] <jono> gepatino, cool
[18:12] <jono> gepatino, well, open in terms of whether contributions are reviewed
[18:12] <jono> I think we should get advice from our translation community about how the translations are best governed
[18:12] <gepatino> ok
[18:12]  * cielak agrees
[18:12] <jono> so in terms of testing
[18:13] <jono> I would like to build unit test suites for all of our projects
[18:13] <jono> I know the web team are already working on this
[18:13] <jono> and I am planning on putting in place unit tests for the daemon
[18:13] <jono> I suspect the viewer is important but less critical than the daemon
[18:13] <jono> if the daemon gets it wrong, all viewers are screwed :-)
[18:14] <jono> hey janosTheHun
[18:14] <janosTheHun> hey jono !
[18:14] <cielak> viewer is just a bunch of GTK+ hacks, the real code is in the daemon ;)
[18:14] <jono> cielak, indeed :-)
[18:14] <jono> the other part of the testing which I wanted to discuss was how we test the server
[18:14] <jono> again, cielak and I discussed this a little earlier
[18:14]  * janosTheHun here now, but won't be long
[18:15] <jono> so while we have seen good traffic on the validation server, which suggests things are generally working well, there are sometimes issues, and these could be either U1 syncing delays or bugs in the server
[18:15] <cielak> janosTheHun: semi-final? :)
[18:15] <janosTheHun> cielak: yup :)
[18:15] <cielak> or generaly any case causing trouble with the validation process
[18:15] <cielak> there can be many more factors
[18:16] <jono> in terms of the U1 lag, I have a solution which I think could work - I will set up a U1 user who will generate some files and put the timestamp inside the file - when the file is synced we can compare the timestamps of the server to the file and get an idea of lag
[18:16] <jono> I think having visibility on U1 lag will help us in tracking down some issues
[18:16] <jono> I would also like the server testing to dynamically create and register shares and check on the success of that too
[18:16] <cielak> such file would be sent like each 10 minutes, or daily?
[18:16] <jono> cielak, I am thinking every 10 mins or so
[18:17] <jono> and then plot this into a a graph
[18:17] <jono> so we can compare when a bug occurs to the lag time
[18:17] <cielak> right
[18:17] <jono> bug X happened on 5th June, and oh look...U1 was lagging :-)
[18:17] <jono> in terms of ensuring the server is actually validating trophies correctly, I think the first step is probably unit tests
[18:18] <cielak> well, most our problems with validation server is not just lag, but no signature at all, yet that's a good idea nevertheless
[18:18] <jono> one challenge we have now is that if a user types in the wrong identification it will constantly fail
[18:18] <jono> cielak, right
[18:18] <jono> so a trophy not getting signed means either:
[18:19] <jono>  (1) the user is screwing around with .trophy files
[18:19] <jono>  (2) there is a bug in the code that uploads a trophy
[18:19] <cielak> 1) is unlike, if someone intentionally messes things up, they won't report a bug
[18:19] <jono> (3) the user entered extra-information that generated the .trophy and then changed it after it was synced, s when the server validates it the extra-info doesnt work
[18:20] <jono> yeah I think few people, if any are faking trophies
[18:20] <gepatino> (4) there is a bug in the code that validates the trophy
[18:20] <cielak> 3) is not valid, daemon will regenerate the trophy with new extrainfo, if it wasn't yet signed
[18:21] <jono> gepatino, oops, yes
[18:21] <philipballew> faking does not give you that good feeling that earning it does.
[18:21] <jono> cielak, right, but imagine this: the user adds e-a, it gets approved and generates a .trophy, that gets uploaded, they then change their e-i and U1 doesnt sync it yet
[18:21] <gepatino> so, the real programming bugs seems to be (2) and (4), am I right?
[18:21] <jono> philipballew, indeed
[18:22] <jono> gepatino, yup
[18:22] <cielak> jono: this happens just once, the next time the .trophy is sent it will be correct, and the server will sign it then
[18:22] <cielak> or will it not?
[18:22] <jono> cielak, agreed, I just mean that it is not inconceivable that there could be a mismatch
[18:23] <cielak> if I modify my .trophy and send a new version, will the server re-sign it?
[18:23] <jono> I do think we have some bugs in there somewhere
[18:23] <jono> cielak, if you already have the .asc, the server wont resign
[18:23] <jono> if you don't have the .asc it will try to sign
[18:23] <cielak> each time I upload a new version?
[18:23] <cielak> or just then the file is created?
[18:24] <jono> cielak, each time the file is updated
[18:24] <cielak> okay, that's correct then
[18:24] <jono> if you modify a file in U1 that is in a subscribed folder, it gets synced
[18:24] <cielak> so 3) is not really a problematic case
[18:25] <jono> cielak, right, I think the mismatch scenario is pretty rare anyway
[18:26] <cielak> indeed
[18:26] <jono> it will result in a logged failure on the server, but then just resolve itself
[18:26] <cielak> we better seek for bugs in the code :)
[18:26] <jono> what we need to identify is what is the source of the failures
[18:26] <jono> cielak, totally agree
[18:26] <jono> cielak, we just need to do more testing and find failures
[18:26] <janosTheHun> i recommend writing unit tests around this issue, and try to cover all the corner cases you can think of
[18:26] <jono> right now I think there is a lot we can do to get better visibility on failures
[18:26] <jono> janosTheHun, agreed
[18:27] <jono> janosTheHun, I was saying before you joined that I would like us to have unit tests for all of our projects
[18:27] <jono> and before we land code we can run the test suites
[18:28] <janosTheHun> jono: yup, good idea
[18:28] <cielak> we might also think to include some easy access to debug data
[18:29] <cielak> the daemon log file is working great
[18:29] <jono> cielak, what kind of debug data
[18:29] <cielak> for bug reports it's really useful
[18:29] <cielak> but there are other things we ask all users that report a bug
[18:29] <jono> cielak, I agree we might want to build some better debug tools into our software
[18:30] <cielak> like the share data, whether it got accepted, what files are in trophies directory
[18:30] <jono> one thing that could be useful for example is an easy way to see if a share is active
[18:30] <jono> yeah
[18:30] <jono> cielak, maybe we could add this to battery?
[18:30] <jono> add a switch to summarize system info
[18:30] <jono> accomplishments-battery -i for example
[18:30] <cielak> you have recently implemented support for getting our share data from the u1syncdaemon, what if we simply printed the result to the daemon log?
[18:30] <jono> and it displays the share status and other reporting
[18:31] <cielak> I'd integrate it with either daemon or viewer, so that when one reports a bug, we do not need to ask him to install the battery
[18:31] <jono> cielak, we could do that
[18:31] <jono> makes sense
[18:31] <jono> I am happy to take a look into that
[18:31] <jono> should be a simple addition :-)
[18:31] <cielak> actually, there is some bug in determining share ID, found it recently
[18:32] <jono> cielak, oh?
[18:32] <cielak> will need to take a closer look, but it makes me unable to publish my trophies :) (the shareid in URL does not match my actual shareid)
[18:32] <jono> cielak, I think I know this bug
[18:32] <jono> this might be because you have two active shares
[18:32] <cielak> nope, just one
[18:32] <jono> really?
[18:32] <jono> odd
[18:33] <cielak> yeah, will report it & investigate
[18:33] <jono> cool
[18:33] <jono> speaking of which....
[18:33] <jono> I have another suggestion
[18:33] <jono> I would like to suggest we have two log files
[18:33] <jono> daemon.log
[18:33] <jono> and scriptrunner.log
[18:33] <jono> the daemon is getting spammed with all the checks for accomplishments
[18:33] <cielak> aaah, that's wise
[18:33] <jono> which makes it difficult to read
[18:33] <janosTheHun> is there a wiki page about running the unit tests in the daemon project?
[18:33] <jono> janosTheHun, not yet, they don't exist
[18:34] <jono> janosTheHun, we have an original set of tests that hasnt been touched since January
[18:34] <jono> I need to go in and update them
[18:34] <jono> when I get a few working we can work together to build out full coverage
[18:34] <jono> cielak, would you be happy to split the daemon log into the two files?
[18:35] <jono> we may even want to have a log file standard info such as the share, share id, if it is active, trophydir etc
[18:35] <jono> so these daemon logs:
[18:35] <jono>  * daemon.log - general run time daemon info
[18:35] <jono>  * scriptrunner.log - log of when accomplishments are checked
[18:36] <jono>  * environment.log - a list of settings in the environment (e.g. share id, name, trophy dir, collections installed etc)
[18:36] <cielak> well, daemon.log will contain very little information, we might merge environment.log into it
[18:37] <jono> cielak, right, I was just thinking you would need to hunt it our in daemon.log
[18:37] <jono> whereas environment.log can just summarize
[18:37] <jono> I am happy with whatever you prefer though
[18:37] <cielak> maybe I'll try both, and compare which one makes more sense
[18:38] <cielak> we can have several instances of some 'logging' object, that would write to a single file
[18:38] <jono> cielak, awesome :-)
[18:38] <jono> indeed
[18:38] <jono> this will give us good visibility when people have issues
[18:38] <jono> cielak, we may want to consider this as a push into 2.1
[18:38] <jono> depending on how invasive it is
[18:38] <cielak> by the way: we have not created separate series for 0.2
[18:39] <cielak> thus we cannot separate 0.3 additions from 0.2.1 ones
[18:39] <jono> cielak, oops
[18:39] <jono> I will do that
[18:40] <jono> I will create the series, but we should probably only push critical fixes to 0.2.x
[18:40] <jono> so lets maybe do this in 0.3
[18:40] <jono> I will create the series today anyway
[18:40] <cielak> yeah, will be more time to test all that
[18:40] <janosTheHun> ok i guys i have to go, will try to do something for the daemon and then ping you
[18:40] <jono> cool
[18:40] <jono> laters janosTheHun! :-)
[18:40] <jono> thanks!
[18:40] <cielak> thanks janosTheHun, see you!
[18:41] <jono> so anything more to discuss on testing?
[18:42]  * cielak just pushed a tiny fix that significantly cleans up demon's log ;-)
[18:42] <jono> cielak, wow, you are fast, buddy :-)
[18:42] <jono> ok, so the final topic I wanted to discuss was growing our community of accomplishments writers
[18:42] <jono> I am a little behind on this
[18:43] <jono> I am planning on putting together documentation and a video for how to get people involved
[18:43] <cielak> it may be worth reminding that we have lots of forum accomplishments waiting
[18:43] <jono> but so far I have been focused on a few other things such as the branches
[18:43] <jono> cielak, oh we should look into that
[18:43] <cielak> and s-fox will be surely interested in developing them, but Canonical did not reply for some longer time
[18:44] <jono> yeah Canonical IS has not responded yet since his last email
[18:44] <jono> I will see if I can ping them to respond
[18:44] <jono> I also need to update the docs as battery now checks for missing fields in .accomplishment files
[18:44] <cielak> might be worth it, I can't imagine 0.3 release without forum accoms!
[18:44] <jono> indeed :-)
[18:44] <cielak> there is one more problem with the docs
[18:44] <jono> oh?
[18:45] <cielak> someone had problems with following the guide recently
[18:45] <cielak> the problem is with the order of chapters
[18:45] <cielak> I guess battery information is too soon
[18:45] <cielak> it assumes one has already installed the collection, that is working on a bazaar branch etc
[18:46] <jono> ahhh
[18:46] <cielak> so basically it requires knowledge from upcoming chapters
[18:46] <jono> we should ask people to file bugs in ubuntu-accomplishments for docs related issues
[18:46] <jono> cielak, could you ask that person to file a bug?
[18:46]  * cielak wanted to re-read the whole guide to determine causes, but hadn't yet time
[18:46] <jono> good idea
[18:47] <cielak> jono: sure, will try to
[18:47] <jono> and as we get more contributors involved it will help us spot other issues
[18:47] <jono> ok cool
[18:47] <jono> well I have covered everything I wanted to discuss today
[18:47] <jono> anything else?
[18:47] <cielak> wasn't it philipballew?
[18:48] <cielak> philipballew: are you still with us? ;-)
[18:48] <philipballew> yes!
[18:48] <cielak> awesome! would you mind reporting a bug in ubuntu-accomplishments concerning the troubles you had with following the guide on creating accomplishments?
[18:49] <philipballew> Yes. I will.
[18:49] <cielak> great thanks!
[18:49] <jono> ok, I guess we can wrap
[18:49] <cielak> maybe someone lurking has any questions concerning accomplishments?
[18:49] <jono> thanks folks for joining our first meeting!
[18:50] <jono> yeah, any questions?
[18:50] <jono> and remember that we live in #ubuntu-accomplishments
[18:50] <gepatino> is there any roadmap for web gallery to 0.3?
[18:50] <gepatino> or so far only the specs in the wiki?
[18:50] <philipballew> I am considering a simple video tutorial on making some for people who are not good at reading and understanding as they would be in they could see.
[18:51] <jono> gepatino, just the wiki right now
[18:51] <jono> but part of it is the Mobile spec
[18:51] <jono> did you see that gepatino?
[18:51] <jono> https://wiki.ubuntu.com/Accomplishments/Specs/Mobile
[18:51] <jono> this is basically a stylesheet for the web gallery
[18:51] <jono> philipballew, that would be great
[18:52] <jono> my main advice is ensure that you have written a few accomplishments first before you do a tutorial
[18:52] <jono> someone else did a tutorial and they had not written an accomplishment and it wasnt so good
[18:52] <gepatino> i've read that, jono, thanks
[18:52] <jono> gepatino, cool
[18:53] <cielak> and of course such new accomplishments are very welcome! :)
[18:53] <gepatino> and finally, is there any release date for the web gallery? we are progressing but there are a lot of things to fix, like page layouts, check url schemas, etc
[18:53] <jono> gepatino, release date for 0.3 is Sep 5th
[18:54] <jono> so if we could shoot for then, that would be grea
[18:54]  * cielak has to remember it, hehe
[18:54] <jono> it would be cool to have it in place earlier so we can get some further testing
[18:54] <gepatino> sure, it would be nice to have one or two weeks before
[18:54] <cielak> hopefully we'll get trophies.ubuntu.com :)
[18:55] <jono> indeed :-)
[18:55] <jono> alright, lets wrap
[18:55] <jono> thanks, folks!
[18:55] <jono> #endmeeting
[18:55] <meetingology> Meeting ended Thu Jun 28 18:55:26 2012 UTC.
[18:55] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-28-18.00.moin.txt
[18:55] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-06-28-18.00.html
[18:55] <cielak> thanks everyone, thanks jono!
[18:57] <jono> :-)
[18:59] <gepatino> see you guys