additional Milestone label for applications
If you want to track an external project on fogbugz, we should also create a proper fogbugz project, so it is clearly separated. On a project-basis you can define custom milestones. So in that sense, milestones do not serve for distinguishing external projects. Additionally you can define a simpler workflow for external projects (e.g. open / closed) which might serve your purposes better. PharoLauncher might not be the best example as it is maintained by core members, but usually for other projects it makes sense to manage them externally. Github is really a good option for that. On 2013-10-04, at 19:10, btc@openinworld.com wrote:
I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'.
btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it.
[1] http://wiki.eclipse.org/Simultaneous_Release
cheers -ben
On 2013-10-04, at 19:44, btc@openinworld.com wrote:
Camillo Bruni wrote:
If you want to track an external project on fogbugz, we should also create a proper fogbugz project, so it is clearly separated. There is a separate Project='Launcher', but I guess its hard to filter out when many Projects are subparts of the main image. On a project-basis you can define custom milestones.
Good to know. I guess 'Launcher' just inherited the default. Who can update those?
only admins currently, though the club is not that exclusive :) so if you want I can make you one...
btc@openinworld.com wrote:
I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'.
btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it.
[1] http://wiki.eclipse.org/Simultaneous_Release
cheers -ben
Elsewhere I see a comment by Marcus that "we need to find a way how to use the bug tracker for projects..." I notice there is already a Projects field while the Areas field is entirely unused (perhaps this is from following the guidelines of [2]). One option might be recategorizing many of the existing Projects as Areas under one Project='Image'. Maybe that would require an unreasonable effort to implement, but I float the idea anyway. Perhaps the Fogbugz sysadmins have some tools that could assist. [2] http://www.fogcreek.com/fogbugz/docs/70/topics/basics/Projectsandareas.html cheers -ben
On Oct 4, 2013, at 7:37 PM, btc@openinworld.com wrote:
btc@openinworld.com wrote:
I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'. btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it.
[1] http://wiki.eclipse.org/Simultaneous_Release
cheers -ben
Elsewhere I see a comment by Marcus that "we need to find a way how to use the bug tracker for projects..." I notice there is already a Projects field while the Areas field is entirely unused (perhaps this is from following the guidelines of [2]). One option might be recategorizing many of the existing Projects as Areas under one Project='Image'. Maybe that would require an unreasonable effort to implement, but I float the idea anyway. Perhaps the Fogbugz sysadmins have some tools that could assist.
So the idea is that I want to have filter for "Need to be reviewed" "need to be integrated" that are possible to get to empty (that is: that are only related to the image itself). https://pharo.fogbugz.com/f/filters/36/Review https://pharo.fogbugz.com/f/filters/35/Integration e.g. https://pharo.fogbugz.com/f/filters/35/Integration has two issues that I can't act uppon. So they are not "to be included, because I can not include them. How do we make a filter that shows me not the other projects? Marcus
On 2013-10-05, at 09:47, Marcus Denker <marcus.denker@inria.fr> wrote:
On Oct 4, 2013, at 7:37 PM, btc@openinworld.com wrote:
btc@openinworld.com wrote:
I've been advised that for application related issues tracked on Fogbugz (e.g. for PharoLauncher) to avoid tagging the Milestone as 'Pharo3.0' - which is reserved for image related issues. Fair enough, but the only available alternative 'Later' just doesn't seem a good fit. Can adding another milestone be considered, like 'non-image' or 'application'. btw, my reasoning for tagging with Pharo3.0 was to do with the idea of simultaneous release [1] of related tools with the image. With the CI now operating for a lot of projects, it is not unfeasible that such a co-ordinated release occur. This might be good to encourage participation in testing and bug hunting in the final weeks and maybe speed the uptake of 3.0. On the other hand, it might unreasonably stretch resources trying to co-ordinate it.
[1] http://wiki.eclipse.org/Simultaneous_Release
cheers -ben
Elsewhere I see a comment by Marcus that "we need to find a way how to use the bug tracker for projects..." I notice there is already a Projects field while the Areas field is entirely unused (perhaps this is from following the guidelines of [2]). One option might be recategorizing many of the existing Projects as Areas under one Project='Image'. Maybe that would require an unreasonable effort to implement, but I float the idea anyway. Perhaps the Fogbugz sysadmins have some tools that could assist.
So the idea is that I want to have filter for
"Need to be reviewed" "need to be integrated"
that are possible to get to empty (that is: that are only related to the image itself).
https://pharo.fogbugz.com/f/filters/36/Review https://pharo.fogbugz.com/f/filters/35/Integration
e.g.
https://pharo.fogbugz.com/f/filters/35/Integration
has two issues that I can't act uppon. So they are not "to be included, because I can not include them.
How do we make a filter that shows me not the other projects?
Marcus
I think it should just be fine if we define a different workflow (and thus different labels) for external projects...
I think it should just be fine if we define a different workflow (and thus different labels) for external projects...
The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area.
So we need to have 2 things 1. a separate project for each external project that wants to report 2. a separate Area for these external projects For instance, NativeBoost has both a stable version in the image and a development version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). However, if the bug concerns the development version we set the Area to something project specific. I will try to update the tracker and the filters to reflect that...
thanks! This is a good idea. On Oct 6, 2013, at 1:57 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I think it should just be fine if we define a different workflow (and thus different labels) for external projects...
The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area.
So we need to have 2 things 1. a separate project for each external project that wants to report 2. a separate Area for these external projects
For instance, NativeBoost has both a stable version in the image and a development version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). However, if the bug concerns the development version we set the Area to something project specific.
I will try to update the tracker and the filters to reflect that...
seems like it works, so by default the pharo-internal projects will have the Area "1. Pharo Image" set. Why the "1."? Well I cannot order the Areas, and the first one is selected by default :P The filter "review" and "integration" now only look at issues that have the proper Area set. On 2013-10-06, at 08:08, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
thanks! This is a good idea.
On Oct 6, 2013, at 1:57 AM, Camillo Bruni <camillobruni@gmail.com> wrote:
I think it should just be fine if we define a different workflow (and thus different labels) for external projects...
The 'Area' field looks unused, having only a single option 'Misc'. Perhaps that could be 'Image' and 'External Project' or similar. Most of an external project's issues would also have an area of 'External 'Project', but sometimes it might be 'Image' if a change there is required to fix an issue reported on a project. Or maybe for external projects you have only a single option 'External Project' for Area.
So we need to have 2 things 1. a separate project for each external project that wants to report 2. a separate Area for these external projects
For instance, NativeBoost has both a stable version in the image and a development version aside. So if a bug appears in the image we can set the Area to "Pharo Image" (the default). However, if the bug concerns the development version we set the Area to something project specific.
I will try to update the tracker and the filters to reflect that...
On 2013-10-06, at 17:36, btc@openinworld.com wrote:
Camillo Bruni wrote:
seems like it works,
so by default the pharo-internal projects will have the Area "1. Pharo Image" set.
Why the "1."? Well I cannot order the Areas, and the first one is selected by default :P
The filter "review" and "integration" now only look at issues that have the proper Area set.
Looks good. The "1." looks fine, but in case it is useful I happened to find a Fogbugz script "Set Hard Default for Project and Area in New Cases" at [1] that seems related.
ah ok, I didn't see the script and went for the silly solution fogbugz proposed already for other things (wiki names ...).
I'm curious now whether 'External' projects are then free to use Milestone=Pharo3.0 if they want to target certain issues of their own to align with that release date?
Yes, this is possible now, as long as the Area is not "1. Pharo Image" everything can be used freely.
participants (4)
-
btc＠openinworld.com -
Camillo Bruni -
Marcus Denker -
Stéphane Ducasse