[SoaS] Meeting minutes 2010-05-31 (v3 release review)

[Mel Chua]

This was a great v3 release retrospective meeting - full logs at 
http://me.etin.gs/sugar-meeting/sugar-meeting.log.20100531_1507.html and 
also pasted below. As a reminder, all meeting notes are available at 
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_meetings#Minutes.

It's a long discussion, but a good one and worth reading if you have the 
time. I'll start by pasting action items, then the full log.

We're still taking ideas/comments/feedback on the v3 release until 
Sunday night, since Monday at 1900 UTC is the v4 planning meeting. (Same 
place, same time, see 
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_meetings#Meeting_details 
for the permanent link to meeting how-to info).

Thank you for all who attended, and for those who are about to undertake 
the mammoth task of reading the logs below. :) If I have time, I'll try 
to work on a summary that's easier to read, but may not get to it (and 
very much welcome other people trying to beat me to the task).

--Mel

PS: Note that for future meetings, we'd love to have "pretty-notes" 
functionality available in the meeting bot - see 
http://bugs.sugarlabs.org/ticket/2026 if you're interested, help welcome!

---- Action items ----

[16:17:10] <sdziallas> #action SeanDaly talking about testing sprints 
for v.4
[16:19:38] <pbrobinson> #action SoaS team to publish as much info as 
possible to the SoaS list so marketing are aware sooner rather than later
[16:30:06] <mchua> #action SeanDaly to start discussion on multiple 
website (spins.fp.o, wiki.sl.o, etc.) divergence on-list
[16:34:49] <sdziallas> #action fix that! (v3 didn't have a test plan and 
it made things confusing for both testers and release engineering)
[16:36:26] <sdziallas> #action talk to daveb tomeu and others about 
ensuring that (we need to make sure jabber.sl.o is up)
[16:41:59] <mchua> #action satellit_ to bring up DVD as feature for 
consideration in v4, by way of figuring out the feature inclusion process
[16:50:29] <sdziallas> #action pick SoaS v.4 codename soon
[16:51:21] <mchua> #action pick SoaS v.4 color combos soon
[17:00:10] <mchua> #action find ways to tap tabs and the Welly/Auckland 
testers for SoaS QA, 'cause they rock
[17:02:11] <mchua> #action SeanDaly taking Mirabelle media launch 
discussion up at Marketing meeting

---- full log ----

