[IAEP] Upstream/downstream relationships
mel at melchua.com
Sun Jul 19 21:42:12 EDT 2009
Background: I happened to catch the end of a #sugar-meeting discussion
between Caroline, Sebastian, Tomeu, and Simon (hopefully I haven't
missed anyone) about the frustration of figuring out ways to work with
upstream and downstream, and which projects played what roles (is Sugar
upstream of SoaS? Is SoaS a separate project? Who provides
user/deployment support? etc.)
Tomeu requested that we move this discussion to a mailing list. This is
my reply to Caroline's email explaining her frustrations. In this email,
I'm trying to summarize what I perceive as the sense of the conversation
in order to get everyone on the same page.
> I guess for me I got frustrated when Fedora bugs were closed and I got
> the feeling that because the bugs were not in Sugar that there was a
> feeling that they were hopeless and/or no one cared or something.
Here's what I think I'm hearing (implied) right now.
1. A person can be both a Sugar person and a Fedora person.
2. As a Sugar person, someone should only have to care about a Fedora
bug to the extent that Sugar relies upon Fedora as an upstream option
(one of multiple options, because Sugar should be OS-independent).
3. It's the responsibility of Fedora people who care about Sugar using
Fedora to be a responsive upstream by caring about and taking action on
the Fedora bugs that the Sugar community reports.
It sounds like #3 might be a little shaky right now - working, but not
in a way that makes you feel comfortable that it will continue working
well enough to not block you at some point.
> I think what I want to happen is what actually did happen. When we
> identify a bug that is in Fedora, we work with Fedora to track it down,
> then we do two things. 1. Figure out a work around for people who need
> to make it work now. 2. Get the fix pushed into Fedora then pushed into
> Sugar. Bernie helped me with working with Fedora.
Ok - so the ideal process would go something like this? (Not specific to
Fedora, but I'll use it here as an example.)
Teacherperson: "Oh noes, problem!"
Sugarperson: "Teacherperson, I got it! Hey, Fedoraperson! There's a bug
in Fedora that blocks Teacherperson from doing something cool with
Sugar. I filed it in your system as #fedorabug (and set up a #sugarbug
ticket in my system to remind us to watch this in our weekly "check up
on upstream bugs" pass in the Sugar dev team meeting)."
Fedoraperson: "Thanks, Sugarperson - we're on it, #fedorabug is tagged
to make sure we watch this in the Sugar SIG's weekly "check up on sugar
bugs" pass. Here are the steps we're going to go through, here's how
long we think it might take, we won't necessarily be the one making the
patch but we'll be your contact point about it."
Sugarperson: "Thanks, Fedoraperson! Teacherperson, I'm going to make a
temporary workaround for you in the meantime. Fedoraperson, I'll come
back and ask every week if the bug's fixed."
*a week later*
Sugarperson: "Hey Fedoraperson, what's the #fedorabug status?"
Fedoraperson: "Not yet, Sugarperson; we've done $foo and we still need
to do $bar."
Sugarperson: "Ok, Teacherperson, we will continue to use the workaround."
*repeat for multiple weeks as needed, hopefully not too many*
Sugarperson: "Fedoraperson, #fedorabug status?"
Fedoraperson: "Sugarperson, #fedorabug is closed! Here's how to make
sure it works for Teacherperson, see if this is ok or whether we need to
reopen or make a new ticket."
Sugarperson: "Teacherperson, let's try this out. Hurrah, things work
now, thanks Fedoraperson! I am closing #sugarbug. Teacherperson,
Fedoraperson fixed this for you!"
Teacherperson: "Yes, thank you, Fedoraperson! Here is what I was able to
do as a result of you fixing this bug."
Fedoraperson: "Awesome, Teacherperson, Sugarperson! Glad we could help."
>> I think we are moving the right direction on this but I'm not sure if we
>> are there yet.
If the scenario above sounds like "the right direction," here are the
things that could happen to move us towards that. (Not all the ideas are
good, and some of them exist in partial form already.)
* the Sugar dev team puts a "check upstream bugs" item in place during
their weekly meeting agendas, and assigns someone each week to find the
status of Sugar blocking bugs in each upstream project.
* Fedora should be on the list of "upstreams" to check bug status in
* Some person or entity on the Fedora side should be poking through the
list of bugs-reported-by-Sugar each week to try and fix them or get them
fixed. There is a Fedora OLPC SIG; I am not sure how explicitly it
includes Sugar, but that seems like the logical place to start.
* Some person or entity on the Fedora side should be updating a status
page on the bugs-reported-by-Sugar each week so that the Sugar volunteer
assigned to find the status of upstream bugs can just look at that page
for this particular upstream. This page could be a bugzilla query with a
timestamp to say "last updated on $date."
* the Sugar dev team likewise updates a similar status page weekly.
* someone in Sugar (perhaps someone from the dev team, perhaps someone
from the education team) translates the Sugar development status page
into updates for the individual teachers waiting for a bug to be fixed
or a feature to be deveoped.
This comes from some of Caroline's comments:
> and for there to be an easy place to see the status of problems as they
> work their way through this process, which may take over a month or
> two. I would especially like for the issue to not be "closed" until its
> actually fixed for Sugar users.
> We also need a process that is not going to send teachers running
> screaming. That may mean hiding some of it behind a curtain and having
> volunteers move things to the next level.
As usual, stuff is only going to happen and change if folks step up to
do the work. I've only got the bandwidth to write this summary right
now, but since it's written (and somewhat belatedly being sent - weird
networking issues all of last week while traveling) I thought I'd toss
it out there in the hopes that it'll help move things forward.
More information about the IAEP