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

#sugar-meeting, 2010-05-31

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

All times shown according to UTC.

Time Nick Message
15:07 mchua #link http://wiki.sugarlabs.org/go/S[…]k_meetings#Agenda
15:08 #info Today's meeting goal: review the v3 release cycle of SoaS, go over what happened and what parts of that went well / could be better.
15:08 #info this is NOT a v4 planning session - we'll be doing that next week, and incorporating the data we get during this round into that to make v4 better.
15:09 So what we're looking for here, really, is an hour (really 50 minutes now) of chronological brainspew, if that makes sense.
15:09 Seeing the release from as many different perspectives as possible.
15:09 Does that work for everyone?
15:09 sdziallas is +1 to that.
15:09 garycmartin +1
15:09 satellit_ +1
15:09 mchua Okay. If everyone can take a look at the release schedule in that agenda link above, we'll go through things one at a time.
15:10 One month at a time, actually.
15:10 I'll put a link to the SoaS list archives here...
15:10 #link http://lists.sugarlabs.org/archive/soas/
15:10 Okay, we should start with November.
15:11 #topic November 2009
15:11 #info November 11, 2009 - Fedora (and therefore Fedora Spin) release cycle begins
15:11 #link http://lists.sugarlabs.org/arc[…]ember/thread.html
15:11 (The first few months should be pretty quick)
15:12 sdziallas Looks like we were having lots of funny decision panel convos back then.
15:12 mchua Yeah, that's when we got the exclusive permission to use the SoaS name from SLOBs.
15:12 #info November 2009 - SLOBs declares the term "SoaS" to refer to this project
15:12 sdziallas I'm really glad this is out of the way now.
15:12 mchua That was important.
15:12 It also took WAY too long, imo, but I think SLOBs also learned a lot from the process.
15:12 Decision panels: we should... um... run them better.
15:13 SeanDaly lurking at dinner table with iPhone
15:13 sdziallas waves to SeanDaly
15:13 mchua Hey, SeanDaly!
15:13 Anything else for November? I want to move quickly until we get to Feb or so.
15:13 sdziallas I think we're good there.
15:13 mchua #topic December
15:13 #topic December 2009
15:13 Whoops. There we go.
15:14 #link http://lists.sugarlabs.org/arc[…]ember/thread.html
15:14 sdziallas We're still talking Blueberry there, so we should move on.
15:14 Blueberry got released a little later than F12, hence the shorter cycle for Mirabelle.
15:14 mchua Yeah, a lot of blueberry press here (mad props to SeanDaly and crew on that!)
15:14 sdziallas: should we just skip a bunch of months then? When do you reckon the Mirabelle release cycle actually started?
15:15 sdziallas mchua: February is probably not too bad.
15:15 mchua #info December 2009 - still on Blueberry, lots of good PR from SeanDaly and Marketing crew (but this isn't Mirabelle, so we should move on)
15:15 Actually, January we got spin approval, so let's stop briefly there
15:15 #topic January 2010
15:15 #link http://lists.fedoraproject.org[…]nuary/007869.html
15:16 #info January 14, 2010 - Approval as a Fedora Spin
15:16 Now, this was pretty significant.
15:16 sdziallas Yeah, right. That was important, but we should be good now.
15:16 mchua sdziallas: can you talk a little about why this was a big deal, and what it entailed / what it meant?
15:16 sdziallas The SIG needs to reapprove spins, but we've got trademark approval.
15:16 mchua: sure thing!
15:17 the whole Spin Process is what enables (and entitles) us to the advantages the cooperation with Fedora brings.
15:17 mchua #link https://fedoraproject.org/wiki/Spins
15:17 #info "Spins are alternate versions of Fedora, tailored for various types of users via hand-picked application sets and other customizations."
15:17 sdziallas (I think we covered the advantages for us regarding engineering and sustainability in a previous email)
15:17 mchua #link http://spins.fedoraproject.org/about
15:18 sdziallas This is significant, though, as the Feature Freeze (see agenda) was a hard deadline for this.
15:18 mchua sdziallas: Yeah... if you find that email, let me know, it'd be a good link to have - trying to explain rationale behind these decisions here for posterity and all.
15:18 #info Feature Freeze (in the Fedora 13 cycle, Feb 9, 2010) was a hard deadline for Spin approval, so it's good we got in earlier
15:18 SeanDaly wishes I knew what SIG meant
15:19 sdziallas Special Interest Group (sorry)
15:19 there's a SIG in Fedora that takes care of the Spins :)
15:19 mchua #info Spin approval was a deadline imposed by Fedora - if we'd missed that, we would not have been able to take advantage of Fedora's engineering, etc. resources at all for Mirabelle.
15:19 So it was an approval process on the Fedora side that needed to happen.
15:20 SeanDaly is a SIG a decision committee?
15:20 sdziallas mchua: I just found an email saying that we'll only use Fedora packages (which was a requirement, too), but not the email I was thinking about.
15:20 mchua We can cover the "why a spin?" process later on - we should actually do a little "how SoaS gets made" guide explaining what kickstart files are and so forth - but for instance, .iso files stopped being produced by the "sdziallas manually builds them every time" process
15:20 pbrobinson no, a SIG is a group of people with a special interest. Eg Sugar
15:21 mchua and started being produced by the "automatically, the Fedora system generates .isos from the kickstart files we've uploaded" process (aiui - pbrobinson, sdziallas, correct me if I'm wrong here)
15:21 sdziallas mchua: exactly! and we got automatic builds for testing! and... you made the point already :)
15:21 mchua so we gained some instant automation of the infrastructure we need anyway, without any more work or maintenance on our part
15:21 so we could focus on things like... making Activities work, the stuff that's actually unique to Sugar.
15:21 so that was a *huge* win.
15:21 sdziallas obviously, we *have* to take care of the packages now, but we'd have done that anyway, so it *is* an improvement. yes.
15:22 s/yes/YES!!! :)
15:22 mchua Before SoaS was a spin, it was a remix of Fedora.
15:22 which means we were doing all the same *technical* stuff - packaging still had to happen, we still made a kickstart file and used that to generate an .iso
15:22 it was just all done manually
15:23 and slowly, and without any help or support from anybody else, and resulted in... sleepless nights, aiui.
15:23 sdziallas (which was why I was so hosed before the Blueberry launch... yup, exactly.)
15:23 pbrobinson it required a lot of time and manual process
15:23 mchua Anyhoo, I think we've waxed eloquent on the "YAY, SPINS!" point enough. :) but this is just - trying to give the folks not from engineering here some insight on why we were so psyched about this.
15:23 it's like having someone come in and magically volunteer to cook/clean/mow-the-lawn/fix-the-plumbing
15:24 #link http://lists.sugarlabs.org/arc[…]nuary/thread.html
15:24 #info That's the January mailing list archives - we didn't explain the "yay, spin!" thing very well then, which may have led to communication disconnect down the line
15:24 sdziallas http://meeting.olpcorps.net/su[…]0100108_1109.html
15:24 mchua In particular, I'm not sure if we made it clear enough that we were tied to the Fedora release cycle, and what that meant, and how...
15:25 ...but we'll get to that later on.
15:25 sdziallas we had a meeting about this, IIRC. but... yeah.
15:25 mchua #link http://meeting.olpcorps.net/su[…]0100108_1109.html
15:25 SeanDaly has a cleaning lady who unplugs computers and routers
15:25 mchua sdziallas: what's that meeting link, so I can #info it?
15:25 er, summary?
15:25 actually, I should just...
15:25 sdziallas mchua: it comes from a SoaS planning meeting. I *think* that's when we moved towards the spin idea...
15:25 mchua #chair sdziallas pbrobinson satellit_ SeanDaly garycmartin
15:26 sdziallas: now you can #info too.
15:26 sdziallas awesome!
15:26 #info SoaS planning meeting lead to working on getting spin approved
15:26 mchua Okay, moving on to Feb?
15:26 sdziallas Yup!
15:26 mchua (where the real fun starts)
15:26 #topic Feb 2010
15:27 garycmartin FWIW didn't know the diff between remix and spin.
15:27 mchua #info 2010-02-09 Fedora Feature Freeze
15:27 garycmartin: yeah, that's our fault for not clarifying things
15:27 sdziallas garycmartin: we failed at explaining that then :)
15:27 notes the info line.
15:27 mchua I think perhaps sdziallas and pbrobinson and I are so enmeshed in the Fedora world as well that we sometimes forget others aren't.
15:27 sdziallas We didn't really have a "feature process" for SoaS.
15:27 I think we should have. Or at least start talking features early in the release cycle.
15:28 pbrobinson mchua: you might be right there, but people didn't really speak up to say they didn't know what it meant either
15:28 mchua #note sdziallas, pbrobinson, and mchua forgot that others don't keep track of the Fedora schedule and what dates/milestones mean and how they impact SoaS's schedule - need to communicate this more clearly next time.
15:28 sdziallas I believe this will give people the ability to count more on what's going to happen and will ensure a better communication.
15:28 mchua pbrobinson: good point.
15:28 #note folks need to speak up also when we start talking about things they don't understand!
15:28 garycmartin: so I'm glad you noted that above now :)
15:28 sdziallas: #info, plz
15:28 sdziallas #info sdziallas thinks we should talk about features for v.4
15:29 mchua: I was just typing a note but made it an info. ;)
15:29 mchua or #note or #agreed or #something-that-puts-meeting-minutes-up
15:29 worksforme.
15:29 pbrobinson The fedora guys publish a schedule to the mailing lists as a reminder to all about upcoming schedules. We should do that as well
15:29 mchua pbrobinson: how often?
15:29 sdziallas we don't need a giant process that makes things more complicated. but I'd prefer us narrowing features down early (and having deadlines there).
15:29 mchua pbrobinson: you have chair, so feel free to #idea it too ;)
15:30 walterbender mchua: independent of schedule, there is another related topic I'd like to mention...
15:30 sdziallas mchua: could we get poelcat to CC the SoaS list on the devel announcements?
15:30 pbrobinson mchua: not 100% sure, but fortnightly would probably be enough
15:30 mchua sdziallas: what happened in this round because of no well-defined feature process? examples of bad things that could have been avoided/good things that could have happened but didn't?
15:30 sdziallas mchua: or it could just letter-me-later ;)
15:30 mchua #idea send fortnightly release schedule emails to the SoaS list about upcoming milestones
15:31 sdziallas mchua: marketing wouldn't be looking for things to promote because we'd have norrowed these down early.
15:31 pbrobinson #idea regulart email the upcoming schedule and deadlines
15:31 sdziallas and everybody would have worked on making these things happen instead of...
15:31 mchua walterbender: Sure thing. Feel free to jump in any time.
15:31 walterbender sdziallas: the issue from the Activity perspective was a bit less direct.
15:31 mchua #chair walterbender
15:31 SeanDaly Most nonfedorans don't know nuances of Fedora nomenclature... including journalists who cover FOSS...
15:31 sdziallas ..."oh shit need feature?" - *implement* (or try to)
15:31 mchua SeanDaly: Yep - but we don't know what you don't know, so please ask us to explain things that aren't clear
15:32 walterbender there were lots of Fedora changes that ultimately impacted activities regardless of "features"
15:32 mchua Should we explain the feature process in Fedora briefly?
15:32 SeanDaly sdziallas: marketers always very interested in features
15:32 mchua for SeanDaly and others who may not be familiar with that part of how the schedule works?
15:32 walterbender and fr some reason, in the run up to v3, those implications were not clear
15:32 mchua nods
15:32 pbrobinson walterbender: most of the issues were GNOME and other upstream features and mostly not Fedora
15:32 sdziallas SeanDaly: yes, but a day before the release is suboptimal for all of us, so I'd like to get these out earlier :)
15:32 walterbender so we had wholes, like the evince/Read debacle
15:33 pbrobinson walterbender: that was upstream gnome.
15:33 mchua ok, what I'd like to do is ask pbrobinson and sdziallas to give a quick overview of the Fedora feature process so we have a summary here
15:33 sdziallas SeanDaly: (not saying this is marketing's fault, just that talking about these earlier will make them better and give marketing more time for them, too)
15:33 mchua and then hear walterbender on how it impacted Activities
15:33 and then SeanDaly on how he'd have liked to see it work out with Marketing
15:33 and then proceed
15:33 walterbender it seems that one thing the SoaS team could do is try to make sure that these sorts of changes, to what ever extent they can be anticipated, are well known on devel
15:34 mchua (can we do that? summary of feature process, then walterbender on Activities, then SeanDaly on Marketing? I think this is a pretty major topic and will be an important part of the process to handle better for v4)
15:34 sdziallas I will note that I wasn't aware of any evince-python lib changes, but I agree that we need communication there.
15:34 walterbender speaking as an activity developer, I assumed that if it worked in jhbuild, it was probably working on SoaS... but that was a faulty assumption
15:34 mchua ( garycmartin, feel free to poke in with comments and such too - does the feature process we're talking about make sense, or is it something we need to pause and explain?)
15:34 walterbender: hang on a moment
15:34 SeanDaly sdziallas: our problem is the disappearance of existing features, not looking for new ones
15:34 pbrobinson walterbender: those issues weren't even know by us until a couple of days before release.
15:35 mchua pbrobinson, SeanDaly, hang on a moment
15:35 I want to make sure everyone's on the same page wrt "what is the feature process, anyway?"
15:35 garycmartin: (you following ok? we're blazing past *tons* of Fedora-specific stuff right now)
15:35 pulls out meeting chair hat. one at a time.
15:35 pbrobinson #link https://fedoraproject.org/wiki/Features/Policy
15:35 sdziallas waves franctically to talk about sources of these issues. later. mchua is right.
15:36 garycmartin mchua: Reading as fast as I can but half page backlog prevents me asking anything.
15:36 mchua pbrobinson, sdziallas: can you guys #info and #link us "what's the feature process in Fedora?" info for a minute or two? so we all know what we're talking about?
15:36 pbrobinson: perfect
15:36 garycmartin: np
15:36 #info basically, the way features happen in Fedora is that early in the release process, developers propose features, and they are approved by feature freeze
15:36 sdziallas or not. and if they aren't, they are dropped.
15:37 not from inclusion, but they aren't mentioned as features explicitely.
15:37 mchua #info they have to meet certain criteria by certain deadlines - if they don't, they're dropped and not eligible for mention as features
15:37 satellit_ This brings in testing can I say a few things?
15:37 mchua this means that, for instance, we don't have last-minute "but... can we get this in? do we have this working? can we put this in a press release?" scrambles
15:37 satellit_: yep, after SeanDaly
15:37 pbrobinson #info feature freeze is in time for the alpha release
15:37 mchua queueing up the takling queue :)
15:37 er, talking queue
15:38 #info Marketing team in Fedora makes their plans according to the feature list that's set by Alpha - this lets us plan how to target what features early in the process
15:38 pbrobinson so all major features but be in and be able to be tested by the alpha
15:38 more minor ones can come along later but all have to be in by the beta release
15:38 sdziallas so here's the thing about a feature process for SoaS:
15:38 mchua Yep, so there's a lot of time to test and figure out how we'll position the release marketing-wise (speaking as the Fedora Marketing team lead for Fedora 13)
15:38 nods
15:38 pbrobinson after that point int time its bug fixing only
15:39 mchua #info Major features must be in and testable by Alpha; minor changes need to be in and testable by Beta, after Beta it's only bugfixes allowed (in the Fedora schedule)
15:39 sdziallas since SoaS relies on *both* Sugar *and* Fedora, we're kinda relying on *their* feature processes, too. There are rarely *SoaS* features that don't go into either a Sugar or Fedora category.
15:39 Books are such an example.
15:39 But I'm having a hard time coming up with lots of more.
15:39 Which is why I'm saying that KISS should work here.
15:39 garycmartin So do folks consider activities as features
15:40 mchua #info since SoaS relies on both Sugar and Fedora as upstreams, we rely on their feature processes - most SoaS features come from either Fedora features or Sugar features.
15:40 sdziallas (maybe I'm pushing too far here, though)
15:40 garycmartin: good point!
15:40 mchua Hm, garycmartin raises a good question. I don't know the answer, but I'm inclined to say yes... I don't know if sugar(core) takes those into account though
15:40 so maybe that's our third upstream.
15:40 Fedora, SL (sugar-core), and ASLO.
15:40 sdziallas I *think* we need to pull the upcoming Activity Inclusion criteria here out of the hat, mchua?
15:41 mchua and nobody is really driving an Activity release process, afaict, but maybe walterbender can speak to that more
15:41 pbrobinson mchua: SoaS also relies on upstream GNOME and python too
15:41 sdziallas If these criteria covers them and their developer proposes them and the criteria is met, including them should be sane, I think.
15:41 mchua #info SoaS upstreams: Fedora, Sugar Labs (sugar-core), ASLO (Activities), GNOME, python
15:41 walterbender I am less concerned about activities as features than I am about changes that impact activities
15:41 sdziallas #info Activity Inclusions Criteria to be finalized for v.4
15:42 pbrobinson walterbender: who maintains the jhbuild system and the versions of packages that it uses?
15:42 mchua Okay. Does everyone have an okay idea of the feature process (at least as it works in Fedora as a specific example of how feature processes in FOSS projects work in general)?
15:42 Feature processes are things that happen in basically every major FOSS project, and really in every major engineering project (even non-software) - it's how we systematically make sure we build something that's good and working.
15:42 #info Feature processes are things that happen in basically every major FOSS project, and really in every major engineering project (even non-software) - it's how we systematically make sure we build something that's good and working.
15:42 walterbender and there are several subsystems that impact lots of activities, so knowing as much as far in advance about those changes (features) would be very helpful... thosie specific features, such as python, gtk, gst, etc.
15:43 pbrobinson: jhbuild is maintained by silbe
15:43 mchua notes we seems to have shifted gears so walterbender has the floor on Activities, which is fine :) it was next on our list anyhow
15:43 sdziallas I think we need to clarify who's responsible for what there.
15:43 mchua walterbender: you have the floor - #info the high-level points you're making from the pov of Activities on how this release went
15:43 walterbender mchua: I wasn't intending to switch topics...
15:43 mchua walterbender: nah, it was time for the topic to switch :) go for it
15:44 #topic Activity development/inclusion perspective on the feature process
15:44 (and then it'll be SeanDaly's turn to talk about Marketing, and then satellit_ on testing)
15:44 walterbender I think that the POV of activities was all about changes (features) in Fedora that were not accounted for by the activity maintainers in a timely fashion
15:45 this IMHO led to much of the instability that led to much of the confusuion
15:45 garycmartin +1
15:45 pbrobinson walterbender: I think partially the Activity maintainers need to follow their upstream dependencies as well. EG Read -> evince. I try to keep track as much as possible and notify but I do miss some on occasion
15:45 SeanDaly I understand the coding-of-features process, but i'm concerned about its incompleteness re: meta objectives. But, quite possibly classic FOSS development is necessarily that way...
15:46 mchua SeanDaly: one sec, we'll get to marketing/metaobjectives in a sec
15:46 walterbender so from the POV of activities, if we can establish a definition of core libraries and dependencies to Sugar to track more closely, it would help the activity developers be more responsive
15:46 in v4
15:46 mchua walterbender: lemme see if I can summarize
15:46 sdziallas pbrobinson: that's a good point. I hear it was a gnome-evince-python lib upstream API change for 2.30 that wasn't specific to Fedora, but I might be wrong.
15:46 pbrobinson #info track core libraries and dependencies more closely
15:47 SeanDaly was responding to mchua's question I have 2 min or so time lag
15:47 pbrobinson no, the evince change was as part of the upcoming gnome 3
15:47 mchua SeanDaly: ah gotcha! you may want to queue up your notes on mktg though, it'll be your turn in a moment
15:47 pbrobinson its something we're going to need to track very closely for the next release as there's going to be a lot of churn
15:48 garycmartin Oh joy...
15:48 mchua walterbender: is this a fair summary? "Activity developers weren't informed of changes in the libraries their Activities depended on, when those libraries changed in Fedora (and thus got included in SoaS). This led to confusion and instability late in the cycle when Activity folks belatedly realized this had happened."
15:49 walterbender should have used a different example than read, like Browse :)
15:49 mchua: I am not pointing figures at Fedora... just that activity developers -- myself beign an example -- not as well tuned into upstream as I should be...
15:49 mchua walterbender: it sounds to me like two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn't realize that collision was coming, because we didn't track dependencies between then?
15:50 walterbender but since Fedora has to be tuned in... perhaps they can help us by bringing changes to our attention more xecplictly
15:50 mchua walterbender: well, it's nobody's fault and everyone's at the same time... sounds like part of the problem was that, like sdziallas pointed out, we didn't know who was responsible for keeping track of that
15:50 so everyone assumed it was someone else
15:51 #info Activity developers weren't informed of changes in the libraries their Activities depended on, when those libraries changed in Fedora (and thus got included in SoaS). This led to confusion and instability late in the cycle when Activity folks belatedly realized this had happened.
15:51 #info two of our upstreams (Fedora and ASLO) basically collided when they combined, and didn't realize that collision was coming, because we didn't track dependencies between them... part of the problem was that we didn't know who was responsible for keeping track of that aspect of communication, so everyone assumed it was someone else and nobody did it.
15:51 pbrobinson it would be good if we could enable a python option to close check the api and break the build if there's something missing
15:51 mchua pbrobinson: #idea
15:51 walterbender mchua: I raise the issue so that we can try to come up with a more efficient process going forward...
15:51 pbrobinson #idea  it would be good if we could enable a python option to close check the api and break the build if there's something missing / changed
15:52 mchua walterbender: does that sum up the problem from the Activities side? and then we can make sure we fix it for v4 when we plan that schedule out next week, make sure that responsibility is clear?
15:52 walterbender mchua: if the answer is, activity developers: pay attention, so be it.
15:52 mchua walterbender: yeah, I'm glad you brought that up - I hadn't even thought of it
15:52 didn't realize that had been a problem for Activity devs at all
15:52 walterbender mchua: it manifests itself in the small number of "supported" activities from the Fedora POV... SL needs to do better.
15:53 mchua looks at time - we still have SeanDaly and satellit_ queued up to talk, and I had a few more milestones I wanted to bring up - are people ok with extending the meeting 15 minutes? and then hard stop there?
15:53 walterbender is done...
15:53 mchua #info the Activities confusion manifests itself in the small number of "supported" activities in the v3 release
15:53 walterbender: thanks!
15:53 #info Marketing perspective on v3 feature/release process
15:53 SeanDaly: you're on.
15:54 tries to find what SeanDaly said earlier
15:54 SeanDaly ok my concern is that by the time I learned what was happening a couple of months ago, we were stuck
15:55 mchua SeanDaly mentioned above that he's concerned about the incompleteness of the current feature process (as run by Fedora and being adopted by SoaS) re: meta objectives. And notes that possibly classic FOSS development is necessarily that way... (but that doesn't mean we have to stick to it!)
15:55 SeanDaly: what do you mean by "what was happening" and "we were stuck"?
15:56 SeanDaly I clearly understood tech advantages esp. sustainibility, but we were in the alternate universe of marketing decides engineering executes;
15:56 this was engineering decides and marketing executes
15:57 pbrobinson SeanDaly: can you explain that differently, it doens't make sense to me
15:57 mchua nods, I'd like to hear what it looked like (this release cycle) from the marketing pov
15:57 SeanDaly if I had realized that e-readers kaput I could have alerted to higher priority
15:58 mchua since I think part of the disconnect is that pbrobinson and sdziallas and I were all looking at this from the engineering pov and didn't see it at all, hence disconnect
15:58 sdziallas nods. yup, I'd like to see how we can work on this.
15:58 mchua sits back to listen for a bit, will be afk but reading.
15:58 SeanDaly it's like this
15:59 pbrobinson SeanDaly: we only found out 2 days before release. We didn't know ourself. It built and we were very concerntrated on core issues
15:59 SeanDaly In the perceptions business, one way to entice is with features
15:59 sdziallas I don't think we a disagree there. ;)
16:00 SeanDaly I remember that mail from James Simmons that went unanswered :-(
16:00 but more than features is: fundamental promise
16:01 The fundamental promise of SoaS is: run Sugar on just about anything without touching hard disk
16:01 Now, I have no doubt Mirabelle will run better than its predecessors
16:02 But not clear how this fundamental promise is kept
16:02 pbrobinson doesn't see how the "fundamental promise" was broken in Mirabelle
16:03 SeanDaly this why SoaS creation kit so important
16:03 We have 2 very formidable barriers:
16:03 the unfamiliarity barrier -
16:04 and the installation barrier, which is a big deal for teachers
16:04 mchua SeanDaly: (specific examples and links to stuff help a lot here, too! we can also note things you're talking about (like James Simmons's email) and find links later when we write up a fuller review before next week's meeting)
16:04 satellit_ ASLO .xo files on USB for direct drag-drop install is a feature
16:04 SeanDaly on iPhone can' t easily link now
16:04 mchua SeanDaly: noted, that's why we've got others in the channel :)
16:05 battery dying, going over to somewhere with power - can someone #info Sean's high level points when he's done, and #link in what you can of what he's mentioning, so we make sure we're all grokking this summary correctly and that we have it in the minutes for posterify?
16:05 er, posterity, even.
16:05 SeanDaly satellit_: SoaS team wanted to restrict Activities to tested; sound engineering, but left out lots
16:05 mchua --> frantic dash for electricity, plz proceed
16:06 sdziallas mchua: I'll take care of that.
16:06 SeanDaly anyway to sum up I'd like to venture a revolutionary concept
16:07 that marketing not be "downstream" as in Fedora, but in the canoe
16:07 sdziallas SeanDaly: I'd like to have us #info your points: should we note the removal of activities?
16:07 listens.
16:08 (go ahead.)
16:08 SeanDaly sdziallas: yes that was the day Slobs meeting was cancelled and you an mchua said ok we have three activities
16:09 pbrobinson SeanDaly: that's fine but it needs to be achievable with a very small team and be stable and tested. People need to test as there's no point slapping any and all things in for the sake of it
16:09 sdziallas that was - I tested them - by that time what was working; looking at the Mirabelle state, I'm confident to say that we got better until the release date :)
16:10 SeanDaly i was also upset that marketing numbers became engineering numbers and we discarded our opportunity for large media launch of v3
16:11 pbrobinson doesn't think the tail should wag the dog
16:11 sdziallas #info marketing was confronted with removal of activities
16:11 SeanDaly probinson: unfortunately this wasn't adding features, it was learning feature regression :-(
16:12 probinson: yes, with tail being either engineering or marketing
16:12 pbrobinson SeanDaly: It was because things didn't work. People weren't testing them. This became very clear when 2 days before release Read was broken beyond repair and had been for 3 months!
16:13 SeanDaly: we were essentially a 1.5 person team. Both sdziallas and I had other massive commitments
16:13 SeanDaly probinson: how can I assist next time? organize testing sprints?
16:14 pbrobinson SeanDaly: that would be great
16:14 sdziallas SeanDaly: I think that'd be something which would help us quite a bit, yes! :)
16:15 I *think* from what I can see (correct me if I'm wrong) is that our issues come partly from the different projects we inherite from.
16:15 garycmartin Apologises for not putting in his usual test in hours, but had a client and needs to put food on the table.
16:15 satellit_ comments on testing?
16:15 sdziallas Because this requires a large amount of *communication*.
16:15 SeanDaly i believe volunteers including teachers can be found if "what to do" very clear
16:15 for testing
16:15 sdziallas satellit_: we'll get there, let's wrap this and put it in a nutshell and go on to testing then :)
16:15 #info sdziallas thinks what's really needed is communication
16:15 satellit_ : )
16:16 SeanDaly Clock ticking i have 1 more comment
16:16 pbrobinson SeanDaly: testing all activities is a good start. General functionality. I think laptop.org had a number of these defined that we could use
16:16 sdziallas the activity authors need to pay attention to their upstreams, the SoaS team needs to pull the strings together and talk to marketing and... okay, SeanDaly: go for it.
16:17 pbrobinson satellit_: was our real champ in the v3 release process
16:17 sdziallas #action SeanDaly talking about testing sprints for v.4
16:17 SeanDaly very concerned about communications strategy divergent on fedora spin Soas site
16:17 sdziallas #note marketing to be pulled early into the convos
16:17 SeanDaly i can't see how to avoid confusion
16:18 sdziallas (everybody, please #info and #note things if I missed anything above)
16:18 pbrobinson #info the activity authors need to pay attention to their upstreams, the SoaS team needs to pull the strings together and talk to marketing and...
16:18 sdziallas pbrobinson: thanks :)
16:18 SeanDaly convo=conversation?
16:18 sdziallas SeanDaly: yup!
16:18 SeanDaly ok i'm done
16:18 sdziallas SeanDaly: can you explain the spins page issue real quick?
16:19 (I'd like to give satellit_ the word on testing afterwards and then we should wrap up)
16:19 I'm just not sure I understand the point enough :)
16:19 (to #note it)
16:19 pbrobinson #action SoaS team to publish as much info as possible to the SoaS list so marketing are aware sooner rather than later
16:20 SeanDaly Yes - my suggestions of K-6 instead of K-8, and mention of XS server unheeded
16:20 But these are key marketing points
16:20 mchua back, haz power
16:20 reads backlog
16:21 we're over time, is everyone still ok with this?
16:21 SeanDaly generally speaking, minisite not a good idea
16:21 mchua would rather get everything out than cut it short, but also wants to be cognizant that people don't necessarily have infinite time for this :)
16:21 sdziallas mchua: SeanDaly just made his last point, I was about to give satellit_ the word on testing.
16:21 mchua catching up
16:21 nods, thanks sdziallas!
16:21 SeanDaly remember I opposed Caroline's minisite
16:22 sdziallas #note marketing prefers not to have spins page due to alternating content?
16:22 (does that put it in a nutshell?)
16:22 SeanDaly we need to draw contributors to SL site and wiki
16:22 because learning curve is steep
16:23 whiwh does'nt preclude presence elsewhere
16:23 mchua nods. SeanDaly, I did my best to reply to your points re: K-8 and XS on-list, we should continue that discussion if it wasn't clear there.
16:23 pbrobinson SeanDaly: so you want the wiki linked as well as SL main site on the SoaS spins page?
16:23 SeanDaly look at Sugar pages on OpenSUSE for example
16:23 pbrobinson SeanDaly: URL?
16:23 sdziallas (is everybody alright with the #note above?)
16:23 mchua I apologize for the spins page content being so last-minute notice too - we were all scrambling to hit deadlines there, and I appreciate you stepping in at the last minute to read over and send patches.
16:24 SeanDaly but problematic if not in phase with SL site :-( is all
16:24 mchua is confused by the #note - SeanDaly, not sure I understand the concern there yet.
16:24 sdziallas pbrobinson: I think we're linking to the wiki pages already.
16:24 SeanDaly ok can expound in detail later
16:25 sdziallas mchua: If I understand SeanDaly correctly, he says the spins.fp.o page is not a good idea if it doesn't contain the same information as the rest.
16:25 (rest being the wiki and stuff)
16:25 Is this an appropriate description? :) (if so, I'd like to head to testing real quick)
16:25 mchua hm, okay... I feel like we did try to keep that stuff in line with what was on the sl.o wiki and such, but can wait for SeanDaly to take the lead on a mailing list convo on this, I'd like to understand that perspective better
16:25 sdziallas (if not, let's adjust the #note)
16:25 mchua nods, +1 re moving onto testing
16:26 pbrobinson +1 on SeanDaly outlining this on list
16:27 sdziallas satellit_: your turn!
16:27 mchua SeanDaly, is that ok? that way you don't have to type on your iphone :)
16:27 satellit_ From a field testing POV (Building real Soas sticks from .iso files like a user)
16:27 sdziallas #topic testing in the mirabelle release cycle
16:27 satellit_ I see testing to have at least these Phases:* Basic functions* Applications (ASLO testing & integration)* Collaboration-(local-adhoc-xmpp-mesh
16:27 mchua would like to first thank satellit_ for his testing efforts for v3, *super* appreciated
16:27 sdziallas mchua: +1
16:27 mchua i think that's the first time we've had anything close to systematic testing coverage
16:27 and we still have a long way to go, but it's a better start than we have ever had
16:27 satellit_ : )
16:28 Jabber connection kept failing this made testing harder. I hope that this can be resolved.
16:28 pbrobinson mchua: +1
16:28 satellit_ There was a long period when no soas spins nightly composes worked (I did a daily build to USB if possible) when they did I had a problem: only script worked to make test USB sticks
16:28 liveinst did not work; zyx-liveinstaller did not work due to f13 changes. dmc gave up on it in April and finally with my pleading got it to work by may 8 (It was yum downloadable in f13 by may 20) Too LATE for Mirabelle!
16:29 wish If I had seen read problem sooner. we all assumed it has nothing to read!
16:29 sdziallas satellit_: yeah, it took us all a bit to realize that it was that serious... :)
16:29 mchua #info satellit_ did field-testing (building real SoaS sticks from .iso files and testing on those) - closest thing to systematic testing we've had yet, though we still have a ways to go
16:30 sdziallas satellit_: but you found a good chunk of issues with which we couldn't have released. thank you for that!
16:30 mchua #action SeanDaly to start discussion on multiple website (spins.fp.o, wiki.sl.o, etc.) divergence on-list
16:30 SeanDaly: (just so we don't forget ;)
16:30 satellit_ Activities-Index-ASLO.ods came from desire to use ASLO .xo on stick to test on running Soas without installing from web each time
16:30 mchua satellit_, one thing I do think we could have done better with in the v3 cycle was figuring out a better way to make changes based on your test results.
16:31 satellit_ I guess we need a central reporting site: (many threads on this)
16:31 mchua On my part, I wasn't always sure where to find the latest notes, or in what format, or what a test result meant - for instance, "X doesn't work" means "X was tested... in what way, exactly, that's reproducible in order to demonstrate the thing that doesn't work?"
16:31 nods
16:31 #idea Central test result reporting location
16:31 satellit_: that's a good idea
16:32 would be happy to help with suggestions on setting that up, used to run OLPC's community QA team some time back
16:32 satellit_ on wiki could we set up an editable form like it we all could add to and edit?
16:32 sdziallas I think we need to differenciate between the installed activities and the ones from a.sl.o.
16:32 mchua: hey, semantic-wiki-fu? ;)
16:32 mchua satellit_: Yeah, I've had some ideas on a semantic mediawiki based test case system for some time now (that would add form fields to the wiki) but never had time to implement it for SL... but perhaps that's something we could do if you're interested.
16:33 satellit_: that's a separate topic though :) but if you're keen on it, we could try setting it as a v4 goal, to have that up and running.
16:33 sdziallas: yep, you read my mind.
16:33 satellit_ +1 for common site
16:33 sdziallas alright, that's already an #action, right?
16:33 mchua satellit_: ok, ping me on the list when you have bandwidth to get started and we'll take it from there?
16:33 pbrobinson sdziallas: agreed. Its impossible to test them all and we can't fix the issues with a.sl.o activities. That's the responsibility of that maintainer
16:33 satellit_ Collaboration-(local-adhoc-xmpp-mesh)  need to be tested also
16:34 XO-1 0.82-0.88 interactions etc
16:34 mchua satellit_: Yeah, agreed - so basically, what I'm hearing here is "v3 didn't have a test plan, and it made things confusing for both testers and release engineering"
16:34 satellit_ +1
16:34 mchua no test plan == no list of all the things satellit_ is currently bringing up that we don't test well, and should
16:34 sdziallas #info v3 didn't have a test plan and it made things confusing for both testers and release engineering
16:34 #action fix that!
16:34 mchua grins
16:35 satellit_: anything else re: testing workflow?
16:35 oh, installation instructions... we did standardize on those, but i feel like the way they were decided upon was more a bludgeon than it should have been
16:35 less of a consensus than it could have been if we had started earlier.
16:35 sdziallas yup, we need to make these more prominently, too.
16:35 satellit_ Jabber must be available. also real installs to sticks from .iso are different. NC must be up
16:35 mchua because right now the only 2 "official" install methods we support are, iirc, liveusb-creator and unetbootin
16:36 satellit_: all good things to save for the v4 test cases.
16:36 sdziallas #note we need to make sure jabber.sl.o is up
16:36 satellit_ unetbootin has persistence?
16:36 sdziallas #action talk to daveb tomeu and others about ensuring that
16:36 pbrobinson I think it would be useful to look at the Fedora AutoQA project as well during the v4 process to see what we can automate
16:36 satellit_ trick edit icon for liveusb-creator  command --reset-mbr
16:37 mchua #idea look at Fedora AutoQA project to see what QA features we can automate
16:37 satellit_ It is usually needed
16:37 mchua I'm trying to step back from specific technical features here, concentrate on broad process and schedule
16:37 pbrobinson mchua: agreed.
16:38 mchua #info We standardized on official install methods (liveusb-creator, unetbootin) but this was done quickly without broad consensus so there's still friction about alternate methods that are out there.
16:38 satellit_ Sugar-Creation-Kit DVD  should be downloadable and linked to?
16:38 mchua satellit_: so, I think the DVD is a good example of something that's currently unofficial/unsupported because of our lack of a feature process
16:38 satellit_: we can link to it as a *draft* of something unofficial and unsupported - along with all the other experimental work
16:39 satellit_ Ok
16:39 pbrobinson mchua: 'alternate methods' maybe?
16:39 mchua but to make it a feature we can actually publicize and say "yes, this is part of the SoaS project," we need to figure out a way to do that, who's going to support it, etc.
16:39 (probably you, or whoever the feature maintainer is for any given feature ;)
16:39 satellit_ It is basically the wiki on a DVD
16:40 "sneakernet" or behind firewall at school  is my mind picture of use case
16:40 * should save bandwidth on servers.
16:40 * separate editions for V3/V2/XO-1 ?
16:40 mchua nods... satellit_, perhaps a good #action here for later is to look at the dvd you made as one of the features under consideration for v4, and figure that out together
16:40 (the feature process, I mean - it's not a bad first test case)
16:40 satellit_ all questions need discussion and guidance
16:41 mchua it may make it through for v4, it may not, but we'll learn a lot in the process, I'm guessing.
16:41 sdziallas mchua: yup yup!
16:41 mchua v4 is going to be our first deliberately planned release, aiui, so we'll undoubtedly be making tons of mistakes and learning a lot ;)
16:41 satellit_ thanks for the attention...: )
16:41 mchua #action satellit_ to bring up DVD as feature for consideration in v4, by way of figuring out the feature inclusion process
16:42 that should do it :)
16:42 anything else?
16:42 looks at time
16:42 sdziallas time to wrap up! *ring*
16:43 mchua so, ending on a happy note: what did people *like* about the v3 release process?
16:43 and the v3 releaes?
16:43 er, release?
16:43 other than "zomg, we made one and it functions!"?
16:43 sdziallas it's *shiny*. it's *yellow*. it works... well, er, mostly. It has over 300 downloads by now.
16:43 mchua #info things we liked!
16:43 pbrobinson mchua: its over :-D
16:43 mchua #undo
16:43 satellit_ It works nicely...)
16:43 mchua #topic Things we liked!
16:44 sdziallas pbrobinson: LOOOL :D
16:44 mchua #info it's *shiny*. it's *yellow*. it works... well, er, mostly. It has over 300 downloads by now
16:44 #info it's over :-D
16:44 #info It works nicely
16:44 #link http://lists.sugarlabs.org/arc[…]0-May/024203.html
16:44 sdziallas #info we actually made it.
16:44 mchua #link http://lists.sugarlabs.org/arc[…]0-May/010956.html
16:44 sdziallas #info we have a *team* :)
16:44 mchua #info (those links are compliments from Daniel and Simon)
16:44 #info we have a *release schedule*
16:45 sdziallas is s/300/350 by now.
16:45 pbrobinson #info the process from an engineering process was considerably smoother using the Fedora Spins process
16:45 mchua #info we started driving communications to public channels - notably the SoaS mailing list - so things are more transparent
16:45 sdziallas pbrobinson: I *don't* think that says a lot :P
16:45 mchua #info multiple people have commit access to each repository that needs to be handled, no single-person bottlenecks
16:45 (afaict)
16:46 pbrobinson sdziallas: its a start!
16:46 SeanDaly back on a computer
16:46 sdziallas waves :)
16:47 mchua SeanDaly: we're wrapping up - listing the things that were good about this release cycle
16:47 sdziallas (if any) :D
16:47 mchua #info we *had* a release cycle and a target release date set early in the process... it wasn't just a "uh, this seems ready to go now" sort of thing
16:47 time-based releases ftw - predictability is great.
16:47 sdziallas wonders if this is his gallows humor, heh.
16:48 SeanDaly mchua: predictability in marketing good for some things, nt for others :D
16:48 mchua :)
16:48 SeanDaly effect of surprise important to generate coverage for example ;-)
16:49 challenge is for surprises to be good ones :D
16:49 mchua right!
16:49 ok, any other notes, last-minute thoughts, things we've missed?
16:49 pbrobinson SeanDaly: gnome/fedora/ubuntu seem to use it to great advantage
16:49 mchua does anyone have something else to say that they don't fele like they've had a chance to say, that you're not already going to be taking to a mailing list convo?
16:50 garycmartin mchua: Where are all the ponies
16:50 sdziallas #action pick SoaS v.4 codename soon
16:50 garycmartin: ponyberry? :D
16:50 SeanDaly probinso: use what?
16:50 probinson: use what?
16:50 mchua #info we lack ponies in the v3 release. and pandas.
16:51 pbrobinson SeanDaly: a timed release
16:51 mchua garycmartin: a grievous oversight! we must remedy!
16:51 garycmartin sdziallas: And next set of colour combos for artwork.
16:51 mchua #action pick SoaS v.4 color combos soon
16:51 pbrobinson mchua: I have 2 ponies on the farm in aus. Does that help?
16:51 SeanDaly probinson: no beef with timed releases
16:51 mchua pbrobinson: Yes. Yes. They should be Ponyberry release mascots.
16:51 sdziallas garycmartin: yes. and thank *you* for helping with that (even sometimes on short notice) :)
16:52 garycmartin: it's really appreciated and helped a lot to take one thing to worry about away!
16:52 mchua I reckon we need to find a better way to sync with Design as well. :)
16:52 #idea sync with Design earlier in the release cycle for color-choosing, etc.
16:52 SeanDaly mchua: one more comment if I may?
16:52 pbrobinson votes for a release name that isn't a berry :-P
16:52 sdziallas pbrobinson: pony-belle?
16:52 mchua SeanDaly: go for it.
16:52 SeanDaly we haven't done media launch yet
16:52 mchua pbrobinson: technically speaking, mirabelle is a plum, not a berry.
16:52 therefore.
16:52 sdziallas listens.
16:53 mchua waiting for SeanDaly
16:53 SeanDaly probinson: original idea was ice cream flavours so a nonberry OK
16:53 m_anish (suggests Alphonso for v4 :-) )
16:53 pbrobinson mchua: yes, I know... but its still small and round :-)
16:53 SeanDaly mchua: just saying we can do Mirabelle media launch for LinuxTag
16:53 with focus on team, if y'all agree
16:53 pbrobinson SeanDaly: ah. you learn something every day. I thought it was suppose to suggest healthy eating with fruit :-P
16:54 sdziallas SeanDaly: I do. :)
16:54 SeanDaly pbrobinson: hee hee no sdz & I went for ice cream in a marketing meeting a year ago
16:54 pbrobinson SeanDaly: rum and raisin it is then :-P
16:55 SeanDaly pbrobinson: hee hee rum for kids :D
16:56 sdziallas okeydokey, I think that sounds awesome (not the rum, but... y'know)
16:56 pbrobinson SeanDaly: rum for the release engineers and marketing... raisins for the kids :-)
16:56 sdziallas SeanDaly: is tomorrow a marketing meeting taking place?
16:56 pbrobinson: :)
16:56 SeanDaly pbrobinson: :D
16:56 sdziallas: yes indeed we can
16:56 sdziallas pbrobinson: hope I don't count as kid anymore :P
16:57 pbrobinson sdziallas: in europe.... no. in the US... yes :-|
16:57 sdziallas SeanDaly: awesome! maybe we could work on that more then :)
16:57 pbrobinson: shhhht :)
16:57 mchua suggests cake batter
16:57 SeanDaly sdziallas: OK
16:58 mchua: cake batter ice cream?
16:58 mchua Hey, tabs! you're catching the end of the SoaS release review meeting here.
16:58 sdziallas waves to tabs!
16:58 mchua SeanDaly: yes!
16:58 tabs hi
16:58 mchua it is tasty.
16:58 SeanDaly greets tabs
16:58 sdziallas mchua: :)
16:58 mchua tabs, we had some good discussion about how testing went for v3 - we'll have logs of that up in a moment
16:58 sdziallas (should we wrap up?)
16:58 mchua (they'll get sent to the SoaS list, if you're on that)
16:58 we should, yeah.
16:58 it's almost 2 hours on the dot right now
16:59 tabs mchua: I am on that list
16:59 pbrobinson as a lead up to the v4 release I'd like to point out that there's a FUDCon in September in Zurich so it might be useful in the lead up to the release for a sugar/soas meetup
16:59 garycmartin Tabs == Tabitha?
16:59 tabs yes
16:59 i am tabitha
16:59 mchua tabs: excellent. it sounds like satellit_ will be working more on getting systematic testing up for v4, so hopefully you and the Welly testers can join us there :)
16:59 SeanDaly pbrobinson: could be interesting Zurich
16:59 mchua thinks we need better ways to tap the talent of the Welly testers - they've been doing awesome work for... what is it, 2 years now?
16:59 tabs We are in :-)
16:59 sdziallas mchua: actually, I still need to look at the teaching schedule re September...
16:59 mchua tabs: yay!
16:59 tabs Though we are also the Auckland testers now
16:59 sdziallas :)
16:59 mchua tabs: oh man, even better!
16:59 garycmartin tabs: Well a hi from me too, for all that NZ testing
17:00 mchua #action find ways to tap tabs and the Welly/Auckland testers for SoaS QA, 'cause they rock
17:00 #info there's a FUDCon in September in Zurich, we may want to look at that as a Sugar/SoaS meetup opportunity.
17:00 tabs James Cameron in Australia has been helping with testing
17:01 mchua SeanDaly: The media launch for Mirabelle - is that something we should take up in the Marketing meeting tomorrow? I want to make sure that convo thread doesn't drop.
17:01 #info thank you also to James Cameron in Australia for his testing help!
17:01 sdziallas pbrobinson: ouch, that'd be fun (re: FUDCon Zurich)
17:01 pbrobinson tabs: hi from a fellow down under person (from Aus originally, in London for the moment)
17:01 mchua Any other last-minute notes? we need to wrap up
17:01 already twice as long as we originally said :)
17:01 pbrobinson mchua: no I think we're done
17:01 sdziallas nods
17:01 mchua we can schedule another meeting between and now and next week's v4 planning session if needed.
17:01 SeanDaly mchua: yes, as I said to sdz
17:01 mchua Ok! I'll send minutes to the list in a moment.
17:02 SeanDaly: Awesome, thanks!
17:02 sdziallas awesome!
17:02 mchua #action SeanDaly taking Mirabelle media launch discussion up at Marketing meeting
17:02 aaaand ending in 5...
17:02 4...
17:02 sdziallas thanks folks!
17:02 mchua (thanks all!)
17:02 3...
17:02 sdziallas :)
17:02 mchua 2...
17:02 1..
17:02 sdziallas 0.5
17:02 mchua #endmeeting
11:46 lucian #topic is an abstraction/wrapper desirable?
11:46 mchua lucian: oh wait... I thought we were talking about the meeting time in 3.25 hours
11:46 walterbender lucian: I cannot image it not being desirable...
11:46 mchua (that's when the soas meeting is)
11:46 (not now)
11:47 lucian mchua: oh. then never mind, i'm just bad with international times :)
11:47 walterbender: several people have expressed concerns
11:47 maintainability was the most often quoted one
11:47 i've heard concerns about performance, but i'll just dismiss those
11:47 mchua lucian: oh, okay :) no conflict then. I have to go, but I'll read backscroll when I return.
11:47 (thanks for running this, it's a long overdue discussion!)
11:47 lucian mchua: ok, bye
11:49 walterbender: i don't have any experience making such wrappers reall
11:49 walterbender lucian: there are downsides, but the current situation is also unmaintainable and has us in a corner...
11:49 lucian walterbender: do you think it's feasible to maintain a wrapper?
11:50 walterbender maybe in the long term is it just a means of transitioning to a different base, e.g., webkit...
11:50 lucian if one of the backends were to be dropped entirely, would the extra work still be worthed?
11:50 walterbender but the current situation is unsustainable/maintainable
11:52 lucian: I haven't looked at the code, but it seems that if anything needs to be rewritten, then a rewrite on an abstraction layer is not adding a lot of additional work/overhead
11:52 lucian Surf already exists, but lacks many features
11:52 walterbender the only reason not to do it is if we make a definitive decision to stick with xul and don't anticipate that changing any time soon.
11:53 then application of minimal patches to the current code base would perhaps be best...
11:53 but either way, it seems we have a very fragile system that needs to be shored up.
11:53 lucian so in the short term, switching to webkit is "finishing Surf" vs "porting Browse"
11:54 walterbender where porting Browse would involve building an abstraction layer
11:54 (presumably)
11:54 lucian walterbender: yes, that seems the best choice
11:54 browse has many more features than surf, so it could be ported to webkit directly
11:54 but the extra work for an abstraction makes sense to me when it comes to browse
11:55 walterbender lucian: in theory, it should make the code cleaner and easier to maintain
11:56 lucian walterbender: assuming i get the abstraction layer right
11:56 tomeu webkitgtk+ devs have shown interest in helping out, btw
11:57 lucian tomeu: helping out in general? are they interested in a wrapper?
12:00 tomeu lucian: helping out in the way upstreams use to help: answering (good) questions, fixing bugs you find, reviewing any patches you come up with, etc
12:00 lucian tomeu: ah, ok. valuable help anyway
12:01 walterbender needs to disappear for a few minutes...
12:05 lucian tomeu: do you think this abstraction layer is a good idea?
12:06 tomeu lucian: it's a hard decision, that's why I asked about mozilla, if xulrunner is going to stop being available to us in distros, we have it out of the question
12:07 lucian tomeu: i'm trying the mozilla mailing list for more answers about that
12:08 tomeu lucian: awesome, you can try asking blizzard in gimpnet or irc.mozilla.org, he worked on sugar and is now in mozilla.org
12:08 lucian tomeu: ah, good
12:11 tomeu: so i see 3 choices
12:11 1) go ahead with the abstraction layer
12:11 2) port everything to webkit
12:12 3) stick with mozilla, get everything fixed and maintain it if needed
12:12 3 doesn't seem like an option anymore from what i've read
12:13 tomeu lucian: yes, but would be good to have some first hand information
12:13 sdziallas lucian: I'm by no means qualified to make any comment on this, but I'll try anyway. ;) I suppose it's a matter of figuring out whether (1) is just delaying the inevitably for a little bit and estimating the workload (1) would bring compared to (2).
12:13 tomeu I have only read rumours
12:14 lucian tomeu: yes, we need more info from mozilla folk
12:15 tomeu: also about webkit, it seems webkit devs are less hostile to gobject bindings, with lkcl calming down a bit
12:15 tomeu: i'll need to talk to pywebkitgtk folk some more, though
12:15 tomeu lucian: yeah, a colleague at collabora has been working on the dom bindings
12:15 lucian: may be better to go with pygi instead
12:16 lucian tomeu: that's not ready
12:16 tomeu lucian: and pywebkitgtk is not maintained ;)
12:16 lucian tomeu: true, i guess
12:16 tomeu we need to make some effort anyway
12:16 so we need to choose where is better to spend it
12:16 lucian i guess we're the only ones that need to embed web engines in python apps
12:17 tomeu lucian: for webkit's api, it may be there already
12:17 lucian tomeu: callbacks are the only big issue afaict
12:17 tomeu lucian: not really, what happens is that the move to g-i hasn't been sold properly to the python community
12:17 lucian tomeu: js uses a lot of events and they need to fire fast
12:17 tomeu lucian: but the python side will be catching so many events?
12:18 lucian tomeu: perhaps not quite so many, indeed
12:19 tomeu: there will be mostly setting up and getting results from the dom every now and then
12:19 tomeu lucian: so the earlier we test it, the earlier we'll be able to make an informed decision
12:20 I'm tryint o get distros to package pygi, in the meantime I would checkout the required modules into sugar's jhbuild
12:20 lucian tomeu: right. my last exam is on wednesday, the rest of this week i'll try and find out what would actually work
12:20 from the p.o.v. of upstreams
12:21 tomeu nice, we still need to get soem info before we can make the best decisions
12:23 lucian tomeu: fwiw, the pywebkitgtk activity log could look worse http://code.google.com/p/pywebkitgtk/updates/list
12:23 but it is a fragile situation nontheles
12:23 right, i'll guess that wraps it up
12:23 thanks walterbender tomeu sdziallas for your input
12:23 tomeu yeah, I was only talking about what I have heard, we should check that out as well
12:24 lucian #endmeeting

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

Powered by ilbot/Modified.