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

[Walter Bender]

On Mon, May 31, 2010 at 5:08 PM, Mel Chua <mel at melchua.com> wrote:
> 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.

It was a good discussion.

>
> 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

Cloudberry?

> [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

It didn't make the "action" list, but a discussion of how to keep the
activity developers better synced to changes would be appreciated.

-walter

> ---- 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
> _______________________________________________
> SoaS mailing list
> SoaS at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/soas
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org