« 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