Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate

#olpc-meeting, 2011-05-23

Index | Today     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
14:04 meeting Meeting started Mon May 23 14:04:13 2011 UTC. The chair is Cerlyn. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04 Useful Commands: #action #agreed #help #info #idea #link #topic #endmeeting
14:04 Cerlyn #topic 11.2.0 Bug Triage
14:04 #chairs dsd_ erikos
14:05 (I don't know if it's listening to half the commands; but :)
14:05 #meetingtopic 11.2.0 Bug Triage
14:06 dsd_ ok, so where do we start?
14:06 what are we going to do exactly in this meetings? take the last weeks worth of bugs and decide if they are 11.2.0, 11.3.0, future release, that type of thing?
14:07 homunq has quit IRC
14:07 erikos dsd_, yeah, I think so
14:07 Cerlyn #chair dsd_ erikos
14:07 meeting Current chairs: Cerlyn dsd_ erikos
14:08 erikos dsd_, I wonder how we want to approach it though bug by bug or assign a split them up
14:08 dsd_, and the triager can ask here if in doubt
14:08 martinlanghoff <martinlanghoff!~martin@mail.globisgroup.com> has joined #olpc-meeting
14:08 Cerlyn Or in this case, we need to figure out what we really need to do for this release, as no triage meetings have been held prior to this date
14:08 dsd_ on a general basis, i'd say go bug by bug
14:09 but yeah, as cerlyn just said, this meeting may be a bit different as its the first one
14:09 martinlanghoff I'm late - was at olpc-triage wondering why it was so quiet :-)
14:09 dsd_ i was just thinking that defining the general process would help us figure out what needs to be done specially for the first one
14:09 homunq <homunq!~chema@187.143.153.84> has joined #olpc-meeting
14:10 martinlanghoff we had a process last round
14:10 it worked
14:11 dsd_ ok, can someone explain it for me?
14:11 martinlanghoff of course, first meeting is different, bugs probably aren't as organized yet as we had them when we were "in the process" last time
14:11 my memory is fuzzy, but IIRC...
14:11 erikos has as well the fuzzy memory
14:12 martinlanghoff - we spent some time initially making sure the potentially interesting bugs were tagged correctly
14:12 2 - then every week we'd go through the list in either order of priority
14:12 or by "status"
14:13 attention wanes after ~40 minutes, so I strongly prefer priority order
14:13 or looking at statuses that need complex thinking first
14:13 dsd_ ok
14:14 erikos martinlanghoff, yeah, I think that works when we are on a sane ground
14:14 dsd_ what about bugs that had arrived in the week before the meeting and not been tagged or categorised?
14:14 erikos martinlanghoff, so, yes - sounds like a good plan
14:14 martinlanghoff my feeling is that last time we did#1 above "all in sync" over irc and it was painful
14:14 I think a first pass at #1 can be done -- even as part of this meeting -- in parallel
14:15 as we all know the process and we have our criteria reasonably in sync
14:15 erikos martinlanghoff, yes, I think as well that the initial round should be done in parallel
14:15 martinlanghoff interesting bugs *will* be reviewed by the whole group many times over the process, so any deviation or error made today
14:15 will be corrected soon
14:15 dsd_ sounds good
14:15 erikos dsd_, I guess we have to filter the incoming bugs
14:15 dsd_ erikos: should that be a #3 item?
14:15 erikos dsd_, either the release manager or we do it all
14:16 dsd_, (or appoint someone responsible)
14:16 dsd_ i'd be happy to do it separately, might be easier than dragging in loads of people
14:16 martinlanghoff this time round we have more bugs in dev.sl.o - so some adjustment in practice may be needed...
14:16 dsd_ perhaps on a general basis i can commit to doing it before each meeting starts
14:17 Cerlyn We also are only going to be able to do maybe 20% of them before the 11.2.0 date, so there is going to be mass deferment
14:17 martinlanghoff I propose either dsd or Cerlyn - maybe they can take turns or share the load.
14:18 dsd_ Cerlyn: what do you think?
14:18 martinlanghoff Cerlyn, agreed - we need to have some rough rule to triggee when we 've covered the "top 20%"
14:18 trigger
14:19 Cerlyn Personally I think we need to get all the highly user-visible things taken care of for 11.2.0 at this point (activities not starting, etc.)
14:19 dsd_ i mean on the question of a general process, who looks and tags the incoming bugs on a weekly basis
14:20 i'm happy to do it, allowing you to have 1 less distraction.. or alternatively, if you see it as your role and not mine i'm happy to step out of it
14:21 Cerlyn I could do it but I think you have a better idea what you want to target for each milestone
14:21 dsd_ ok
14:21 so i'll start doing that for the next few weeks and we'll see where it takes us
14:22 erikos great
14:22 dsd_ i've actually been doing it a bit already, but i'll make more of a point of it from now on
14:22 erikos we need to add the 11.3.0 milestone to trac
14:22 (sidenote)
14:22 martinlanghoff dsd_, do you have milestone management magic powers on trac ?
14:22 dsd_ nope
14:23 martinlanghoff hm - I do, ostensibly for XS milestone mgmt :-) ... but *you* should - not sure who grants that.
14:23 Cerlyn Quozl I believe is the main Trac admin
14:24 gonzalo maybe we can ask him to update the module owners too
14:24 the component owners
14:24 erikos (and for the 'action needed' field check the settings, /me could not find it)
14:24 dsd_ i think we have a general process then .. the two points that martin said, plus the triage of incoming bugs that i'll do on an ongoing or weekly basis, making sure that all new bugs have been tagged/milestoned for the start of each triage meeting
14:25 i have just 1 more "general process" question
14:26 olpc has typically had the habit of moving loads of bugs to the next milestone (in this case it would be 11.3.0) without really any commitment to actually taking care of those bugs in the next milestone
14:26 Cerlyn erikos: Likely covered at http://trac.edgewall.org/wiki/TracWorkflow
14:27 dsd_ for this reason hundreds of bugs were pushed from 8.2.0 to 9.1.0, and more recently, 50-100 bugs have been just been shifting around through 10.1.x to 11.2.0
14:27 erikos Cerlyn, well, the technical question
14:27 dsd_ should we change or continue that practice?
14:28 erikos dsd_, I prefer more having a bug cleanup after a release
14:29 dsd_ another way of asking the same question... during the triage we do now, where we find feature bugs that wont go into 11.2.0, how do we decide between putting those bugs in 11.3.0 vs future release?
14:30 gonzalo i found future release a to vague
14:30 martinlanghoff dsd_, in this case, 11.x.y are both on the same platform so it makes more sense than other times to 'push them out'
14:31 dsd_ push them out = put them all in future release ?
14:31 martinlanghoff gonzalo, 'future release' its vague on purpose; it means "nice but not now" ;-)
14:31 I say - have them on 11.2.0, then push them out to 11.3.0
14:31 Cerlyn In general we don't seem to start each release cycle by figuring out what past bugs we want to fix this time around from the future release pool
14:31 dsd_ Cerlyn: right.. but perhaps we should ?
14:31 martinlanghoff of course, during triage we close old/stale bugs if appropriate
14:32 Cerlyn That would be more in line with what I've seen in commercial environments, yes
14:32 martinlanghoff Cerlyn, of course we do
14:32 maybe we don't put it on trac, but we sure discuss what we think we can achieve this cycle
14:32 erikos (/me found the solution to expand the sugarlabs bug tracker, custom fields, would like to discuss this then as well)
14:32 martinlanghoff in this cycle, you may see collaboration overhaul :-)
14:33 dsd_ right.. but in this cycle, we started with loads of bugs that nobody really ever committed to looking at
14:34 erikos martinlanghoff, yes, but it is true that we did not go through the old bugs yet to see what still applies etc
14:34 dsd_ actually not that many..perhaps i'm making an issue out of something not so big
14:34 e.g. #10390
14:34 martinlanghoff dsd_, erikos you are both right, but we can't do that with a tiny team and a huge buglist
14:34 erikos dsd_, yeah, I think most of the bugs open have been filed during the last months
14:35 martinlanghoff we didn't go through the list formally, but we sure picked some bugs to prioritize
14:35 dsd_, #10390 I "triaged" it way down my list
14:35 dsd_ martinlanghoff: so your suggestion is that we move all the bugs we decide we cant deal with right now to 11.3.0? the same true for the new incoming tickets on a weekly basis?
14:36 martinlanghoff ok - here's what I propose. we triage what we can, focussing on the "top 20%"
14:36 -- by which I mean what we're likely to be able to address
14:37 now - once we're done w 11.2.0 , we'll know what we want to prioritize in terms of bugfixing for 11.3.0
14:37 it'll be the stuff that was important but didn't make the cut. yes/no/cancel?
14:38 dsd_ i agree, but my question was more about the details of triaging
14:38 martinlanghoff btw, #10390 got triaged down because we don't think cozybit really finished their job
14:39 so it has the risk that we do a lot of work, only to find some serious flaw that prevents it working... and cozybit may or may not be interested in fixing it :-p
14:39 dsd_ i think you're saying that we are effectively about to move 80% of the 11.2.0 tickets to another milestone.. my question is: which milestone? and how do i (as the incoming bug triager) decide this on an ongoing basis?
14:40 gonzalo we are thinking in moving the 80% of the tickets to 11.3.0 ? really?
14:41 Cerlyn gonzalo: Well are you really going to fix 240 tickets by July?
14:41 gonzalo can we start priorizing the tickets?
14:41 and later see what you can't do?
14:41 martinlanghoff dsd_, I am not sure
14:41 dsd_ gonzalo: we can, as soon as we decide what we do with the low priority ones :) thats my current question
14:41 gonzalo what we can,t do
14:42 martinlanghoff but I think gonzalo just gave us a hint: if we start triaging we'll know what the low-pri ones look like
14:42 dsd_ ok, so lets start with a couple of examples.. can i propose #10390  ?
14:43 gonzalo propose to?
14:43 martinlanghoff because I don't have an answer that covers all the spectrum of possible "unlikely to get fixed" bugs
14:43 dsd_ propose that we decide which milestone it goes in, because its not going in 11.2.0 :P
14:43 erikos gonzalo, as an example
14:43 martinlanghoff #10390 is a nice-to-have, wishlist item
14:43 it's a feature, not a bug
14:44 erikos maybe type is enhancement then
14:44 maybe 'type' is 'enhancement' then
14:44 martinlanghoff yep - done
14:45 dsd_ i personally get a bit irritated at carrying bugs over from one milestone to another without knowing what kind of commitment will be made in the next cycle, so would vote to put them all in future release .. then when we come to decide exactly who will work on what for the 11.3.0 cycle
14:45 we would move tickets from future release to 11.3.0
14:45 at the same time, its only a minor irritation :)
14:46 martinlanghoff dsd_, oh man... if we knew the future... :-)
14:46 dsd_ exactly
14:46 martinlanghoff i treat it as a useful database of things that may affect our deployments (but we don't know which one will)
14:46 erikos Iam fine with moving to 'future release'
14:46 martinlanghoff (so we can't prioritize all)
14:47 I am ok pushing stuff that we're clear we will not fix to 'future release'
14:47 erikos it is a huge pile by now, but one can sort by ticket number decending and find out which are the recent items after 11.2.0 when wanted to see for 11.3.0
14:49 dsd_ thats a good idea
14:49 gonzalo i can move all the activities still with old toolbars to future, right'
14:49 ?
14:49 Cerlyn If we had an 11.3.0 target one could just move them there
14:50 martinlanghoff you guys are the future
14:50 erikos gonzalo, for those you are sure you want to do them in 11.3.0
14:50 gonzalo, I would leave them for now
14:50 gonzalo, and wait until we have the 11.3.0 milestone
14:50 Cerlyn We may also need to strip out some stuff for 11.2.0 to fix in 11.3.0 if we're not fixing them now (like #10631 and #10696) as they are extremely ugly and user visible
14:50 erikos (but this is only my advice of course)
14:50 gonzalo erikos, ok
14:51 martinlanghoff i think we can simplify decisionmaking: 11.2.0 for stuff we may do now, or for 11.3.0 ; and 'future release' for stuff we clearly can't do
14:51 erikos (we can add a keyword 11.3.0 as well for now that we do not have to touch things several times)
14:51 martinlanghoff trac has this nice "mark this milestone as finished, push open bugs to this other milestone" button
14:52 because right now we don't know how much we can do in the next 2 months; we'll argue lots about 11.2.0 vs 11.3.0 when the only reality is _time_
14:52 I prefer we skip the arguing and maximise the time :-)
14:52 gonzalo me too
14:53 dsd_ i dont quite follow the suggestion though
14:53 you're saying leave stuff in 11.2.0 even though its beyond the feature deadline, because we plan to do it in 11.3.0? and that once 11.2.0 is done, you'll use the trac feature to magically put all those tickets in 11.3.0?
14:54 martinlanghoff dsd_, fair enough
14:54 dsd_ did i understand right?
14:54 martinlanghoff features /out/ now
14:54 dsd_ but leave bugs in, right
14:54 that makes some more sense
14:54 martinlanghoff I was thinking of bugs -- this triage cycle we should run our filters to search for _bugs_, everything else be damned
14:55 dsd_ ok, i'm happy with that, but i'm not sure if my original question has been answered (maybe i missed it...)
14:55 when moving features out now, do we put them in 11.3.0 or future release?
14:56 martinlanghoff um, oh
14:56 erikos dsd_, we have no 11.3.0 milestone yet
14:56 Cerlyn What I think he's saying is do the inverse, and use something in Trac (such as high priority or a tag) to mark what we want to do now
14:56 dsd_ erikos: we could create one right now i'm sure..
14:56 Cerlyn and then mass move later
14:56 erikos dsd_, well, I can't :/
14:56 martinlanghoff by default, future rel, but some stuff (ARM support! robots!) has a good chance of 11.3.0 :-) --
14:57 erikos dsd_, well, for stuff we are sure to do in 11.3.0 I would directly move it there, why touch things several times
14:57 dsd_ erikos: but how sure can you be? 11.3.0 planning so far has been minimal
14:57 martinlanghoff but it's a very short list, and we know them well, so you can just future-release them, and we'll move them back later
14:58 so that simplifies rules: features /out/ to the future
14:58 dsd_ ok, that sounds good to me
15:00 gonzalo ok, can we start looking at priorities?
15:00 martinlanghoff and (valid) bugs stay in 11.2.0 until fixed or released
15:01 dsd_ alright, that seems clear to me
15:01 erikos ok, what view does people look at with the 250 bugs?
15:01 dsd_ no more process questions from me :) (for now)
15:01 gonzalo erikos, 207 :)
15:01 Cerlyn I'm using http://dev.laptop.org/query?st[…]tone=11.2.0-final
15:02 And http://bugs.sugarlabs.org/quer[…]&keywords=~11.2.0
15:02 martinlanghoff thanks Cerlyn
15:02 so I;m reordering mine by component
15:02 dsd_ we could take a first pass, moving feature bugs off til future release?
15:03 martinlanghoff dsd_, can that be automated?
15:03 dsd_ dont think so
15:03 erikos ok, lets make sure we all have the same view
15:03 dsd_ do you have something in mind?
15:04 gonzalo erikos, the links from Cerlyn, grouped by component?
15:04 martinlanghoff so my thought was to - add filter by 'defect' , order by component so we can work in parallel
15:04 so I'm looking at http://dev.laptop.org/query?st[…]final&type=defect
15:05 dsd_ ah, thats a good point, perhaps all "enhancement" tickets can be moved to future release? with a little human sanity-checking
15:05 erikos martinlanghoff, that assumes that type is set correctly ;p
15:05 martinlanghoff erikos - you're right
15:06 so I volunteer to review those set to something other than defect
15:06 erikos ok, sounds good
15:06 dsd_ ok
15:07 and, to throw an idea out there, for the defects, me(system), erikos(sugar) and gonzalo(activities) can go through, checking for correct type, component, and priority ?
15:07 erikos dsd_, ok, do we set blocker?
15:07 dsd_, who decides that?
15:08 dsd_ perhaps we should do that collectively after, limiting ourselves to low/medium/high on first pass?
15:08 martinlanghoff I agree
15:08 gonzalo ok
15:08 erikos is good with me
15:08 martinlanghoff then we rview high pri together
15:08 dsd_ alright.. lets do it?
15:09 erikos yes
15:09 gonzalo yes
15:09 dsd_ go go go
15:09 erikos gonzalo, maybe you can move the 'not assigned' activity bugs/enhancements to 'other-activity'
15:10 gonzalo erikos, ok
15:14 erikos (sometimes adding a note why a triager is doing something helps later to understand what happened)
15:25 dsd_ there are quite a few bugs that i'm not sure how to triage; i'm going to keyword them with "retriage?" for possible later discussion with this group
15:26 (i.e. bugs that i think can/should be pushed out, but i'm not 100% sure)
15:30 Cerlyn don't forget the Sugarlabs tracker; there are a lot of "Unspecified" priority 11.2.0-tagged items there
15:43 dsd_ Cerlyn: remind me what the decision was for sugar tickets?
15:43 http://bugs.sugarlabs.org/ticket/2570 is quite important, so i'd like to mark it for 11.x.x consideration
15:43 do i have to create a ticket on dev.laptop.org ?
15:44 Cerlyn dsd_: Quite honestly I don't know as that kept changing.  I believe we wanted anything critical to OLPC builds copied to the OLPC tracker, but there are likely 11.2.0-tagged items not in OLPC's tracker
15:45 dsd_ erikos: can you clarify?
15:45 Cerlyn you can add keyword "11.2.0" to that in Sugarlabs if you think its relevant to us though
15:45 erikos dsd_, if we do our tagging right and are able to do the same workflow in the sugarlabs bug tracker I think we are ok
15:45 martinlanghoff erikos, component for window manager / sugar issues?
15:46 erikos martinlanghoff, 'wm' keyword
15:46 martinlanghoff sugar component ok?
15:46 erikos martinlanghoff, component sugar
15:46 martinlanghoff thanks!
15:57 erikos dsd_, http://dev.laptop.org/ticket/10693 - great! can you comment what the next steps are?
15:57 dsd_, do we have to carry the patch?
15:57 dsd_ commenting now
15:58 erikos dsd_, thanks
16:01 Cerlyn, can you test this http://dev.laptop.org/ticket/10713 ?
16:04 gonzalo, we never landed the activity launcher http://dev.laptop.org/ticket/10723 :(
16:04 gonzalo, so much work...
16:04 gonzalo erikos, no so much, but sascha said is not material for 0.92
16:05 erikos gonzalo, but can go in master
16:05 gonzalo erikos, ok, i will send you a version for master
16:06 erikos gonzalo, well, we should see the blockers we did went through review already, no?
16:06 gonzalo yes
16:07 erikos, (this can continue like a weekend project)
16:07 erikos gonzalo, sure, not critical
16:09 Cerlyn hmm... pippy fails to start in os19 on an XO-1
16:09 NM, os17
16:13 gonzalo Cerlyn, ticket?
16:13 Cerlyn I'm going to try another XO-1 first
16:15 works in os19
16:16 gonzalo ok
16:20 erikos dsd_, did you work on that one with vornau ? http://dev.laptop.org/ticket/10487
16:20 dsd_ vornau?
16:20 Jerry?
16:21 no, that was different (use sugar-install-bundle in build process)
16:22 for 10487, the next step is for someone to write the sugar code that silbe attempted to describe. i still dont quite understand the proposal
16:25 erikos dsd_, ok, yeah - I guess we can mark it 'feature'
16:26 Cerlyn, #10448 you re-tested on 11.2.0 ?
16:26 Cerlyn yes on an XO-1.5
16:26 dsd_ erikos: sounds good to me.. your territory :)
16:27 Cerlyn I don't see 10713 but as the commit notes that was fixed in March
16:29 erikos Cerlyn, yeah, I thought I had still seen it with this fix
16:30 Cerlyn, so I would like to have thorough sam testing of this
16:30 dsd_ martinlanghoff: i'm done on my bit .. need any help on yours?
16:31 martinlanghoff I'm having fun :-) --
16:33 i  you know batti, you may have an opinion on http://dev.laptop.org/ticket/10704
16:33 dsd_ i dont think its realistic
16:34 batty is small and simple, this is olpc-specific
16:34 better option would be to create a simple gnome app to tweak it, perhaps easy as part of gnome's new control center
16:34 want me to comment?
16:34 martinlanghoff ok - I misunderstood earlier descriptions of batti as being configurable/overridable/pluggable or somesuch
16:34 no - it's ok.
16:36 dsd_ once you're done, i have 16 tickets that i think could/should be pushed out of 11.x.x, ready for your 2nd opinion :)
16:36 martinlanghoff erikos, is http://dev.laptop.org/ticket/10727 cooked?
16:38 erikos martinlanghoff, the initial part yes
16:38 martinlanghoff, but I want to refine it
16:38 martinlanghoff, want to do it for 11.3.0
16:40 dsd_ i'm still a bit confused on the OLPC-SL split for sugar/activities tickets. are we moving all Sugar/activity related tickets to SL, without equivalent tickets on OLPC?
16:40 gonzalo dsd_, only when are not blockers i think
16:41 really not moving, creating the new ones
16:41 dsd_ "blocker" is quite subjective
16:42 ah, well i was going to offer to help move them, but if we're only applying this for new tickets then theres nothing to do there
16:42 gonzalo yes
16:49 Cerlyn unfortunately sugarlabs doesn't seem to let me look at details in the Trac timeline, but then they like showing 30 days of backlog by default
16:54 erikos martinlanghoff, do we have a test env for leases in the miami office?
16:55 Cerlyn not really no
16:55 martinlanghoff dsd_, i'm done
16:55 erikos hmmm
16:55 martinlanghoff apologies about the delay
16:55 Cerlyn I can pull production short-term from the real server, and we have loaded leases into our schoolserver, but custom licensing hasn't been done much
16:56 martinlanghoff refresh your search - I pushed a bunch out to future-rel
16:56 Cerlyn has left #olpc-meeting
16:56 Cerlyn <Cerlyn!~Cerlyn@173-12-75-9-miami.hfc.comcastbusiness.net> has joined #olpc-meeting
16:56 erikos wants to test http://dev.laptop.org/ticket/10861
16:56 martinlanghoff and fixed one or two that were defects
16:57 dsd_ martinlanghoff: http://dev.laptop.org/query?st[…]ords=~retriage%3F
16:57 i've commented on all of those, i think that they can maybe be pushed out as described
16:57 but my personal preference of moving out things that can't be committed too in the short term might be creeping in..
16:59 martinlanghoff sure
16:59 gonzalo dsd_, we can't do anything about Audio volume in XO 1.5 ? #10574
16:59 martinlanghoff dsd_, the fsck ticket - you're saying some changes in boot process make life easier in f15/16?
16:59 dsd_ gonzalo: we already did. we fixed it with a workaround. that ticket is there so that we find a cleaner fix
17:00 martinlanghoff: yes
17:01 its also a feature that is unlikely to bring significant gain
17:01 martinlanghoff what's the component that benefits us there?
17:01 gonzalo dsd_, the mic volume too? i can hear anithing saved with recoed at 30 or 40 cms
17:01 dsd_ systemd and plymouth
17:02 gonzalo s/can/can't/
17:03 Cerlyn For #10528 we need to know if the AVC touchpad ever went into production (I think it might have), #10571 how common are deployments doing XO-1.5 retrofits into ALPS
17:03 dsd_ gonzalo: thats a different issue
17:04 gonzalo dsd_ there are a ticket? i think is important
17:04 dsd_ gonzalo: not that i know of
17:04 gonzalo dsd_, ok, i will add one
17:05 Cerlyn The #10571 issue makes such a franken XO extremely frestrating to use, as it may not resume from keyboard half of the time
17:06 dsd_ martinlanghoff: there are a still a lot of enhancement tickets in the 11.2.0 milestones, is that intentional?
17:07 martinlanghoff: if you do take action on any of those tickets i pointed you at (thanks!) please remove the retriage? keyword
17:10 erikos dsd_, http://dev.laptop.org/ticket/10427 I do not understand your solution here
17:10 dsd_, do you link now the mimetype files?
17:10 dsd_ erikos: the build system now uses sugar-install-bundle to install activities, which is the correct way to install activities (right?)
17:11 i didnt check the resultant link, but i assume sugar-install-bundle does that
17:11 presumably jerry checked that
17:13 gonzalo i will go to lunch now, i will be back in 30 mins
17:16 erikos dsd_, yes, that should work, too
17:16 dsd_ great
17:17 erikos gonzalo, #10903 misses the component
17:17 dsd_, good to reference the commit in the ticket ;p
17:19 dsd_ good point
17:19 erikos was proactive
17:20 ok I have 4 tickets I would set to blocker can we quickly go through them?
17:21 martinlanghoff dsd_, ah you spotted that I forgot to remove retriage
17:21 I was doing same
17:21 dsd_ hehe thanks
17:22 martinlanghoff still a couple to discuss
17:22 #9535
17:22 I think we can keep that one open -- it describes the fix for the root cause
17:23 dsd_ leave it in 11.x.x as well?
17:24 martinlanghoff no - future release
17:25 dsd_ sounds good, can i put it in the wireless component too? next step is firmware development
17:25 martinlanghoff but we did split off the "workaround" -- which ended up being changesi n powerd
17:25 yep
17:25 dsd_ ok i'll do that
17:25 thanks
17:25 martinlanghoff cool
17:27 Cerlyn For #10232 XO-1s currently are allowed to idle suspend.  If we are still worried about that then we need to tell them not to for 11.2.0
17:27 dsd_ right, that will be done
17:28 it only gets enabled during development windows to allow easy access for developers and testers to any progress (one day...) on the various outstanding issues
17:28 erikos is called for dinner
17:33 dsd_ save some for us
17:36 martinlanghoff yummy
17:37 dsd - I am re-visiting enhancements that remain...
17:37 dsd_ ok
17:37 martinlanghoff oops - ok some are new
17:37 dsd_ yeah i figured maybe some people changed type
17:37 martinlanghoff gonzalo, changed them from defect to enhancement, but didn't push them out
17:37 dsd_ gonzalo: hows it going on your side? can i help with something?
17:38 martinlanghoff skipping the toolbar items - the ones left over have a good chance of being in 'add to build' state
17:39 3707 is test-in-build
17:39 8865 same
17:39 dsd_ k
17:39 martinlanghoff 10778 same
17:39 gonzalo yes, are a few test in build and add to build
17:39 martinlanghoff 10790 - well, it's time to close it :-)
17:40 10812 is also an rpm change
17:40 10860 and 10861 - both have the patch - though 10860 may be worth a bump out
17:41 dsd_ i dont see a patch in 10860
17:42 gonzalo no, erikos is asking for this
17:42 dsd_ some of the others will need to be dealt with tonight if they make thef reeze
17:42 but yeah, suppose it makes sense to leave them for today
17:45 i think my part is done, and i'm feeling pretty trac'd out
17:46 Cerlyn the lease patch has a TODO to internationalize "days remaining", so if patched we're going to have to edit it later
17:46 martinlanghoff gonzalo, I've tagged a couple "manuel?" - they seem to be items on which manuel may be able to help (and get them done for 11.3.
17:46 Cerlyn, do you mean we need to cahnge the code to say _("days remaining")
17:47 or to tanslate the string in pootle?
17:47 gonzalo martinlanghoff, good, i will look to them
17:47 Cerlyn yes, and maybe throw the number in there in case it changes location
17:47 dsd_ with plural forms too ;)
17:47 Cerlyn ah yes; Arabic does that, doesn't it
17:47 dsd_ the patch looks a bit sketchy..i bet it blows up on delegated leases
17:47 martinlanghoff easier to say "expires on"
17:48 if the patch's no good... /out/
17:48 Cerlyn martinlanghoff: Then we would have to expose the current date within Sugar better, which apart from the Clock activitiy it tries to mask
17:48 dsd_ i'll be doing the freeze build tomorrow at midday .. gives a few hours for people to clean up ends like that, if they really want
17:49 martinlanghoff some of the enhancement trac items are about getting you to include some rpms :-)
17:49 dsd_, ^^^
17:49 dsd_ yeah, those are fine of course
17:49 martinlanghoff or change rpms
17:49 dsd_ they are all in "add to build" i guess ?
17:49 martinlanghoff um
17:49 soon they will :-p
17:49 dsd_ hehe ok, thanks
17:49 i'll make sure to go over them first
17:50 #10812 is presumably one of those, but its not clear which packages should be added as a result
17:56 #10783 is also waiting on your comments
17:57 gonzalo my last comment in #10783 is related to #10790
17:58 dsd_ ah ok, could you post it on 10790 then please?
17:58 gonzalo ok
18:02 Cerlyn Anything I have to look at?
18:06 gonzalo Cerlyn: all the "test in build"?
18:07 Cerlyn I meant during this meeting
18:15 martinlanghoff i'm all trac'd out
18:15 running out for some food
18:18 Cerlyn So should we close out this meeting, or is there more discussion to be held?
18:19 dsd_ i think there is more work to be done, but not today..please :)
18:20 Cerlyn you can #endmeeting it if you want
18:20 martinlanghoff sure - we're done here. we've gone far beyond what I'd expected
18:20 dsd_ #endmeeting
18:20 meeting Meeting ended Mon May 23 18:20:42 2011 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot. (v 0.1.4)
18:20 Minutes: http://meeting.sugarlabs.org/o[…]-23T14:04:13.html
18:20 Log:     http://meeting.sugarlabs.org/o[…]11-05-23T14:04:13

Index | Today     Channels | Search | Join

Powered by ilbot/Modified.
Webmaster