Re: Tracking Issues, Versions

2018-04-26 Thread John McDonnell 
I thought Jiri had marked some issues as blockers for 9.0 as part of netcat.


 Laszlo to get those permissions you need to raise an INFRA ticket.


On 26 April 2018 at 19:23, Matthias Bläsing 
wrote:

> Hi,
>
> Am Donnerstag, den 26.04.2018, 11:18 -0700 schrieb Laszlo Kishalmi:
> > I'm walking through the open issues with PR-s now. I'm going to mark
> > their Fix Version to 9.0 if I think that shall be part of that
> > release.
>
> Issues need people working on them if that does not happen, marking
> them for a release won't help.
>
> I would switch it around: are there show stoppers, that prevent a
> release? There was and there is a saying for open source: Release
> early, release often!
>
> Greetings
>
> Matthias
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
> For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
>

Re: Tracking Issues, Versions

2018-04-26 Thread Matthias Bläsing 
Hi,

Am Donnerstag, den 26.04.2018, 11:18 -0700 schrieb Laszlo Kishalmi:
> I'm walking through the open issues with PR-s now. I'm going to mark 
> their Fix Version to 9.0 if I think that shall be part of that
> release.

Issues need people working on them if that does not happen, marking
them for a release won't help.

I would switch it around: are there show stoppers, that prevent a
release? There was and there is a saying for open source: Release
early, release often!

Greetings

Matthias

-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Tracking Issues, Versions

2018-04-26 Thread Laszlo Kishalmi 

Well, it seems there no too many option here.

I'm walking through the open issues with PR-s now. I'm going to mark 
their Fix Version to 9.0 if I think that shall be part of that release.


BTW Could someone grant me some rights in JIRA to share my dashboard:

http://telegra.ph/NetBeans-Issue-Overview-04-26 (screenshot)


On 04/22/2018 09:52 AM, Laszlo Kishalmi wrote:
Well that one could work for me as well. Anyone else has any other 
idea or supporting this one?



On 04/21/2018 10:04 PM, cowwoc wrote:

The way I've seen JIRA used in the past is:

Setting a "Fix Version" of 9.0 on an unresolved issue implies a 
desire to fix it in that release. When that issue is subsequently 
marked as resolved, the Fix Version indicates what version it was 
fixed in.


Gili

On 2018-04-22 12:53 AM, Laszlo Kishalmi wrote:

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 
9.0 release. Right now it is hard to say. We are working with two 
version field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from 
Geertjan, I still can't say it is fixed in 9.0. I set it to Next, 
though the issue is still unresolved and I do not feel myself 
comfortable with that setting either.


We can haggle on the Priority of the issue. It does not really 
affects me, but if we really would like to provide a decent IDE we 
might need to come up with a JavaHelp replacement. So critical would 
be fine for me either. Still this issue would not be delivered in NB 
9.0.


I'd propose label those issues which we would really like to deliver 
in 9.0 with "NB9.0", though I'm open any other 
clarifications/suggestions etc. So let's discuss this!






-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists








-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Tracking Issues, Versions

2018-04-22 Thread Laszlo Kishalmi 
Well that one could work for me as well. Anyone else has any other idea 
or supporting this one?



On 04/21/2018 10:04 PM, cowwoc wrote:

The way I've seen JIRA used in the past is:

Setting a "Fix Version" of 9.0 on an unresolved issue implies a desire 
to fix it in that release. When that issue is subsequently marked as 
resolved, the Fix Version indicates what version it was fixed in.


Gili

On 2018-04-22 12:53 AM, Laszlo Kishalmi wrote:

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 
9.0 release. Right now it is hard to say. We are working with two 
version field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from Geertjan, 
I still can't say it is fixed in 9.0. I set it to Next, though the 
issue is still unresolved and I do not feel myself comfortable with 
that setting either.


We can haggle on the Priority of the issue. It does not really 
affects me, but if we really would like to provide a decent IDE we 
might need to come up with a JavaHelp replacement. So critical would 
be fine for me either. Still this issue would not be delivered in NB 
9.0.


I'd propose label those issues which we would really like to deliver 
in 9.0 with "NB9.0", though I'm open any other 
clarifications/suggestions etc. So let's discuss this!






-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists






-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Re: Tracking Issues, Versions

2018-04-21 Thread cowwoc 

The way I've seen JIRA used in the past is:

Setting a "Fix Version" of 9.0 on an unresolved issue implies a desire 
to fix it in that release. When that issue is subsequently marked as 
resolved, the Fix Version indicates what version it was fixed in.


Gili

On 2018-04-22 12:53 AM, Laszlo Kishalmi wrote:

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 
9.0 release. Right now it is hard to say. We are working with two 
version field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from Geertjan, 
I still can't say it is fixed in 9.0. I set it to Next, though the 
issue is still unresolved and I do not feel myself comfortable with 
that setting either.


We can haggle on the Priority of the issue. It does not really affects 
me, but if we really would like to provide a decent IDE we might need 
to come up with a JavaHelp replacement. So critical would be fine for 
me either. Still this issue would not be delivered in NB 9.0.


I'd propose label those issues which we would really like to deliver 
in 9.0 with "NB9.0", though I'm open any other 
clarifications/suggestions etc. So let's discuss this!






-
To unsubscribe, e-mail: dev-unsubscr...@netbeans.incubator.apache.org
For additional commands, e-mail: dev-h...@netbeans.incubator.apache.org

For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists

Tracking Issues, Versions

2018-04-21 Thread Laszlo Kishalmi 

Dear all,

Some of you might noticed that I spent some time digging JIRA up and 
down during the last few days.


I try to identify those issues which we really need to solve before 9.0 
release. Right now it is hard to say. We are working with two version 
field at the moment: Affects version(s) and Fix Version(s).


1. Affects Versions: is quite straight forward: It is used to define
   the version where the issue is found. For me it is not necessary the
   version it shall be fixed.
2. Fix Versions: It can be set when an issue is resolved, marking the
   version where the fix for the issue would be delivered.
3. There is no clear field which would specify if an issue shall be in
   a specific release. Well, I know this is not really agile, but we
   are still kind of waterfall, having infrequent major releases.

To see my problem, check: NETBEANS-656 Help is Broken (Offline and 
On-line) 


Affect Versions: 9.0 (well, yes we do not deliver JavaHelp)

Fix Version: Though there is an improvement PR applied from Geertjan, I 
still can't say it is fixed in 9.0. I set it to Next, though the issue 
is still unresolved and I do not feel myself comfortable with that 
setting either.


We can haggle on the Priority of the issue. It does not really affects 
me, but if we really would like to provide a decent IDE we might need to 
come up with a JavaHelp replacement. So critical would be fine for me 
either. Still this issue would not be delivered in NB 9.0.


I'd propose label those issues which we would really like to deliver in 
9.0 with "NB9.0", though I'm open any other clarifications/suggestions 
etc. So let's discuss this!