[gta02] Introduction of the release dude role
Holger Freyther
zecke at openmoko.org
Fri May 9 23:17:51 CEST 2008
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
More information about the distro-devel
mailing list