[gta02] Introduction of the release dude role

Wolfgang Spraul wolfgang at openmoko.com
Sat May 10 06:42:45 CEST 2008

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)

   Daniel (not for this update, works on Diversity only)

   Tick (Installer)
   raster (Launcher)
   Thomas (opkg, will finish at end of May)

   Holger (Qtopia)



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.

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

More information about the distro-devel mailing list