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

#sugar-meeting, 2010-03-08

 « Previous day | Index | Today | Next day »     Channels | Search | Join

All times shown according to UTC.

Time Nick Message
09:16 tomeu nice
09:16    *  backport SL#1787 to 0.86, push out + announce new release
09:16 who wants to start with this?
09:16 silbe that's my point :)
09:17 basically I've noticed that we didn't force an index rebuild for v1 -> v2 migrations of the data store
09:18 which means the new features v2 was supposed for won't work if the user upgraded from 0.84 to 0.86
09:19 we have a fix in 0.88 now (committed today) that will force a rebuild even if the user already missed it (by bumping the version yet again)
09:20 we should backport the fix to 0.86 and push out a new 0.86 release for current 0.86 users.
09:21 tomeu so this issue is brought up here to decide if it's worth making a new 0.86 release?
09:21 alsroot +1 but I guess it would not be so useful since we don't have(I guess) sugar deployments that stuck to 0.86 and can't switch to 0.88
09:22 silbe the question is: what will reach the users more quickly? a new 0.86 release or 0.88?
09:23 alsroot at the end doesn't see any problem to not push this fix to 0.86
09:23 e.g. OLPC will use 0.84, other LTS(ubuntu at least) 0.84 based as well
09:23 silbe the answer also depends on whether Ubuntu Lucid will ship 0.86 or 0.88
09:23 tomeu silbe: depends on the users, I guess
09:23 what's the downside of a new release?
09:24 silbe tomeu: that's why i'd rather push out a new release, to make sure we reach as many users as possible
09:24 tomeu: I can't think of any downside, but maybe someone else does?
09:25 tomeu I guess just the work of making a new release and packaging it, but I guess it's worth it?
09:25 silbe: btw, which changes in v2 need an index rebuild?
09:26 alsroot silbe: so, lucid will be 0.88 based and I guess other mainstream distros as well
09:26 silbe tomeu: would think so. it isn't critical (nothing breaks badly), but it will work for some (those that started with 0.86 or had their index rebuilt due to corruption) while it won't work for others (that migrated from 0.84) which can be rather confusing.
09:27 tomeu: you should know, you introduced v2 IIRC :)
09:27 alsroot: ok, that's good news already.
09:27 tomeu wishes he could remember all he did in the past
09:28 silbe: but you don't know it?
09:28 silbe let's check the new README section...
09:32 tomeu 2   0.86.x
09:32    Add sorting by title and mtime
09:32 silbe commit 987b48bb194acf301a968823ccbc079d3f734997, implement sorting by mtime + title
09:34 hmm, sorting isn't directly exposed to the user currently. does any activity use it?
09:34 tomeu so we were updating the index instead of rebuilding it, so the old entries wouldn't be sortable?
09:34 ah, those changes got reverted from the UI
09:34 designers didn't liked it
09:35 alsroot silbe: at least will, Library
09:35 btw I'm going to use eben's mockup for sorting feature
09:35 tomeu that's what was implemented in the journal
09:35 silbe ok, then it might still be better to push out a release, as otherwise Library will need to add a workaround
09:36 tomeu fine with me
09:36 silbe tomeu: yeah, I remember the headers got thrown out agai
09:36 tomeu are we done with this?
09:36 silbe so what's the procedure to do a 0.86 bugfix release?
09:36 tomeu any action items?
09:36 silbe who does it, and how?
09:36 tomeu I guess alsroot just does a release?
09:36 in the 0.86 branch
09:37 alsroot will do
09:37 silbe thx!
09:37 tomeu do'nt think we need to do anything else
09:37 ok, next point:   *  0.88 Release: bug database cleanup, code review, stabilization, etc
09:37 silbe well, as long as release includes announce, yep :)
09:38 (just making sure)
09:38 tomeu people can also prod packagers if needed
09:38 so walterbender has been spearheading the triaging effort
09:38 walterbender: anything you want to say about it?
09:40 ok, maybe later
09:40 silbe guess not ;)
09:41 tomeu there's still lots of bugs for triaging, is anybody here interested in helping out but is unsure of how?
09:41 silbe what about the review q? anything still stuck in there (haven't checked all of my own bugs yet)
09:41 ?
09:42 tomeu we have 31 items there
09:42 some are bogus, we should remove them from there
09:42 I will dedicate some time tomorrow to go through mine
09:42 alsroot someone has tiny link to bugs.sl.o query
09:43 silbe you mean the sugar-love ones, or are there bugs with r? that don't have a patch attached?
09:43 tomeu alsroot: http://tinyurl.com/yg73kkw
09:43 silbe: bugs with r? that aren't awaiting review
09:44 alsroot: do you have your review queue under control? do you need any help with it?
09:45 alsroot is trying to figure out
09:45 tomeu #action alsroot to make a new datastore release in the 0.86 branch
09:45 hmm
09:45 silbe we should make sure the activity-death-response one makes it i
09:46 alsroot has severa fsync related patches, but not sure it is the right way to go -- it could makes sense for OLCP and could be better to have patches there
09:46 silbe I still don't understand why it didn't get committed yet, it makes a huge difference
09:46 tomeu #actionitem alsroot to make a new datastore release in the 0.86 branch
09:46 damn
09:47 anybody knows the syntax?
09:47 alsroot known nothing about such stuff
09:47 silbe alsroot: I don't think the fsync ones are useful. we should rather make stuff more resilient to failures.
09:47 tomeu #ACTION alsroot to make a new datastore release in the 0.86 branch
09:47 silbe as it will still break if the machine crashes / gets turned off during the sync
09:48 tomeu #ACTION Tomeu to go through his review queue tomorrow
09:48 silbe: shouldn't be doing both in some cases?
09:49 silbe: about the activity feedback one, it remained in r! for months, thus not appearing in the queue
09:49 silbe tomeu: in some cases yes, but not in most of those proposed by OLPC
09:49 on the XO, the data store is already very slow. using fsync will slow it down even more.
09:50 tomeu ok, so this is stuck because nobody has time to look at it?
09:50 silbe tomeu: maybe we should do a monthly run through the r! ones to ensure nothing gets forgotten?
09:50 tomeu: which one? fsync?
09:51 tomeu yeah
09:51 silbe: well, I hoped the review report would spot such situations
09:52 any takers for reviving the review report?
09:52 silbe tomeu: i'll take a look at it later to see if there's any proposed fsync that I think makes sense for us.
09:52 alsroot at least will look into his queue
09:52 silbe tomeu: no, the review report is for detecting tickets that don't have any review flag set, even though there are patches attached.
09:53 tomeu #ACTION silbe will look at the fsync tickets
09:53 silbe: but could also say which tickets are in r! and for how long
09:53 #ACTION alsroot to look at his review queue soonish
09:53 silbe tomeu: you should be able to do that with a regular query, no report required.
09:54 tomeu silbe: the problem is that people don't need to remember every week to execute N queues
09:54 instead, a single report is generated weekly and several eyes get a glimpse at the current status
09:54 silbe tomeu: take a look at http://bugs.sugarlabs.org/wiki/User:sascha_silbe  to see what queries I use for the my tickets in the q
09:54 tomeu that the whole point of automated reports
09:55 silbe: do you agree on the usefulness of automated reports in the mailing lists?
09:55 silbe tomeu: ah, you're talking about the reminder email, not the Trac report
09:55 yes, that would be useful
09:55 tomeu ok, so we need to find someone who wants to look at it
09:56 silbe who was supposed to look at it?
09:56 tomeu did we had a volunteer already?
09:57 alsroot btw maybe there is already track plugin for that
09:58 silbe put it up for me, i'll have a go once Trac is migrated
09:58 tomeu awesome!
09:59 #ACTION silbe to look at a report that is sent automatically every week noting which tickets are in the review queue and for long. also spot tickets that have been in r! for too long and may be stuck
09:59 as an aside, http://producingoss.com/ proposes the figure of the patch manager to do just that job
10:00 we can automate it instead because of the r? flag
10:00 ok, let's move to the last topic? stabilization?
10:00 silbe go ahead
10:01 tomeu so the nightly soas builds should have the last 0.88 bits
10:01 ready to be tested
10:02 guess we don't have anybody from the .nz team, being so late there
10:02 is anybody here testing those builds?
10:02 alsroot there is also last 0.88 in karmic ppa for several days
10:03 tomeu alsroot: and is there anybody using it?
10:03 alsroot at least someone answered to the devel@ about this
10:03 tomeu alsroot: ok, would be great if tickets were filed about 0.88 testing
10:04 I'm unfortunately not able to lead the qa effort, but I think other people such as canoeberry are working on it
10:05 heh
10:05 just said: tomeu: I'm unfortunately not able to lead the qa effort, but I think other people such as canoeberry are working on it
10:05 silbe perfect timing :)
10:06 tomeu right now, I see the situation as in 0.88 not going to be a polished release, because people aren't testing it during the stabilization period
10:07 myself, I'm being paid for 1-2 days in misc sugar stuff (which could include testing and bugfixing, but I have lots of other stuff to do as well) and the rest for new features, so I'm unable to dedicate more time to stabilization
10:08 so, should we close this meeting? we are 5 minutes late, but we can talk about something else if needed
10:08 5, 4, 3, ...
10:08 silbe reading backlog
10:08 tomeu 2, 1, 0
10:09 thanks all for coming
10:09 waits for silbe
10:09 alsroot goes to bump ds 0.86
10:10 silbe tomeu: yes, I'd rather have you respond fast to reviews than doing random testing
10:10 tomeu ok, so I will go through thr queue tomorrow, but please ping me when needed about it
10:10 silbe as for myself, I'm going to check on all the open bugs I'm currently subscribed to soon.
10:11 I hope to get a couple of them into 0.88
10:11 once that's done I can do some testing
10:11 tomeu great, as triage proceeds, we'll get a better idea of what is really important to get fixed
10:11 Daniel_C: do you need ideas for good bugs to tackle?
10:12 silbe BTW, we should document the dependencies of the 3G stuff
10:12 bernie mentioned some of it lately on IRC, but we should rather have it in the source and release notes
10:13 tomeu silbe: do we know already which are those?
10:14 silbe tomeu: I don't, but I sure hope the patch submitter (Daniel_C? tch? I don't remember) does :)
10:14 bernie mentioned something about specific versions being required, we should ensure to note that
10:14 tomeu #ACTION tomeu to find out which new dependencies we have because of the 3g stuff
10:14 ok, and let's end the meeting
10:14 silbe also, what connection methods are supported? USB? Bluetooth?
10:15 Daniel_C tomeu: No yet, I have to dedicate more time on triagging tickets
10:15 tomeu if anyone has any particular items, we can do an extraordinary meeting about it
10:15 Daniel_C: ok
10:15 silbe: I would say that we don't really need to to decide that, because activities don't need to know if that's available or not
10:15 silbe: so we can just recommend those
10:16 silbe tomeu: decide what? sorry, loss of context I guess...
10:16 tomeu silbe: which new dependencies we have
10:16 silbe tomeu: activities don't care, but packagers do
10:17 we should make sure packagers have all information they need to make Sugar work as expected
10:17 tomeu silbe: right, but each downstream can decide to make the sugar package depend on more or less soft dependencies
10:17 silbe obsolete dependencies make for some hard-to-find problems
10:17 tomeu silbe: but should we say that sugar will be able to use a specific model of 3g stick?
10:18 if it needs an specific kernel module to be installed?
10:18 silbe tomeu: yes, but in order to make those decisions they need to know what Sugar needs for all the features to work
10:18 tomeu: I'm talking about other packages, not hardware
10:18 tomeu silbe: what I mean is that sugar needs NM to use 3g modems and that is a strong dependency, but we don't directly depend on specific kernel modules
10:18 silbe tomeu: a minimum required version of modem-manager or whatever it was
10:19 tomeu that's a choice of downstreams such as olpc
10:19 silbe: that sounds good
10:19 Daniel_C silbe: the 3G feature needs the option.ko driver
10:19 tomeu needs to go back to collab work
10:20 #endmeeting

 « Previous day | Index | Today | Next day »     Channels | Search | Join

Powered by ilbot/Modified.