Started logging meeting in #sugar-meeting, times are UTC.
[15:07:59] <mchua> #link 
http://wiki.sugarlabs.org/go/Sugar_on_a_Stick_meetings#Agenda
[15:08:18] <mchua> #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:39] <mchua> #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:01] <mchua> So what we're looking for here, really, is an hour 
(really 50 minutes now) of chronological brainspew, if that makes sense.
[15:09:09] <mchua> Seeing the release from as many different 
perspectives as possible.
[15:09:13] <mchua> Does that work for everyone?
[15:09:23] * sdziallas is +1 to that.
[15:09:36] <garycmartin> +1
[15:09:46] <satellit_> +1
[15:09:57] <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:06] <mchua> One month at a time, actually.
[15:10:13] <mchua> I'll put a link to the SoaS list archives here...
[15:10:41] <mchua> #link http://lists.sugarlabs.org/archive/soas/
[15:10:58] <mchua> Okay, we should start with November.
[15:11:01] <mchua> #topic November 2009
[15:11:28] <mchua> #info November 11, 2009 - Fedora (and therefore 
Fedora Spin) release cycle begins
[15:11:49] <mchua> #link 
http://lists.sugarlabs.org/archive/soas/2009-November/thread.html
[15:11:54] <mchua> (The first few months should be pretty quick)
[15:12:00] <sdziallas> Looks like we were having lots of funny decision 
panel convos back then.
[15:12:13] <mchua> Yeah, that's when we got the exclusive permission to 
use the SoaS name from SLOBs.
[15:12:25] <mchua> #info November 2009 - SLOBs declares the term "SoaS" 
to refer to this project
[15:12:26] <sdziallas> I'm really glad this is out of the way now.
[15:12:29] <mchua> That was important.
[15:12:41] <mchua> It also took WAY too long, imo, but I think SLOBs 
also learned a lot from the process.
[15:12:56] <mchua> Decision panels: we should... um... run them better.
[15:13:00] * SeanDaly lurking at dinner table with iPhone
[15:13:07] * sdziallas waves to SeanDaly
[15:13:08] <mchua> Hey, SeanDaly!
[15:13:26] <mchua> Anything else for November? I want to move quickly 
until we get to Feb or so.
[15:13:39] <sdziallas> I think we're good there.
[15:13:46] <mchua> #topic December
[15:13:51] <mchua> #topic December 2009
[15:13:53] <mchua> Whoops. There we go.
[15:14:04] <mchua> #link 
http://lists.sugarlabs.org/archive/soas/2009-December/thread.html
[15:14:05] <sdziallas> We're still talking Blueberry there, so we should 
move on.
[15:14:20] <sdziallas> Blueberry got released a little later than F12, 
hence the shorter cycle for Mirabelle.
[15:14:37] <mchua> Yeah, a lot of blueberry press here (mad props to 
SeanDaly and crew on that!)
[15:14:49] <mchua> sdziallas: should we just skip a bunch of months 
then? When do you reckon the Mirabelle release cycle actually started?
[15:15:16] <sdziallas> mchua: February is probably not too bad.
[15:15:17] <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:40] <mchua> Actually, January we got spin approval, so let's stop 
briefly there
[15:15:43] <mchua> #topic January 2010
[15:15:56] <mchua> #link 
http://lists.fedoraproject.org/pipermail/advisory-board/2010-January/007869.html
[15:16:14] <mchua> #info January 14, 2010 - Approval as a Fedora Spin
[15:16:18] <mchua> Now, this was pretty significant.
[15:16:23] <sdziallas> Yeah, right. That was important, but we should be 
good now.
[15:16:31] <mchua> sdziallas: can you talk a little about why this was a 
big deal, and what it entailed / what it meant?
[15:16:33] <sdziallas> The SIG needs to reapprove spins, but we've got 
trademark approval.
[15:16:47] <sdziallas> mchua: sure thing!
[15:17:08] <sdziallas> the whole Spin Process is what enables (and 
entitles) us to the advantages the cooperation with Fedora brings.
[15:17:09] <mchua> #link https://fedoraproject.org/wiki/Spins
[15:17:40] <mchua> #info "Spins are alternate versions of Fedora, 
tailored for various types of users via hand-picked application sets and 
other customizations."
[15:17:44] <sdziallas> (I think we covered the advantages for us 
regarding engineering and sustainability in a previous email)
[15:17:47] <mchua> #link http://spins.fedoraproject.org/about
[15:18:05] <sdziallas> This is significant, though, as the Feature 
Freeze (see agenda) was a hard deadline for this.
[15:18:10] <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:44] <mchua> #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:51] * SeanDaly wishes I knew what SIG meant
[15:19:00] <sdziallas> Special Interest Group (sorry)
[15:19:09] <sdziallas> there's a SIG in Fedora that takes care of the 
Spins :)
[15:19:13] <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:31] <mchua> So it was an approval process on the Fedora side that 
needed to happen.
[15:20:05] * SeanDaly is a SIG a decision committee?
[15:20:18] <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:32] <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:40] <pbrobinson> no, a SIG is a group of people with a special 
interest. Eg Sugar
[15:21:05] <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:15] <sdziallas> mchua: exactly! and we got automatic builds for 
testing! and... you made the point already :)
[15:21:33] <mchua> so we gained some instant automation of the 
infrastructure we need anyway, without any more work or maintenance on 
our part
[15:21:45] <mchua> so we could focus on things like... making Activities 
work, the stuff that's actually unique to Sugar.
[15:21:51] <mchua> so that was a *huge* win.
[15:21:59] <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:05] <sdziallas> s/yes/YES!!! :)
[15:22:11] <mchua> Before SoaS was a spin, it was a remix of Fedora.
[15:22:31] <mchua> 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:39] <mchua> it was just all done manually
[15:23:01] <mchua> and slowly, and without any help or support from 
anybody else, and resulted in... sleepless nights, aiui.
[15:23:16] <sdziallas> (which was why I was so hosed before the 
Blueberry launch... yup, exactly.)
[15:23:19] <pbrobinson> it required a lot of time and manual process
[15:23:40] <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:57] <mchua> it's like having someone come in and magically 
volunteer to cook/clean/mow-the-lawn/fix-the-plumbing
[15:24:20] <mchua> #link 
http://lists.sugarlabs.org/archive/soas/2010-January/thread.html
[15:24:41] <mchua> #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:59] <sdziallas> 
http://meeting.olpcorps.net/sugar-meeting/sugar-meeting.minutes.20100108_1109.html
[15:24:59] <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:03] <mchua> ...but we'll get to that later on.
[15:25:18] <sdziallas> we had a meeting about this, IIRC. but... yeah.
[15:25:21] <mchua> #link 
http://meeting.olpcorps.net/sugar-meeting/sugar-meeting.minutes.20100108_1109.html
[15:25:26] * SeanDaly has a cleaning lady who unplugs computers and routers
[15:25:28] <mchua> sdziallas: what's that meeting link, so I can #info it?
[15:25:32] <mchua> er, summary?
[15:25:45] <mchua> actually, I should just...
[15:25:53] <sdziallas> mchua: it comes from a SoaS planning meeting. I 
*think* that's when we moved towards the spin idea...
[15:25:55] <mchua> #chair sdziallas pbrobinson satellit_ SeanDaly 
garycmartin
[15:26:02] <mchua> sdziallas: now you can #info too.
[15:26:07] <sdziallas> awesome!
[15:26:29] <sdziallas> #info SoaS planning meeting lead to working on 
getting spin approved
[15:26:47] <mchua> Okay, moving on to Feb?
[15:26:51] <sdziallas> Yup!
[15:26:54] <mchua> (where the real fun starts)
[15:26:57] <mchua> #topic Feb 2010
[15:27:04] * garycmartin FWIW didn't know the diff between remix and spin.
[15:27:14] <mchua> #info 2010-02-09 Fedora Feature Freeze
[15:27:22] <mchua> garycmartin: yeah, that's our fault for not 
clarifying things
[15:27:25] <sdziallas> garycmartin: we failed at explaining that then :)
[15:27:35] * sdziallas notes the info line.
[15:27:38] <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:45] <sdziallas> We didn't really have a "feature process" for SoaS.
[15:27:57] <sdziallas> I think we should have. Or at least start talking 
features early in the release cycle.
[15:28:17] <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:18] <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:19] <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:23] <mchua> pbrobinson: good point.
[15:28:35] <mchua> #note folks need to speak up also when we start 
talking about things they don't understand!
[15:28:40] <mchua> garycmartin: so I'm glad you noted that above now :)
[15:28:47] <mchua> sdziallas: #info, plz
[15:28:54] <sdziallas> #info sdziallas thinks we should talk about 
features for v.4
[15:29:03] <sdziallas> mchua: I was just typing a note but made it an 
info. ;)
[15:29:08] <mchua> or #note or #agreed or 
#something-that-puts-meeting-minutes-up
[15:29:10] <mchua> worksforme.
[15:29:25] <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:41] <mchua> pbrobinson: how often?
[15:29:45] <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:52] <mchua> pbrobinson: you have chair, so feel free to #idea it 
too ;)
[15:30:03] <walterbender> mchua: independent of schedule, there is 
another related topic I'd like to mention...
[15:30:05] <sdziallas> mchua: could we get poelcat to CC the SoaS list 
on the devel announcements?
[15:30:15] <pbrobinson> mchua: not 100% sure, but fortnightly would 
probably be enough
[15:30:35] <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:40] <sdziallas> mchua: or it could just letter-me-later ;)
[15:30:56] <mchua> #idea send fortnightly release schedule emails to the 
SoaS list about upcoming milestones
[15:31:02] <sdziallas> mchua: marketing wouldn't be looking for things 
to promote because we'd have norrowed these down early.
[15:31:11] <pbrobinson> #idea regulart email the upcoming schedule and 
deadlines
[15:31:13] <sdziallas> and everybody would have worked on making these 
things happen instead of...
[15:31:17] <mchua> walterbender: Sure thing. Feel free to jump in any time.
[15:31:17] <walterbender> sdziallas: the issue from the Activity 
perspective was a bit less direct.
[15:31:24] <mchua> #chair walterbender
[15:31:34] <SeanDaly> Most nonfedorans don't know nuances of Fedora 
nomenclature... including journalists who cover FOSS...
[15:31:35] <sdziallas> ..."oh shit need feature?" - *implement* (or try to)
[15:31:54] <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:05] <walterbender> there were lots of Fedora changes that 
ultimately impacted activities regardless of "features"
[15:32:06] <mchua> Should we explain the feature process in Fedora briefly?
[15:32:19] <SeanDaly> sdziallas: marketers always very interested in 
features
[15:32:23] <mchua> for SeanDaly and others who may not be familiar with 
that part of how the schedule works?
[15:32:33] <walterbender> and fr some reason, in the run up to v3, those 
implications were not clear
[15:32:38] * mchua nods
[15:32:39] <pbrobinson> walterbender: most of the issues were GNOME and 
other upstream features and mostly not Fedora
[15:32:48] <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:48] <walterbender> so we had wholes, like the evince/Read debacle
[15:33:11] <pbrobinson> walterbender: that was upstream gnome.
[15:33:13] <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:17] <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:22] <mchua> and then hear walterbender on how it impacted Activities
[15:33:30] <mchua> and then SeanDaly on how he'd have liked to see it 
work out with Marketing
[15:33:33] <mchua> and then proceed
[15:33:34] <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:15] <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:21] <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:25] <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:43] <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:46] <mchua> walterbender: hang on a moment
[15:34:48] <SeanDaly> sdziallas: our problem is the disappearance of 
existing features, not looking for new ones
[15:34:53] <pbrobinson> walterbender: those issues weren't even know by 
us until a couple of days before release.
[15:35:01] <mchua> pbrobinson, SeanDaly, hang on a moment
[15:35:09] <mchua> I want to make sure everyone's on the same page wrt 
"what is the feature process, anyway?"
[15:35:21] <mchua> garycmartin: (you following ok? we're blazing past 
*tons* of Fedora-specific stuff right now)
[15:35:38] * mchua pulls out meeting chair hat. one at a time.
[15:35:46] <pbrobinson> #link https://fedoraproject.org/wiki/Features/Policy
[15:35:47] * sdziallas waves franctically to talk about sources of these 
issues. later. mchua is right.
[15:36:06] <garycmartin> mchua: Reading as fast as I can but half page 
backlog prevents me asking anything.
[15:36:07] <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:11] <mchua> pbrobinson: perfect
[15:36:13] <mchua> garycmartin: np
[15:36:37] <mchua> #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:49] <sdziallas> or not. and if they aren't, they are dropped.
[15:37:03] <sdziallas> not from inclusion, but they aren't mentioned as 
features explicitely.
[15:37:12] <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:18] <satellit_> This brings in testing can I say a few things?
[15:37:33] <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:39] <mchua> satellit_: yep, after SeanDaly
[15:37:39] <pbrobinson> #info feature freeze is in time for the alpha 
release
[15:37:42] * mchua queueing up the takling queue :)
[15:37:44] <mchua> er, talking queue
[15:38:15] <mchua> #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:17] <pbrobinson> so all major features but be in and be able to 
be tested by the alpha
[15:38:32] <pbrobinson> more minor ones can come along later but all 
have to be in by the beta release
[15:38:35] <sdziallas> so here's the thing about a feature process for SoaS:
[15:38:37] <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:42] * mchua nods
[15:38:46] <pbrobinson> after that point int time its bug fixing only
[15:39:09] <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:14] <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:27] <sdziallas> Books are such an example.
[15:39:41] <sdziallas> But I'm having a hard time coming up with lots of 
more.
[15:39:54] <sdziallas> Which is why I'm saying that KISS should work here.
[15:39:55] <garycmartin> So do folks consider activities as features
[15:40:03] <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:12] <sdziallas> (maybe I'm pushing too far here, though)
[15:40:15] <sdziallas> garycmartin: good point!
[15:40:25] <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:30] <mchua> so maybe that's our third upstream.
[15:40:35] <mchua> Fedora, SL (sugar-core), and ASLO.
[15:40:37] <sdziallas> I *think* we need to pull the upcoming Activity 
Inclusion criteria here out of the hat, mchua?
[15:41:02] <mchua> and nobody is really driving an Activity release 
process, afaict, but maybe walterbender can speak to that more
[15:41:07] <pbrobinson> mchua: SoaS also relies on upstream GNOME and 
python too
[15:41:28] <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:30] <mchua> #info SoaS upstreams: Fedora, Sugar Labs 
(sugar-core), ASLO (Activities), GNOME, python
[15:41:38] <walterbender> I am less concerned about activities as 
features than I am about changes that impact activities
[15:41:49] <sdziallas> #info Activity Inclusions Criteria to be 
finalized for v.4
[15:42:04] <pbrobinson> walterbender: who maintains the jhbuild system 
and the versions of packages that it uses?
[15:42:07] <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:38] <mchua> 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:43] <mchua> #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:44] <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:02] <walterbender> pbrobinson: jhbuild is maintained by silbe
[15:43:08] * 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:16] <sdziallas> I think we need to clarify who's responsible for 
what there.
[15:43:33] <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:37] <walterbender> mchua: I wasn't intending to switch topics...
[15:43:45] <mchua> walterbender: nah, it was time for the topic to 
switch :) go for it
[15:44:13] <mchua> #topic Activity development/inclusion perspective on 
the feature process
[15:44:29] <mchua> (and then it'll be SeanDaly's turn to talk about 
Marketing, and then satellit_ on testing)
[15:44:39] <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:16] <walterbender> this IMHO led to much of the instability that 
led to much of the confusuion
[15:45:52] <garycmartin> +1
[15:45:53] <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:55] <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:13] <mchua> SeanDaly: one sec, we'll get to 
marketing/metaobjectives in a sec
[15:46:18] <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:23] <walterbender> in v4
[15:46:36] <mchua> walterbender: lemme see if I can summarize
[15:46:50] <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:56] <pbrobinson> #info track core libraries and dependencies more 
closely
[15:47:06] * SeanDaly was responding to mchua's question I have 2 min or 
so time lag
[15:47:20] <pbrobinson> no, the evince change was as part of the 
upcoming gnome 3
[15:47:24] <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:44] <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:49] <garycmartin> Oh joy...
[15:48:54] <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:00] * walterbender should have used a different example than 
read, like Browse :)
[15:49:54] <walterbender> 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:55] <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:20] <walterbender> but since Fedora has to be tuned in... perhaps 
they can help us by bringing changes to our attention more xecplictly
[15:50:30] <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:37] <mchua> so everyone assumed it was someone else
[15:51:18] <mchua> #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:23] <mchua> #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:28] <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:33] <mchua> pbrobinson: #idea
[15:51:44] <walterbender> mchua: I raise the issue so that we can try to 
come up with a more efficient process going forward...
[15:51:59] <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:06] <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:07] <walterbender> mchua: if the answer is, activity developers: 
pay attention, so be it.
[15:52:13] <mchua> walterbender: yeah, I'm glad you brought that up - I 
hadn't even thought of it
[15:52:24] * mchua didn't realize that had been a problem for Activity 
devs at all
[15:52:58] <walterbender> mchua: it manifests itself in the small number 
of "supported" activities from the Fedora POV... SL needs to do better.
[15:53:13] * 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:21] * walterbender is done...
[15:53:33] <mchua> #info the Activities confusion manifests itself in 
the small number of "supported" activities in the v3 release
[15:53:36] <mchua> walterbender: thanks!
[15:53:43] <mchua> #info Marketing perspective on v3 feature/release process
[15:53:45] <mchua> SeanDaly: you're on.
[15:54:07] * mchua tries to find what SeanDaly said earlier
[15:54:44] <SeanDaly> ok my concern is that by the time I learned what 
was happening a couple of months ago, we were stuck
[15:55:08] <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:24] <mchua> SeanDaly: what do you mean by "what was happening" 
and "we were stuck"?
[15:56:50] <SeanDaly> I clearly understood tech advantages esp. 
sustainibility, but we were in the alternate universe of marketing 
decides engineering executes;
[15:56:55] <SeanDaly> this was engineering decides and marketing executes
[15:57:27] <pbrobinson> SeanDaly: can you explain that differently, it 
doens't make sense to me
[15:57:38] * mchua nods, I'd like to hear what it looked like (this 
release cycle) from the marketing pov
[15:57:46] <SeanDaly> if I had realized that e-readers kaput I could 
have alerted to higher priority
[15:58:01] <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:17] * sdziallas nods. yup, I'd like to see how we can work on this.
[15:58:18] * mchua sits back to listen for a bit, will be afk but reading.
[15:58:21] <SeanDaly> it's like this
[15:59:04] <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:05] <SeanDaly> In the perceptions business, one way to entice is 
with features
[15:59:36] <sdziallas> I don't think we a disagree there. ;)
[16:00:13] <SeanDaly> I remember that mail from James Simmons that went 
unanswered :-(
[16:00:59] <SeanDaly> but more than features is: fundamental promise
[16:01:15] <SeanDaly> The fundamental promise of SoaS is: run Sugar on 
just about anything without touching hard disk
[16:01:51] <SeanDaly> Now, I have no doubt Mirabelle will run better 
than its predecessors
[16:02:39] <SeanDaly> But not clear how this fundamental promise is kept
[16:02:45] * pbrobinson doesn't see how the "fundamental promise" was 
broken in Mirabelle
[16:03:19] <SeanDaly> this why SoaS creation kit so important
[16:03:23] <SeanDaly> We have 2 very formidable barriers:
[16:03:40] <SeanDaly> the unfamiliarity barrier -
[16:04:07] <SeanDaly> and the installation barrier, which is a big deal 
for teachers
[16:04:07] <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:30] <satellit_> ASLO .xo files on USB for direct drag-drop 
install is a feature
[16:04:37] * SeanDaly on iPhone can' t easily link now
[16:04:48] <mchua> SeanDaly: noted, that's why we've got others in the 
channel :)
[16:05:31] * mchua 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:37] <mchua> er, posterity, even.
[16:05:56] <SeanDaly> satellit_: SoaS team wanted to restrict Activities 
to tested; sound engineering, but left out lots
[16:05:59] * mchua --> frantic dash for electricity, plz proceed
[16:06:11] <sdziallas> mchua: I'll take care of that.
[16:06:33] <SeanDaly> anyway to sum up I'd like to venture a 
revolutionary concept
[16:07:13] <SeanDaly> that marketing not be "downstream" as in Fedora, 
but in the canoe
[16:07:32] <sdziallas> SeanDaly: I'd like to have us #info your points: 
should we note the removal of activities?
[16:07:51] * sdziallas listens.
[16:08:05] <sdziallas> (go ahead.)
[16:08:44] <SeanDaly> sdziallas: yes that was the day Slobs meeting was 
cancelled and you an mchua said ok we have three activities
[16:09:30] <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:43] <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:39] <SeanDaly> i was also upset that marketing numbers became 
engineering numbers and we discarded our opportunity for large media 
launch of v3
[16:11:08] * pbrobinson doesn't think the tail should wag the dog
[16:11:13] <sdziallas> #info marketing was confronted with removal of 
activities
[16:11:33] <SeanDaly> probinson: unfortunately this wasn't adding 
features, it was learning feature regression :-(
[16:12:20] <SeanDaly> probinson: yes, with tail being either engineering 
or marketing
[16:12:29] <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:19] <pbrobinson> SeanDaly: we were essentially a 1.5 person team. 
Both sdziallas and I had other massive commitments
[16:13:59] <SeanDaly> probinson: how can I assist next time? organize 
testing sprints?
[16:14:20] <pbrobinson> SeanDaly: that would be great
[16:14:35] <sdziallas> SeanDaly: I think that'd be something which would 
help us quite a bit, yes! :)
[16:15:10] <sdziallas> 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:17] <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:23] <satellit_> comments on testing?
[16:15:27] <sdziallas> Because this requires a large amount of 
*communication*.
[16:15:31] <SeanDaly> i believe volunteers including teachers can be 
found if "what to do" very clear
[16:15:36] <SeanDaly> for testing
[16:15:42] <sdziallas> satellit_: we'll get there, let's wrap this and 
put it in a nutshell and go on to testing then :)
[16:15:58] <sdziallas> #info sdziallas thinks what's really needed is 
communication
[16:15:58] <satellit_> : )
[16:16:34] <SeanDaly> Clock ticking i have 1 more comment
[16:16:37] <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:48] <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:00] <pbrobinson> satellit_: was our real champ in the v3 release 
process
[16:17:10] <sdziallas> #action SeanDaly talking about testing sprints 
for v.4
[16:17:19] <SeanDaly> very concerned about communications strategy 
divergent on fedora spin Soas site
[16:17:41] <sdziallas> #note marketing to be pulled early into the convos
[16:17:53] <SeanDaly> i can't see how to avoid confusion
[16:18:06] <sdziallas> (everybody, please #info and #note things if I 
missed anything above)
[16:18:14] <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:33] <sdziallas> pbrobinson: thanks :)
[16:18:39] <SeanDaly> convo=conversation?
[16:18:44] <sdziallas> SeanDaly: yup!
[16:18:44] <SeanDaly> ok i'm done
[16:18:57] <sdziallas> SeanDaly: can you explain the spins page issue 
real quick?
[16:19:09] <sdziallas> (I'd like to give satellit_ the word on testing 
afterwards and then we should wrap up)
[16:19:31] <sdziallas> I'm just not sure I understand the point enough :)
[16:19:37] <sdziallas> (to #note it)
[16:19:38] <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:17] <SeanDaly> Yes - my suggestions of K-6 instead of K-8, and 
mention of XS server unheeded
[16:20:42] <SeanDaly> But these are key marketing points
[16:20:55] * mchua back, haz power
[16:20:57] * mchua reads backlog
[16:21:06] <mchua> we're over time, is everyone still ok with this?
[16:21:21] <SeanDaly> generally speaking, minisite not a good idea
[16:21:29] * 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:31] <sdziallas> mchua: SeanDaly just made his last point, I was 
about to give satellit_ the word on testing.
[16:21:32] * mchua catching up
[16:21:37] * mchua nods, thanks sdziallas!
[16:21:46] <SeanDaly> remember I opposed Caroline's minisite
[16:22:01] <sdziallas> #note marketing prefers not to have spins page 
due to alternating content?
[16:22:08] <sdziallas> (does that put it in a nutshell?)
[16:22:23] <SeanDaly> we need to draw contributors to SL site and wiki
[16:22:43] <SeanDaly> because learning curve is steep
[16:23:21] <SeanDaly> whiwh does'nt preclude presence elsewhere
[16:23:29] * 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:42] <pbrobinson> SeanDaly: so you want the wiki linked as well as 
SL main site on the SoaS spins page?
[16:23:44] <SeanDaly> look at Sugar pages on OpenSUSE for example
[16:23:56] <pbrobinson> SeanDaly: URL?
[16:23:57] <sdziallas> (is everybody alright with the #note above?)
[16:23:57] <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:10] <SeanDaly> but problematic if not in phase with SL site :-( 
is all
[16:24:15] * mchua is confused by the #note - SeanDaly, not sure I 
understand the concern there yet.
[16:24:24] <sdziallas> pbrobinson: I think we're linking to the wiki 
pages already.
[16:24:46] <SeanDaly> ok can expound in detail later
[16:25:07] <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:18] <sdziallas> (rest being the wiki and stuff)
[16:25:42] <sdziallas> Is this an appropriate description? :) (if so, 
I'd like to head to testing real quick)
[16:25:45] <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:50] <sdziallas> (if not, let's adjust the #note)
[16:25:50] * mchua nods, +1 re moving onto testing
[16:26:21] * pbrobinson +1 on SeanDaly outlining this on list
[16:27:02] <sdziallas> satellit_: your turn!
[16:27:06] <mchua> SeanDaly, is that ok? that way you don't have to type 
on your iphone :)
[16:27:15] <satellit_> From a field testing POV (Building real Soas 
sticks from .iso files like a user)
[16:27:17] <sdziallas> #topic testing in the mirabelle release cycle
[16:27:32] <satellit_> I see testing to have at least these Phases:* 
Basic functions* Applications (ASLO testing & integration)* 
Collaboration-(local-adhoc-xmpp-mesh
[16:27:36] * mchua would like to first thank satellit_ for his testing 
efforts for v3, *super* appreciated
[16:27:42] <sdziallas> mchua: +1
[16:27:45] <mchua> i think that's the first time we've had anything 
close to systematic testing coverage
[16:27:56] <mchua> and we still have a long way to go, but it's a better 
start than we have ever had
[16:27:57] <satellit_> : )
[16:28:03] <satellit_> Jabber connection kept failing this made testing 
harder. I hope that this can be resolved.
[16:28:04] <pbrobinson> mchua: +1
[16:28:20] <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:20] <satellit_> 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:01] <satellit_> wish If I had seen read problem sooner. we all 
assumed it has nothing to read!
[16:29:21] <sdziallas> satellit_: yeah, it took us all a bit to realize 
that it was that serious... :)
[16:29:25] <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:04] <sdziallas> satellit_: but you found a good chunk of issues 
with which we couldn't have released. thank you for that!
[16:30:06] <mchua> #action SeanDaly to start discussion on multiple 
website (spins.fp.o, wiki.sl.o, etc.) divergence on-list
[16:30:12] <mchua> SeanDaly: (just so we don't forget ;)
[16:30:32] <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:52] <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:34] <satellit_> I guess we need a central reporting site: (many 
threads on this)
[16:31:37] <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:42] * mchua nods
[16:31:45] <mchua> #idea Central test result reporting location
[16:31:47] <mchua> satellit_: that's a good idea
[16:32:12] * mchua would be happy to help with suggestions on setting 
that up, used to run OLPC's community QA team some time back
[16:32:18] <satellit_> on wiki could we set up an editable form like it 
we all could add to and edit?
[16:32:28] <sdziallas> I think we need to differenciate between the 
installed activities and the ones from a.sl.o.
[16:32:37] <sdziallas> mchua: hey, semantic-wiki-fu? ;)
[16:32:55] <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:12] <mchua> 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:16] <mchua> sdziallas: yep, you read my mind.
[16:33:16] <satellit_> +1 for common site
[16:33:46] <sdziallas> alright, that's already an #action, right?
[16:33:51] <mchua> satellit_: ok, ping me on the list when you have 
bandwidth to get started and we'll take it from there?
[16:33:54] <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:55] <satellit_> Collaboration-(local-adhoc-xmpp-mesh) need to be 
tested also
[16:34:16] <satellit_> XO-1 0.82-0.88 interactions etc
[16:34:19] <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:31] <satellit_> +1
[16:34:41] <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:44] <sdziallas> #info v3 didn't have a test plan and it made 
things confusing for both testers and release engineering
[16:34:49] <sdziallas> #action fix that!
[16:34:52] * mchua grins
[16:35:00] <mchua> satellit_: anything else re: testing workflow?
[16:35:24] <mchua> 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:35] <mchua> less of a consensus than it could have been if we had 
started earlier.
[16:35:43] <sdziallas> yup, we need to make these more prominently, too.
[16:35:52] <satellit_> Jabber must be available. also real installs to 
sticks from .iso are different. NC must be up
[16:35:52] <mchua> because right now the only 2 "official" install 
methods we support are, iirc, liveusb-creator and unetbootin
[16:36:00] <mchua> satellit_: all good things to save for the v4 test cases.
[16:36:14] <sdziallas> #note we need to make sure jabber.sl.o is up
[16:36:14] <satellit_> unetbootin has persistence?
[16:36:26] <sdziallas> #action talk to daveb tomeu and others about 
ensuring that
[16:36:44] <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:56] <satellit_> trick edit icon for liveusb-creator command 
--reset-mbr
[16:37:03] <mchua> #idea look at Fedora AutoQA project to see what QA 
features we can automate
[16:37:04] <satellit_> It is usually needed
[16:37:20] <mchua> I'm trying to step back from specific technical 
features here, concentrate on broad process and schedule
[16:37:35] <pbrobinson> mchua: agreed.
[16:38:02] <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:06] <satellit_> Sugar-Creation-Kit DVD should be downloadable and 
linked to?
[16:38:29] <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:49] <mchua> satellit_: we can link to it as a *draft* of 
something unofficial and unsupported - along with all the other 
experimental work
[16:39:05] <satellit_> Ok
[16:39:07] <pbrobinson> mchua: 'alternate methods' maybe?
[16:39:20] <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:31] <mchua> (probably you, or whoever the feature maintainer is 
for any given feature ;)
[16:39:48] <satellit_> It is basically the wiki on a DVD
[16:40:25] <satellit_> "sneakernet" or behind firewall at school is my 
mind picture of use case
[16:40:26] <satellit_> * should save bandwidth on servers.
[16:40:26] <satellit_> * separate editions for V3/V2/XO-1 ?
[16:40:37] * 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:52] <mchua> (the feature process, I mean - it's not a bad first 
test case)
[16:40:55] <satellit_> all questions need discussion and guidance
[16:41:04] <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:19] <sdziallas> mchua: yup yup!
[16:41:29] <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:44] <satellit_> thanks for the attention...: )
[16:41:59] <mchua> #action satellit_ to bring up DVD as feature for 
consideration in v4, by way of figuring out the feature inclusion process
[16:42:03] <mchua> that should do it :)
[16:42:05] <mchua> anything else?
[16:42:11] * mchua looks at time
[16:42:59] <sdziallas> time to wrap up! *ring*
[16:43:21] <mchua> so, ending on a happy note: what did people *like* 
about the v3 release process?
[16:43:24] <mchua> and the v3 releaes?
[16:43:24] <mchua> er, release?
[16:43:33] <mchua> other than "zomg, we made one and it functions!"?
[16:43:47] <sdziallas> it's *shiny*. it's *yellow*. it works... well, 
er, mostly. It has over 300 downloads by now.
[16:43:50] <mchua> #info things we liked!
[16:43:53] <pbrobinson> mchua: its over :-D
[16:43:54] <mchua> #undo
[16:43:55] <satellit_> It works nicely...)
[16:43:58] <mchua> #topic Things we liked!
[16:44:00] <sdziallas> pbrobinson: LOOOL :D
[16:44:08] <mchua> #info it's *shiny*. it's *yellow*. it works... well, 
er, mostly. It has over 300 downloads by now
[16:44:14] <mchua> #info it's over :-D
[16:44:19] <mchua> #info It works nicely
[16:44:29] <mchua> #link 
http://lists.sugarlabs.org/archive/sugar-devel/2010-May/024203.html
[16:44:31] <sdziallas> #info we actually made it.
[16:44:40] <mchua> #link 
http://lists.sugarlabs.org/archive/iaep/2010-May/010956.html
[16:44:42] <sdziallas> #info we have a *team* :)
[16:44:49] <mchua> #info (those links are compliments from Daniel and Simon)
[16:44:59] <mchua> #info we have a *release schedule*
[16:45:00] * sdziallas is s/300/350 by now.
[16:45:20] <pbrobinson> #info the process from an engineering process 
was considerably smoother using the Fedora Spins process
[16:45:22] <mchua> #info we started driving communications to public 
channels - notably the SoaS mailing list - so things are more transparent
[16:45:38] <sdziallas> pbrobinson: I *don't* think that says a lot :P
[16:45:55] <mchua> #info multiple people have commit access to each 
repository that needs to be handled, no single-person bottlenecks
[16:45:59] <mchua> (afaict)
[16:46:00] <pbrobinson> sdziallas: its a start!
[16:46:22] * SeanDaly back on a computer
[16:46:26] * sdziallas waves :)
[16:47:05] <mchua> SeanDaly: we're wrapping up - listing the things that 
were good about this release cycle
[16:47:17] <sdziallas> (if any) :D
[16:47:24] <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:36] <mchua> time-based releases ftw - predictability is great.
[16:47:44] * sdziallas wonders if this is his gallows humor, heh.
[16:48:25] <SeanDaly> mchua: predictability in marketing good for some 
things, nt for others :D
[16:48:43] <mchua> :)
[16:48:47] <SeanDaly> effect of surprise important to generate coverage 
for example ;-)
[16:49:05] <SeanDaly> challenge is for surprises to be good ones :D
[16:49:09] <mchua> right!
[16:49:22] <mchua> ok, any other notes, last-minute thoughts, things 
we've missed?
[16:49:51] <pbrobinson> SeanDaly: gnome/fedora/ubuntu seem to use it to 
great advantage
[16:49:52] <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:07] <garycmartin> mchua: Where are all the ponies
[16:50:29] <sdziallas> #action pick SoaS v.4 codename soon
[16:50:34] <sdziallas> garycmartin: ponyberry? :D
[16:50:40] <SeanDaly> probinso: use what?
[16:50:49] <SeanDaly> probinson: use what?
[16:50:58] <mchua> #info we lack ponies in the v3 release. and pandas.
[16:51:00] <pbrobinson> SeanDaly: a timed release
[16:51:04] <mchua> garycmartin: a grievous oversight! we must remedy!
[16:51:07] <garycmartin> sdziallas: And next set of colour combos for 
artwork.
[16:51:21] <mchua> #action pick SoaS v.4 color combos soon
[16:51:22] <pbrobinson> mchua: I have 2 ponies on the farm in aus. Does 
that help?
[16:51:31] <SeanDaly> probinson: no beef with timed releases
[16:51:32] <mchua> pbrobinson: Yes. Yes. They should be Ponyberry 
release mascots.
[16:51:37] <sdziallas> garycmartin: yes. and thank *you* for helping 
with that (even sometimes on short notice) :)
[16:52:01] <sdziallas> garycmartin: it's really appreciated and helped a 
lot to take one thing to worry about away!
[16:52:01] <mchua> I reckon we need to find a better way to sync with 
Design as well. :)
[16:52:09] <mchua> #idea sync with Design earlier in the release cycle 
for color-choosing, etc.
[16:52:13] <SeanDaly> mchua: one more comment if I may?
[16:52:13] * pbrobinson votes for a release name that isn't a berry :-P
[16:52:23] <sdziallas> pbrobinson: pony-belle?
[16:52:25] <mchua> SeanDaly: go for it.
[16:52:26] <SeanDaly> we haven't done media launch yet
[16:52:35] <mchua> pbrobinson: technically speaking, mirabelle is a 
plum, not a berry.
[16:52:37] <mchua> therefore.
[16:52:42] * sdziallas listens.
[16:53:00] * mchua waiting for SeanDaly
[16:53:02] <SeanDaly> probinson: original idea was ice cream flavours so 
a nonberry OK
[16:53:09] * m_anish (suggests Alphonso for v4 :-) )
[16:53:09] <pbrobinson> mchua: yes, I know... but its still small and 
round :-)
[16:53:24] <SeanDaly> mchua: just saying we can do Mirabelle media 
launch for LinuxTag
[16:53:35] <SeanDaly> with focus on team, if y'all agree
[16:53:54] <pbrobinson> SeanDaly: ah. you learn something every day. I 
thought it was suppose to suggest healthy eating with fruit :-P
[16:54:13] <sdziallas> SeanDaly: I do. :)
[16:54:36] <SeanDaly> pbrobinson: hee hee no sdz & I went for ice cream 
in a marketing meeting a year ago
[16:54:55] <pbrobinson> SeanDaly: rum and raisin it is then :-P
[16:55:35] <SeanDaly> pbrobinson: hee hee rum for kids :D
[16:56:18] <sdziallas> okeydokey, I think that sounds awesome (not the 
rum, but... y'know)
[16:56:25] <pbrobinson> SeanDaly: rum for the release engineers and 
marketing... raisins for the kids :-)
[16:56:25] <sdziallas> SeanDaly: is tomorrow a marketing meeting taking 
place?
[16:56:33] <sdziallas> pbrobinson: :)
[16:56:37] <SeanDaly> pbrobinson: :D
[16:56:49] <SeanDaly> sdziallas: yes indeed we can
[16:56:49] <sdziallas> pbrobinson: hope I don't count as kid anymore :P
[16:57:18] <pbrobinson> sdziallas: in europe.... no. in the US... yes :-|
[16:57:38] <sdziallas> SeanDaly: awesome! maybe we could work on that 
more then :)
[16:57:43] <sdziallas> pbrobinson: shhhht :)
[16:57:53] * mchua suggests cake batter
[16:57:54] <SeanDaly> sdziallas: OK
[16:58:08] <SeanDaly> mchua: cake batter ice cream?
[16:58:08] <mchua> Hey, tabs! you're catching the end of the SoaS 
release review meeting here.
[16:58:15] * sdziallas waves to tabs!
[16:58:17] <mchua> SeanDaly: yes!
[16:58:17] <tabs> hi
[16:58:19] <mchua> it is tasty.
[16:58:21] * SeanDaly greets tabs
[16:58:23] <sdziallas> mchua: :)
[16:58:43] <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:49] <sdziallas> (should we wrap up?)
[16:58:50] <mchua> (they'll get sent to the SoaS list, if you're on that)
[16:58:54] <mchua> we should, yeah.
[16:58:59] <mchua> it's almost 2 hours on the dot right now
[16:59:00] <tabs> mchua: I am on that list
[16:59:06] <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:11] <garycmartin> Tabs == Tabitha?
[16:59:15] <tabs> yes
[16:59:19] <tabs> i am tabitha
[16:59:21] <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:39] <SeanDaly> pbrobinson: could be interesting Zurich
[16:59:41] * 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:42] <tabs> We are in :-)
[16:59:46] <sdziallas> mchua: actually, I still need to look at the 
teaching schedule re September...
[16:59:47] <mchua> tabs: yay!
[16:59:50] <tabs> Though we are also the Auckland testers now
[16:59:53] <sdziallas> :)
[16:59:56] <mchua> tabs: oh man, even better!
[16:59:58] <garycmartin> tabs: Well a hi from me too, for all that NZ 
testing
[17:00:10] <mchua> #action find ways to tap tabs and the Welly/Auckland 
testers for SoaS QA, 'cause they rock
[17:00:37] <mchua> #info there's a FUDCon in September in Zurich, we may 
want to look at that as a Sugar/SoaS meetup opportunity.
[17:00:50] <tabs> James Cameron in Australia has been helping with testing
[17:01:10] <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:20] <mchua> #info thank you also to James Cameron in Australia 
for his testing help!
[17:01:26] <sdziallas> pbrobinson: ouch, that'd be fun (re: FUDCon Zurich)
[17:01:26] <pbrobinson> tabs: hi from a fellow down under person (from 
Aus originally, in London for the moment)
[17:01:34] <mchua> Any other last-minute notes? we need to wrap up
[17:01:40] <mchua> already twice as long as we originally said :)
[17:01:46] <pbrobinson> mchua: no I think we're done
[17:01:50] * sdziallas nods
[17:01:53] <mchua> we can schedule another meeting between and now and 
next week's v4 planning session if needed.
[17:01:56] <SeanDaly> mchua: yes, as I said to sdz
[17:01:58] <mchua> Ok! I'll send minutes to the list in a moment.
[17:02:01] <mchua> SeanDaly: Awesome, thanks!
[17:02:03] <sdziallas> awesome!
[17:02:11] <mchua> #action SeanDaly taking Mirabelle media launch 
discussion up at Marketing meeting
[17:02:14] <mchua> aaaand ending in 5...
[17:02:15] <mchua> 4...
[17:02:15] <sdziallas> thanks folks!
[17:02:17] <mchua> (thanks all!)
[17:02:18] <mchua> 3...
[17:02:19] <sdziallas> :)
[17:02:20] <mchua> 2...
[17:02:23] <mchua> 1..
[17:02:24] <sdziallas> 0.5
[17:02:25] <mchua> #endmeeting