[JBoss JIRA] (JBIDE-22621) Server adapter wizard: should be able to import projects to my workspace
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22621?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22621:
-------------------------------------
Fix Version/s: 4.4.x
> Server adapter wizard: should be able to import projects to my workspace
> ------------------------------------------------------------------------
>
> Key: JBIDE-22621
> URL: https://issues.jboss.org/browse/JBIDE-22621
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Andre Dietisheim
> Labels: openshift_v3, server_adapter_wizard
> Fix For: 4.4.x
>
>
> steps to reproduce:
> # ASSERT: have empty workspace
> # ASSERT: have at least 1 service in OpenShift
> # EXEC: in OpenShift explorer: launch server adapter wizard from context menu of your service
> Result:
> The Eclipse project text field is erroring and nothing to select, since you have no project in your workspace yet.
> !no-workspace-project-exists.png!
> There's no way for the user to import a project from OpenShift to the workspace in this wizard. One has to close the wizard and head over to the import wizard first and get back.
> Expected result:
> I should have a link to the right of "Browse.." which allows me to import a project.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22621) Server adapter wizard: should be able to import projects to my workspace
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22621?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-22621:
-------------------------------------
Labels: openshift_v3 server_adapter_wizard (was: )
> Server adapter wizard: should be able to import projects to my workspace
> ------------------------------------------------------------------------
>
> Key: JBIDE-22621
> URL: https://issues.jboss.org/browse/JBIDE-22621
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: openshift
> Affects Versions: 4.4.0.Final
> Reporter: Andre Dietisheim
> Labels: openshift_v3, server_adapter_wizard
> Fix For: 4.4.x
>
>
> steps to reproduce:
> # ASSERT: have empty workspace
> # ASSERT: have at least 1 service in OpenShift
> # EXEC: in OpenShift explorer: launch server adapter wizard from context menu of your service
> Result:
> The Eclipse project text field is erroring and nothing to select, since you have no project in your workspace yet.
> !no-workspace-project-exists.png!
> There's no way for the user to import a project from OpenShift to the workspace in this wizard. One has to close the wizard and head over to the import wizard first and get back.
> Expected result:
> I should have a link to the right of "Browse.." which allows me to import a project.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Len DiMaggio commented on JBIDE-22619:
--------------------------------------
I'd vote for keeping things simple too - and not changing - why not keep the sprint numbers in the sprint number field? Thx!
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-22619:
---------------------------------------------
I grok the reason about the idea for using sprint numbers in the jira fix version but it raises two questions for me:
1) historically we used to be pretty strict about not having "meaningless" jira versions - that the jira version meant something and it was the actual version used in the release/project metadata.
does this proposal of having 4.4.1.S116 mean that the version in our pom's/osgi manifest etc. will actually state 4.4.1.S116 or still using "proper" version names/numbers ?
2) I assume if there in one sprint will be worked on two different versions, i.e. devstudio 9.1.x and devstudio 10.x the versions would be something like 9.1.1.S116 and 10.1.0.S116 ?
...my guess is that the answer to #1 is no and #2 is yes.
And that just make me think ...why put the sprint number into the fixversion ? what is the point ?
Is it because jiralint and our past approach been that we need to set the jira fixversion when working on an issue ?
Could it then help if we make jiralint or something similar go and set the 'expected fix version' on issues that is in a sprint but have no fix version ?
In that case dev's won't have to both set the sprint and fix version (unless there is something unexpected about it)
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22620) remove duplicate entries from target platforms
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-22620:
----------------------------------
Summary: remove duplicate entries from target platforms
Key: JBIDE-22620
URL: https://issues.jboss.org/browse/JBIDE-22620
Project: Tools (JBoss Tools)
Issue Type: Sub-task
Components: target-platform
Affects Versions: 4.4.1.S116
Reporter: Nick Boldt
Current 4.60.0.Final TP contains duplicates of these IUs:
* org.eclipse.m2e.model.edit
* org.eclipse.egit.ui.smartimport
* ...others?
Duplication should be avoided. See also JBIDE-22611.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-22619:
----------------------------------------
We already have a dedicated field on Jira to track sprint number so I don't see the advantage of repeating it in fixVersion.
Also, the fixVersion is a "user-friendly" presentation of when this is going to be available. I'm not sure it's better to tell our user "next sprint" than to tell "next Beta" as we do not publish proper binaries to users by the end of a sprint.
IMO, we're better keeping our current rules.
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22619:
-------------------------------
Sprint: devex #116 2016/06/15 - 07/05
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-22619:
----------------------------------
Summary: Decide strategy for fixversion targets in JIRA
Key: JBIDE-22619
URL: https://issues.jboss.org/browse/JBIDE-22619
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build
Affects Versions: 4.4.1.S116
Reporter: Nick Boldt
We need to decide the strategy for milestones / fixversions in JIRA.
One suggestion has been to align fixversions w/ sprint numbers, thus:
* 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
instead of
* 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
Questions/concerns:
* what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
* whatever schema we adopt has to work with bzira and jiralint
* any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-22619:
-------------------------------
Issue Type: Task (was: Bug)
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (JBIDE-22619) Decide strategy for fixversion targets in JIRA
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22619?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-22619:
----------------------------------
Assignee: Alexey Kazakov
> Decide strategy for fixversion targets in JIRA
> ----------------------------------------------
>
> Key: JBIDE-22619
> URL: https://issues.jboss.org/browse/JBIDE-22619
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Affects Versions: 4.4.1.S116
> Reporter: Nick Boldt
> Assignee: Alexey Kazakov
> Fix For: 4.4.1.S116
>
>
> We need to decide the strategy for milestones / fixversions in JIRA.
> One suggestion has been to align fixversions w/ sprint numbers, thus:
> * 4.4.1.S116, 4.4.1.S117, 4.4.1.S118, 4.4.1.S119, ...?
> instead of
> * 4.4.1.Alpha1, 4.4.1.Alpha2, 4.4.1.Alpha3, 4.4.1.Beta1, ... ?
> Questions/concerns:
> * what do we do for unscheduled milestones (4.5.0.Alpha1, 11.0.0.Alpha1) and placeholders (4.4.1.Final, 10.0.1.GA) ? Should we just use Alpha1 or Final/GA until we know which sprint applies?
> * whatever schema we adopt has to work with bzira and jiralint
> * any other systems that parse JIRA for integration purposes?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months