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.
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?
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
-- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294
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.
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
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
On Wed, 9 Mar 2011 14:31:57 -0600, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
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.
It is an easy change.
I believe that this is done due to the way that series-targeted bugs work in LP.
When you target a bug to a series, say "gcc-4.4", you can remove that targeting by marking the bug "Won't Fix". That is presumably why this is there.
I'm wary of changing it without understanding that interaction better though.
Thanks,
James
On Wed, Mar 9, 2011 at 3:31 PM, James Westby james.westby@linaro.orgwrote:
On Wed, 9 Mar 2011 14:31:57 -0600, Mounir Bsaibes < mounir.bsaibes@linaro.org> wrote:
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.
It is an easy change.
I believe that this is done due to the way that series-targeted bugs work in LP.
When you target a bug to a series, say "gcc-4.4", you can remove that targeting by marking the bug "Won't Fix". That is presumably why this is there.
I'm wary of changing it without understanding that interaction better though.
James, are you going to check on that and make a decision, whether it is ok to change the mapping?
For the other issue: bugs in gcc-linaro-tracking showing as in progress work items. Can we exclude the gcc-linaro-tracking from the status, if we decide to? Thanks & Regards, Mounir
Thanks,
James
On 11/03/11 22:54, Mounir Bsaibes wrote:
On Wed, Mar 9, 2011 at 3:31 PM, James Westby <james.westby@linaro.org mailto:james.westby@linaro.org> wrote:
On Wed, 9 Mar 2011 14:31:57 -0600, Mounir Bsaibes <mounir.bsaibes@linaro.org <mailto:mounir.bsaibes@linaro.org>> wrote: > 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. It is an easy change. I believe that this is done due to the way that series-targeted bugs work in LP. When you target a bug to a series, say "gcc-4.4", you can remove that targeting by marking the bug "Won't Fix". That is presumably why this is there. I'm wary of changing it without understanding that interaction better though.James, are you going to check on that and make a decision, whether it is ok to change the mapping?
For the other issue: bugs in gcc-linaro-tracking showing as in progress work items. Can we exclude the gcc-linaro-tracking from the status, if we decide to?
I specifically want to include gcc-linaro-tracking items. That's why I added them.
Andrew
On Sun, Mar 13, 2011 at 11:03 PM, Andrew Stubbs ams@codesourcery.com wrote:
On 11/03/11 22:54, Mounir Bsaibes wrote:
On Wed, Mar 9, 2011 at 3:31 PM, James Westby <james.westby@linaro.org mailto:james.westby@linaro.org> wrote:
On Wed, 9 Mar 2011 14:31:57 -0600, Mounir Bsaibes <mounir.bsaibes@linaro.org mailto:mounir.bsaibes@linaro.org> wrote: > 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.
It is an easy change.
I believe that this is done due to the way that series-targeted bugs work in LP.
When you target a bug to a series, say "gcc-4.4", you can remove that targeting by marking the bug "Won't Fix". That is presumably why this is there.
I'm wary of changing it without understanding that interaction better though.
James, are you going to check on that and make a decision, whether it is ok to change the mapping?
For the other issue: bugs in gcc-linaro-tracking showing as in progress work items. Can we exclude the gcc-linaro-tracking from the status, if we decide to?
I specifically want to include gcc-linaro-tracking items. That's why I added them.
Hi Andrew. What is your goal here? I'm concerned as status.linaro.org counts each tracking ticket as a work item and this inflates the amount of work recorded. I've assumed that the upstreaming work is rolled into the original work item or bug report which is already tracked.
-- Michael
On 13/03/11 22:28, Michael Hope wrote:
I specifically want to include gcc-linaro-tracking items. That's why I added them.
Hi Andrew. What is your goal here? I'm concerned as status.linaro.org counts each tracking ticket as a work item and this inflates the amount of work recorded. I've assumed that the upstreaming work is rolled into the original work item or bug report which is already tracked.
Simply that I seemed to be spending all my time on one work item, so I thought I would break it down a bit. This also gives me some indication how far through the task I am.
It's unfortunate that the ticket status isn't really what we're after here - i.e. the blueprint status depends on the local 4.6 branch, but the ticket status depends on the upstream status. I had intended that these two would correlate quite closely, but events have conspired against me.
Andrew
On Fri, 11 Mar 2011 16:54:36 -0600, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
James, are you going to check on that and make a decision, whether it is ok to change the mapping?
I will get back to you.
For the other issue: bugs in gcc-linaro-tracking showing as in progress work items. Can we exclude the gcc-linaro-tracking from the status, if we decide to?
You don't want to track anything about gcc-linaro-tracking on status.linaro.org?
Thanks,
James
On Thu, Mar 17, 2011 at 7:07 AM, James Westby james.westby@linaro.org wrote:
On Fri, 11 Mar 2011 16:54:36 -0600, Mounir Bsaibes mounir.bsaibes@linaro.org wrote:
James, are you going to check on that and make a decision, whether it is ok to change the mapping?
I will get back to you.
For the other issue: bugs in gcc-linaro-tracking showing as in progress work items. Can we exclude the gcc-linaro-tracking from the status, if we decide to?
You don't want to track anything about gcc-linaro-tracking on status.linaro.org?
After seeing Andrew's email, please leave it as it is. He's attached the tickets to the initial-4.6b blueprint to track the work he's doing. It does inflate the number of work items a bit but is better than showing no progress.
-- Michael
linaro-toolchain@lists.linaro.org
-
Andrew Stubbs -
James Westby -
Michael Hope -
Mounir Bsaibes -
Ulrich Weigand