Holger,
very good!
To everybody: If you do not want to exclude most Taiwanese from
reading your mails, you have to restrict your mails to 5 lines (I know
this very email is longer).
Who's involved in the software update:
Product Manager: Will
System Software (bootloader, kernel)
Anthony
Matt
Werner
Andy
Splinter
OLV
Jeremy
Daniel (not for this update, works on Diversity only)
Installer/Launcher
Tick (Installer)
raster (Launcher)
Thomas (opkg, will finish at end of May)
Distribution/Build/Integration
Julian
Graeme
Holger (Qtopia)
Preferences
Willie
Testing
Allen
Regina
The communication is very bad in all teams. I don't think anybody
maintains any sort of public 'open issues' list.
Some people have their private lists.
Your weekly status reports are the best thing wrt communication we
have company-wide.
I will try to start sending weekly or bi-weekly mails about who is
working on what.
Wolfgang
On May 10, 2008, at 5:16 AM, Holger Freyther wrote:
Hey friends (Will, Wolfgang, raster, olv, julian, graeme,
sean_chiang, matt,
andy, tick, andy),
you get this mail because I think you are involved with the april
software
update. We have 11 more month (or are one month too late, actually I
think
this is the sad truth) and we should make sure to converge our
development
efforts to make a good first update.
I think our biggest issue is communication. I know what raster is
doing, I got
some input from olv but for the rest of you I can only speculate
what you do,
if you are involved with the april update at all.
So the goals of this mail are:
- Find out if and how you are involved with the update
- Introduce you to the role of a release dude
- Declare myself to that position and setup some rules.
=== People and their roles ===
will: product manager. Tells us when we can stop on the update.
raster: illume/e spec implementor-monkey (I hope we can make that up
for gta04
and thanks for doing this!!!!)
olv: diversity/splinter backend implementor? part of the april update?
julian: distro team lead? involved with the update? responsible for
the auto
builder?
graeme: Will finish the Qtopia package split, and will fix whatever
crimes we
do to the metadata and merge stuff to OE. Besides that I see him
mostly
involved with R&D of org.openmoko.dev.
sean_chiang: Our buddy to look into modem issues blocking sfu? Is that
correct?
matt/andy: Help us fix kernel bugs we stumble across, so we use you
on demand?
anything else you plan to do for the software update?
tick: assassin, enlazar? that is part of the sfu?
jeremy: frontend for diversity?
me: Qtopia and distro stuff
who is involved but not on this list? speak up now to pop up on my
radar.
=== A release dude ===
I know this from KDE [1] but this is my interpretation of the role.
We, as in
Openmoko, build a product. This involves hardware design and
manufacturing
but also software. Our software is a compilation/distribution of
various
projects. We have to build software and control what and which
versions of
software we put into our distro/image. The PM is responsible for
saying what
we will create and has the final say on what stuff we put in the
image.
What is the role of the release dude?
He helps to create a distribution/image that is fullfilling the
requirements
of the product spec and passing the testcases setup at the begin of
the
product development cycle. He constantly tracks progress and helps
people to
find help.
How is the release dude doing this?
Magic would be one option. The other is enforcing control on the
distribution,
updating bits and pieces on request, on his own, getting information
from the
people involved, updating the status, talking with pm...
And by the name of the role, this guy is supposed to be a friend as
our common
goal is the completion of the task, he will not get in the way of
your work,
you don't have to report to him, he will ask you stuff for sure
though.
=== Taking that position ===
Well, it is may, I want to get the april update out, I think the
issue is
communication and that I can help (I hope that this is not like the
drummer
of a rock band suddenly having ideas for new songs?).
So if you don't object I would like to assume the above role and I
come with
my own set of rules (eek, I'm german...)
0. Communicate:
- When in doubt send an email.
- If you make a decision influencing others, sent an email about
that. Keep
things local (irc, office...) when possible, but inform the others
about the
outcome.
- Tell me if you are involved with the software update or not.
1. The distro:
- I will create org.openmoko.april-update and every change needs to
be
reviewed by me. You can and are supposed to ask me to bump versions of
packages, do this with a mail to distro-devel
- The auto-builder has to build the april image from this branch.
Who can do
this?
- The distro has to build without internet access if all the source
has been
fetched in advance.
2. Keep a todolist or two:
- Keep a todolist about all the stuff that annoys you about the
current code
- Keep another list for things you have to absolutely fix for the
april
update. If in doubt talk to Will and put "(will)" after the task.
This should
resemble things from allen's test plans.
- Use something others can access and is versioned. Let this be a
bug in the
bugtracker, a page in the wiki, a file in the source repository.
- Tell me the location of this file.
so there shouldn't be anything you wouldn't do anyway. I promise to
accumulate
your lists and provide an one-stop overview about our open issues.
This list
depends on how good we communicate.
So we have to improve communication. It must be known to us who is
responsible
for what parts, and there must be someone who is integrating all
this and
making sure we go in the right direction. So this is my attempt to
get things
started and I think the taipei status meetings are a good start as
well.
comments? thoughts? sorry for the long mail
z.
[1] http://techbase.kde.org/Schedules/Release_Schedules_Guide
