[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