On Wed, May 28, 2008 at 4:08 PM, Michael Stone <[EMAIL PROTECTED]> wrote: > 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"?
All of this sounds pretty good to me. > 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].) Couple of random ideas: * Several people started to add a TODO to their User wiki page on sugarlabs.org. We might encourage something like that. It's unlikely that everyone will do it and keep it updated though. * At Red Hat all the engineers are sending in weekly status reports, which also contains a "Plans for this week" section. Marco _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
