On Thu, May 19, 2011 at 9:43 PM, Ulrich Weigand <ulrich.weig...@de.ibm.com> wrote: > Michael Hope <michael.h...@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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
