On Thu, May 19, 2011 at 9:43 PM, Ulrich Weigand Ulrich.Weigand@de.ibm.com wrote:
Michael Hope michael.hope@linaro.org wrote:
Hi there. The next two weeks is where we take the technical topics from the TSC and the discussions had during the summit and turn them into the concrete engineering blueprints for this cycle. I've created a page at: https://wiki.linaro.org/MichaelHope/Sandbox/1111Blueprints
listing all of the TRs. Could you please have a look through these, find any with your name on them, and fill in the wiki page. I've put more notes on the page itself. Some of the topics may warrant specifications.
Let me know if you have questions on what the topics actually mean.
In the past cycle, I've been using the feature to attach bugs as work items to a blueprint, and I had been planning to do so again for at least some blueprints this cycle. However, this means that work items are added and disappear as bugs are discovered and possibly resolved as invalid. This seems to conflict with the goal that this cycle, work item numbers should stay stable ...
Any thoughts on how we should handle this?
Peter and I talked about similar yesterday. My current thoughts are: * For tracking the release cost, have a 'Linaro GDB the product' blueprint with a work item per release/month * For tracking support, don't attempt to. Use the ticket system and reserve, say, a 15 % of your time for bug fixes * For tracking work with a big, known backlog such as the GDB testsuite failures: use workitems or bugs attached to a blueprint
It would be nice to have some metrics on the bugs such as reporting rate, retirement rate, backlog, % invalid, and so on. I'll ask the Infrastructure team.
Also, some of the feedback from UDS sessions included features that could arguably be considered part of our blueprints, but go beyond what was originally their scope. For example, one user asked for GDB tracepoints to be also supported with native debugging, and one asked for enhancements to cross-debugging the kernel via KGDB.
At this point it is not clear whether there is anything we can do about those requirements during this cycle, but I think we should keep track of them to make sure they're not forgotten. I could think of a number of ways to do so:
- Add work items to the current blueprints (and postpone them if
we cannot in the end implement them)
- Do more investigation work first, and then add work items later
if appropriate
- Don't add them at all to the existing blueprints, but queue up
new blueprints (possibly for the next cycle)
I'd like to do them as a backlog. Most of these new features are interesting to upstream, so we should either record them upstream somehow or in a wiki page. I'm not fond of blueprints as they're too hard to find and manipulate.
-- Michael