On Wed, Mar 9, 2011 at 3:46 AM, Andrew Stubbs ams@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