[gta02] Introduction of the release dude role

[Holger Freyther]

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