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.
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