[gta02] Introduction of the release dude role

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


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




More information about the distro-devel mailing list