On Wed, Mar 9, 2011 at 3:46 AM, Andrew Stubbs <a...@codesourcery.com> wrote:
> On 08/03/11 19:59, Ulrich Weigand wrote: > >> >> Hi Michael, Andrew, >> >> Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro, >> gdb-linaro etc.) are now also included in the LP work-item tracking >> statistics (http://status.linaro.org/linaro-toolchain-wg.html). This >> didn't happen in the past due to a Launchpad issue that has now been >> fixed. >> > > Yay! :) > > > This seems to be working out nicely, except for one issue: what about the >> gcc-linaro-tracking project? I have a couple of bugs that are fixed in >> Linaro GCC, and are also fixed in mainline GCC, but they still show up as >> an "in-progress" work-item in the status tracker (there are a whole bunch >> more of those assigned to Andrew as well). The reason for this is the LP >> records have an associated gcc-linaro-toolchain project entry, and this is >> set to "Fix Committed", but not "Fix Released" ... probably because GCC >> 4.6.0 is not yet released? >> >> Now, on the one hand it does make sense to include the -tracking project >> in >> the work-item statistics, because they *do* reflect important tasks: >> namely, to make sure that the changes indeed land in the upstream >> repository. However, having them all show up as "in progress" until the >> community makes a new GCC release does not seem very helpful: this is not >> in our control, and our work is in fact done once the patch is committed >> upstream. >> > > There's another problem: the patches that we have decided not to push > upstream at all are marked "Won't Fix", and the work items are showing as > "Postponed". It would be better if they were shown as "Done" - as in, I've > considered the patch and decided what to do with it, so it's done, but no > fix has been either committed, or released. > > Does anybody know what happens if I say it's "Invalid"? I'll flip one over, > and see what happens. Copying James to check whether there was a reason for mapping Won't fix to Postponed. If there is no compelling reason, maybe it is an easy change to map it to Done instead. > > > Therefore my suggestion: we should immediately mark -tracking bugs as "Fix >> Released" (not "Fix Committed"), as soon as the corresponding patch is >> committed upstream (and thus our work on the problem is completed). >> >> Thoughts? Does this make sense? Will this mess up any of the other >> purposes for which we currently use the -tracking project? >> > > Well, I rather liked the distinction, on an aesthetic level, but I don't > see that there was any real advantage. I mean, the release number is given > in the milestone, and we know whether that number has been released, or not, > so the information has been encoded there. You could certainly argue that > the patch has indeed been released to the public at large. > > If nobody objects in the next day or two, I say we do it. The task tracker > is quite useful, and it's all certain managers will look at, so it is of > some commercial interest to those of us who don't work for member companies. > > Michael, I think the patch tracker ought to be adjusted to give a different > message for released, and somehow flag bugs that are in the unhelpful "Fix > committed" state. (Maybe we should do something about "Won't fix" too.) > > Andrew > > > _______________________________________________ > linaro-toolchain mailing list > linaro-toolchain@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-toolchain >
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
