[sugar] Software Status Meeting Tomorrow @ 1400 EDT, 1800 UTC in #olpc-meeting on freenode

[Michael Stone]

On Wed, May 28, 2008 at 03:02:17PM +0200, Marco Pesenti Gritti wrote:
> Relying on email and irc for this seems fragile to me. If a trac query
> would reveal the packages which are staged for inclusion in a certain
> release, it would be pretty much impossible that they go unnoticed.
> 
> Marco

That's fair. Suppose we make tickets for each release contract. The
relevant properties of the contracts that we want to represent include
their risk of slippage, the people who are responsible for seeing them
to fruition, and some material about the terms of the contract like
links to test cases, test results, and which bugs/features are supposed
to be finished upon successful completion of the contract. 

Some of these things are easy to represent with existing Trac features.
For example, we might represent slippage risk with a simple tag scheme
like 

 <rel>:+, <rel>:?, and <rel>:-

Example interpretation: If we saw a ticket labeled 

  rel-8.1.1:- rel-8.2:?

then we should conclude that this was a contract which had slipped from
8.1.1 to 8.2 and which was in question in 8.2. (The advantage of this
scheme over regular milestones is that my example ticket would be
represented in proper context in displays about either 8.1.1 or 8.2).

We also need some way of recording what actual people are responsible
for bringing the contract to fruition. Trac only permits one Owner but
it permits many tags. It seems that tags like

 <role>:<name>   (e.g. tester:erikos)

would suffice for this purpose.

What to do about test cases and test results? Perhaps we should
establish a convention that all release contracts will have a test cases
wiki page and a test results wiki page at specific names, e.g.

  wiki.laptop.org/go/Test Cases/<num>
  wiki.laptop.org/go/Test Results/<num>

and modify Trac to automatically insert prominent hyperlinks on tickets
tagged "rel-contract"?

Finally, there is the issue of work queues. I still have no clue how to
represent, using either either Trac or the wiki, the fact that every
individual has a work queue which differs from the Global Ticket
Priority ordering. People clearly have personal queues for all sorts of
reasons including:

  * people process several tickets concurrently to avoid waiting on one
    another

  * individuals often prefer to fix easy, hard, or well-understood
    things first
  
  * people barter work among themselves in order to help one another
    finish things off; this causes people to work on surprising things

(I want to know about personal queues because I want to pay attention to
the instantaneous velocity of development [i.e. in order to predict
where the code base will have moved to after the next \epsilon units of
time have elapsed].)

Comments?

Michael