Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

Well, I've got the rights to share my dashboard.

It's called: NetBeans Overview

https://issues.apache.org/jira/secure/Dashboard.jspa?selectPageId=12332552

On 04/26/2018 03:53 PM, Laszlo Kishalmi wrote:

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some 
flags for 9.0 as well.


Right now in JIRA we have 27 open issues with PR and 9 of them are 
marked for 9.0 release.


We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, 
that pointed out by Geertjan)


3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:

Well,

I'm trying to collect the remaining things to do for 9.0 release for 
a week now, from GitHub PR-s, JIRA and this mailing list. Regarding 
9.0 in numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more 
focused on what we are doing.


I could promise to go over the open issues and the PR-s and close 
those which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might 
really mean that changes that we do not want to include into 9.0 are 
piling up (indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the 
following days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now 
as we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 


wrote:

Yeah, there are changes in the queue for the master branch that 
could be
too destabilizing. To avoid something like that to negatively 
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put 
only the
safe fixes ready for 9.0 there. The wild development would continue 
in the

master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like 
system

where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not 
from

the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then 
and now?


Best wishes,

Neil







-
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: Time to branch for the release candidate?

[Eirik Bakke]

Here's a bug, with a pull request and some discussion, that's not quite a 
blocker (it existed in 8.2) but still arguably critical:

https://issues.apache.org/jira/browse/NETBEANS-403
"Pressing Home/End scrolls to beginning/end of whole document if tooltip is 
open"

There's an ongoing discussion on 
https://github.com/apache/incubator-netbeans/pull/507 .

-- Eirik


On 4/26/18, 6:53 PM, "Laszlo Kishalmi" 
> wrote:

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some
flags for 9.0 as well.

Right now in JIRA we have 27 open issues with PR and 9 of them are
marked for 9.0 release.

We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that
pointed out by Geertjan)

3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:
Well,

I'm trying to collect the remaining things to do for 9.0 release for a
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0
in numbers are the following (none may be accurate, though):

We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for
release. I just would like to say, we probably need to be more focused
on what we are doing.

I could promise to go over the open issues and the PR-s and close
those which have merged PRs-.

Also I feel the number of open PRs is quite high, though it might
really mean that changes that we do not want to include into 9.0 are
piling up (indicates the need of the release branch).

Also those 5 issues with PR-s might just go into master in the
following days and we could make the release branch after that.

So If I would vote for release branch now it would be 0/-1 right now
as we (or maybe just me) can't really see clearly on 9.0.



On 04/17/2018 05:52 AM, Neil C Smith wrote:
On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
>
wrote:

Yeah, there are changes in the queue for the master branch that
could be
too destabilizing. To avoid something like that to negatively
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only
the
safe fixes ready for 9.0 there. The wild development would continue
in the
master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like
system
where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not
from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and
now?

Best wishes,

Neil



-
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

Enable G1's String Deduplication by default.

[Laszlo Kishalmi]

Dear all,


I've opened an issue months ago in order to revisit the default startup 
options. https://issues.apache.org/jira/browse/NETBEANS-342


I did not came up with anything really big, besides removing the client 
VM specification. However I think we can add string deduplication 
feature of G1 GC (-XX:+UseStringDeduplication), which is available since 
JVM 1.8.0_20.


Honestly I used NetBeans with that for years and I did not notice any 
drawbacks of that so far. What I noticed, when I started to use theSnap 
packages I'm building for Linux, is that NetBeans is a bit more power 
hungry when I working on NB modules. This meant that my 1 Gb heap was 
almost fully consumed when module indexing/parsing happened and forced 
the IDE to more garbage collecting. Re-enabling String deduplication 
helped a lot.


String Deduplication feature has been available since 2014 and even 
Eclipse is using that option from 2016. I think it is safe to enable it 
for 9.0.


See: https://github.com/apache/incubator-netbeans/pull/518

What do you think?

Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

I went though the open issues with PR-s list.

I've marked 17 issues resolved due to it's PR merged, and added some 
flags for 9.0 as well.


Right now in JIRA we have 27 open issues with PR and 9 of them are 
marked for 9.0 release.


We still have 31 open PRs.

As of 9.0: We have 40 issues open (I've marked the 3 blocker ones, that 
pointed out by Geertjan)


3 blocker

6 critical

25 major

5 minor

1 trivial

9 of these has PR-s


Just one note: Our most voted/watched issue is supporting JUnit 5


On 04/26/2018 10:56 AM, Laszlo Kishalmi wrote:

Well,

I'm trying to collect the remaining things to do for 9.0 release for a 
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 
in numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more focused 
on what we are doing.


I could promise to go over the open issues and the PR-s and close 
those which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might 
really mean that changes that we do not want to include into 9.0 are 
piling up (indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the 
following days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now 
as we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
wrote:

Yeah, there are changes in the queue for the master branch that 
could be
too destabilizing. To avoid something like that to negatively 
influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only 
the
safe fixes ready for 9.0 there. The wild development would continue 
in the

master branch.

+1 to branching and that.  Longer term perhaps a more gitflow-like 
system

where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not 
from

the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and 
now?


Best wishes,

Neil





-
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: Time to branch for the release candidate?

[Geertjan Wielenga]

On Thu, Apr 26, 2018 at 7:56 PM, Laszlo Kishalmi 
wrote:

> Well,
>
> I'm trying to collect the remaining things to do for 9.0 release



There are 3 blockers:

https://issues.apache.org/jira/issues/?filter=12343308

Thanks,

Gj





> for a week now, from GitHub PR-s, JIRA and this mailing list. Regarding
> 9.0 in numbers are the following (none may be accurate, though):
>
> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>
> We have 44 open issues with PR-s.
>
> We have 32 open issues marked for 9.0
>
> We also have 5 open issues with PR-s for 9.0
>
> The issues and PRs are not really aligned.
>
> Well this does not necessarily means that we should not branch for
> release. I just would like to say, we probably need to be more focused on
> what we are doing.
>
> I could promise to go over the open issues and the PR-s and close those
> which have merged PRs-.
>
> Also I feel the number of open PRs is quite high, though it might really
> mean that changes that we do not want to include into 9.0 are piling up
> (indicates the need of the release branch).
>
> Also those 5 issues with PR-s might just go into master in the following
> days and we could make the release branch after that.
>
> So If I would vote for release branch now it would be 0/-1 right now as we
> (or maybe just me) can't really see clearly on 9.0.
>
>
>
> On 04/17/2018 05:52 AM, Neil C Smith wrote:
>
>> On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
>> wrote:
>>
>> Yeah, there are changes in the queue for the master branch that could be
>>> too destabilizing. To avoid something like that to negatively influence
>>> the
>>> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
>>> safe fixes ready for 9.0 there. The wild development would continue in
>>> the
>>> master branch.
>>>
>>> +1 to branching and that.  Longer term perhaps a more gitflow-like system
>> where PR's come into a develop branch too?
>>
>>   A question, though - I assume this will branch off master now, not from
>> the beta tag?  Given that in NetCAT we were testing the beta, I assume
>> there is nothing you'd consider "too destabilizing"  between then and now?
>>
>> Best wishes,
>>
>> Neil
>>
>
>
> -
> 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: Time to branch for the release candidate?

[Geertjan Wielenga]

On Thu, Apr 26, 2018 at 8:26 PM, Peter Steele  wrote:

> Just for my interest, which types of people can approve Pull Requests?



NetBeans is simply an Apache project, in the Apache incubator. Nothing that
we're doing here is specific to NetBeans, everything is the same as at
Apache Maven, Apache Groovy, and hundreds at least of other projects.

E.g., to answer your question, there are very clear guidelines:

https://www.apache.org/dev/new-committers-guide.html

Thanks,

Gj




> As
> we are now open source the community is deciding what's important by
> providing the PR's but we have quite a few stacked up. It has previously
> been mentioned in someone else request to get one approved that they should
> just sent a message to dev but that's not really a process, it's just
> hiding the fact there isn't really one.
>
> Also who gets to flag an issue as 9.0, I guess in general what makes an
> issue relevant to a particular version or not.
>
> As we move to integrating the next code donation, there will now be two
> parallel streams running. Bug fixing/enhancing the current code base and
> integrating the new modules. What is the strategy here, branching seems
> like best approach here but it looks like aren't doing this. What is the
> plan to effectively manage the two streams?
>
> On Thu, 26 Apr 2018, 18:56 Laszlo Kishalmi, 
> wrote:
>
> > Well,
> >
> > I'm trying to collect the remaining things to do for 9.0 release for a
> > week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
> > numbers are the following (none may be accurate, though):
> >
> > We have 31 open PR-s in GitHub (not necessary 9.0 related)
> >
> > We have 44 open issues with PR-s.
> >
> > We have 32 open issues marked for 9.0
> >
> > We also have 5 open issues with PR-s for 9.0
> >
> > The issues and PRs are not really aligned.
> >
> > Well this does not necessarily means that we should not branch for
> > release. I just would like to say, we probably need to be more focused
> > on what we are doing.
> >
> > I could promise to go over the open issues and the PR-s and close those
> > which have merged PRs-.
> >
> > Also I feel the number of open PRs is quite high, though it might really
> > mean that changes that we do not want to include into 9.0 are piling up
> > (indicates the need of the release branch).
> >
> > Also those 5 issues with PR-s might just go into master in the following
> > days and we could make the release branch after that.
> >
> > So If I would vote for release branch now it would be 0/-1 right now as
> > we (or maybe just me) can't really see clearly on 9.0.
> >
> >
> >
> > On 04/17/2018 05:52 AM, Neil C Smith wrote:
> > > On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach <
> jaroslav.tul...@gmail.com>
> > > wrote:
> > >
> > >> Yeah, there are changes in the queue for the master branch that could
> be
> > >> too destabilizing. To avoid something like that to negatively
> influence
> > the
> > >> 9.0 release, I'd suggest to create a branch release/9.0 and put only
> the
> > >> safe fixes ready for 9.0 there. The wild development would continue in
> > the
> > >> master branch.
> > >>
> > > +1 to branching and that.  Longer term perhaps a more gitflow-like
> system
> > > where PR's come into a develop branch too?
> > >
> > >   A question, though - I assume this will branch off master now, not
> from
> > > the beta tag?  Given that in NetCAT we were testing the beta, I assume
> > > there is nothing you'd consider "too destabilizing"  between then and
> > now?
> > >
> > > Best wishes,
> > >
> > > Neil
> >
> >
> > -
> > 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

[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: Time to branch for the release candidate?

[Peter Steele]

Just for my interest, which types of people can approve Pull Requests? As
we are now open source the community is deciding what's important by
providing the PR's but we have quite a few stacked up. It has previously
been mentioned in someone else request to get one approved that they should
just sent a message to dev but that's not really a process, it's just
hiding the fact there isn't really one.

Also who gets to flag an issue as 9.0, I guess in general what makes an
issue relevant to a particular version or not.

As we move to integrating the next code donation, there will now be two
parallel streams running. Bug fixing/enhancing the current code base and
integrating the new modules. What is the strategy here, branching seems
like best approach here but it looks like aren't doing this. What is the
plan to effectively manage the two streams?

On Thu, 26 Apr 2018, 18:56 Laszlo Kishalmi, 
wrote:

> Well,
>
> I'm trying to collect the remaining things to do for 9.0 release for a
> week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in
> numbers are the following (none may be accurate, though):
>
> We have 31 open PR-s in GitHub (not necessary 9.0 related)
>
> We have 44 open issues with PR-s.
>
> We have 32 open issues marked for 9.0
>
> We also have 5 open issues with PR-s for 9.0
>
> The issues and PRs are not really aligned.
>
> Well this does not necessarily means that we should not branch for
> release. I just would like to say, we probably need to be more focused
> on what we are doing.
>
> I could promise to go over the open issues and the PR-s and close those
> which have merged PRs-.
>
> Also I feel the number of open PRs is quite high, though it might really
> mean that changes that we do not want to include into 9.0 are piling up
> (indicates the need of the release branch).
>
> Also those 5 issues with PR-s might just go into master in the following
> days and we could make the release branch after that.
>
> So If I would vote for release branch now it would be 0/-1 right now as
> we (or maybe just me) can't really see clearly on 9.0.
>
>
>
> On 04/17/2018 05:52 AM, Neil C Smith wrote:
> > On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
> > wrote:
> >
> >> Yeah, there are changes in the queue for the master branch that could be
> >> too destabilizing. To avoid something like that to negatively influence
> the
> >> 9.0 release, I'd suggest to create a branch release/9.0 and put only the
> >> safe fixes ready for 9.0 there. The wild development would continue in
> the
> >> master branch.
> >>
> > +1 to branching and that.  Longer term perhaps a more gitflow-like system
> > where PR's come into a develop branch too?
> >
> >   A question, though - I assume this will branch off master now, not from
> > the beta tag?  Given that in NetCAT we were testing the beta, I assume
> > there is nothing you'd consider "too destabilizing"  between then and
> now?
> >
> > Best wishes,
> >
> > Neil
>
>
> -
> 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: Oracle no longer offering JREs for desktops (!!)

[cowwoc]

Nevermind. This seems to be a bit of non-news that's over a month old: 
https://www.theregister.co.uk/2018/03/09/java_release_train_qcon/


Gili

On 2018-04-26 2:15 PM, cowwoc wrote:


Gentlemen,

Most of you will probably be impacted by the following bit of news: 
http://jdk.java.net/11/


Oracle will no longer offer a stand-alone JRE for desktops. Starting 
with JDK 11 Oracle will only produce a JDK and a Server JRE.


I assume this goes hand-in-hand with earlier news that JavaFX is 
getting "open-sourced" and AWT is "here to stay" (for now).


Gili

Re: Tracking Issues, Versions

[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

[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

Oracle no longer offering JREs for desktops (!!)

[cowwoc]

Gentlemen,

Most of you will probably be impacted by the following bit of news: 
http://jdk.java.net/11/


Oracle will no longer offer a stand-alone JRE for desktops. Starting 
with JDK 11 Oracle will only produce a JDK and a Server JRE.


I assume this goes hand-in-hand with earlier news that JavaFX is getting 
"open-sourced" and AWT is "here to stay" (for now).


Gili

Re: Time to branch for the release candidate?

[Laszlo Kishalmi]

Well,

I'm trying to collect the remaining things to do for 9.0 release for a 
week now, from GitHub PR-s, JIRA and this mailing list. Regarding 9.0 in 
numbers are the following (none may be accurate, though):


We have 31 open PR-s in GitHub (not necessary 9.0 related)

We have 44 open issues with PR-s.

We have 32 open issues marked for 9.0

We also have 5 open issues with PR-s for 9.0

The issues and PRs are not really aligned.

Well this does not necessarily means that we should not branch for 
release. I just would like to say, we probably need to be more focused 
on what we are doing.


I could promise to go over the open issues and the PR-s and close those 
which have merged PRs-.


Also I feel the number of open PRs is quite high, though it might really 
mean that changes that we do not want to include into 9.0 are piling up 
(indicates the need of the release branch).


Also those 5 issues with PR-s might just go into master in the following 
days and we could make the release branch after that.


So If I would vote for release branch now it would be 0/-1 right now as 
we (or maybe just me) can't really see clearly on 9.0.




On 04/17/2018 05:52 AM, Neil C Smith wrote:

On Tue, 17 Apr 2018 at 12:10 Jaroslav Tulach 
wrote:


Yeah, there are changes in the queue for the master branch that could be
too destabilizing. To avoid something like that to negatively influence the
9.0 release, I'd suggest to create a branch release/9.0 and put only the
safe fixes ready for 9.0 there. The wild development would continue in the
master branch.


+1 to branching and that.  Longer term perhaps a more gitflow-like system
where PR's come into a develop branch too?

  A question, though - I assume this will branch off master now, not from
the beta tag?  Given that in NetCAT we were testing the beta, I assume
there is nothing you'd consider "too destabilizing"  between then and now?

Best wishes,

Neil



-
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: Time to branch for the release candidate?

[Jan Lahoda]

I think a release branch serves several purposes, among others:
-ability to add changes that are specific for the release (in case of
NetBeans things like: release branding, updating module spec. versions to
release format, disabling exceptions, etc.)
-let development (features and general bugfixing) continue even during the
late pre-release stages. This may include:
--allowing bugfixes that are not crucial, or simply too dangerous, for the
release
--allowing (shared) development during the final stages of the release (in
our current situation, this may take quite some time: voting for a release
cadidate takes roughly a week (3 days here, 3 days on the incubator), so if
the release votes fail a few times, the final stages can easily span
several weeks)
-ability to release update release for several past major releases (not
that this would be used much in NetBeans in the past)

I think feature branches are good to develop a (biggish) feature, but when
it is (almost) ready, it needs to be part of some kind of a shared branch,
otherwise people won't (be able to) test and use it.

I agree that the mainline should work as best as it can (and I am myself
running a bleeding edge NetBeans on a bleeding edge JDK), but I think this
is for folks that don't mind (too much) reverting to their last good build
if the new one does not work good enough (which inevitably happens from
time to time, when using bleeding edge).

Jan


On Thu, Apr 26, 2018 at 4:08 PM, Wade Chandler 
wrote:

> +1 and even if we don’t have a “dev” branch, I think we should be able to
> release from master without branching. We should be working to stabilize
> things near a release, and perhaps we ask folks not to merge new features
> to master, but only fixes for a period of time. If we could support feature
> flags, then even better, and for new modules and such I think we can
> through configuration and clusters, to not have them enabled and included
> by default, but not with big new features to existing modules. We would
> need new switches in the config file for those. Then new work can be
> enabled or disabled for a release depending on how far along it is.
>
> Either way, I feel master should always build, run, and be as stable as
> possible. Now, in this interim phase where we are still trying to get over
> to Apache all that is NB, it may be harder or nearly impossible since it is
> so much to bring over, but I think that should be our goal going forward
> once the “drop” has happened.
>
> My $0.02,
>
> Wade
>
>
> ===
>
> Wade Chandler
> e: cons...@wadechandler.com
> t: @wadechandler
> https://www.linkedin.com/in/wade-chandler
>
>
> > On Apr 17, 2018, at 10:09 AM, Christian Lenz 
> wrote:
> >
> > Master shouldn’t be that one, where the wild development is going on.
> Master should be that one which is already live.
> > In General, what gitflow does. Wild development is going on on the dev
> branch, for the next release. If whatever is finished, there is a release
> branch. After that, it will merged into master and created a tag.
> >
> > If this is not possible, then an other solution is that develop stays
> clean and always releasable. You only work on Feature branches. After the
> Feature is finished and ready to go, it will merged into develop. Someday
> you can create a release branch of develop.
> >
>
>
> -
> 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: What Coding Conventions Should We Follow Now? What should the IDE default to?

[cowwoc]

Buhahaha.

I disagree (I believe that "smart" tabs is far superior to space-based 
indentation), but I don't care enough to debate it on this mailing list. 
We all know this point has been beaten to death for decades now.


On a side-note, in my experience checkstyle is a net loss on most 
projects. The cost/benefit of using it relatively high, with users 
having to suppress rules (usually due to bugs in checkstyle itself) 
quite often. Javascript frameworks (e.g. ESLint) are way ahead of Java 
on this point (I guess they have to be due to lack of strong typing).


Gili

On 2018-04-26 11:02 AM, Victor Williams Stafusa da Silva wrote:

Whatever is the convention adopted, I only implore one thing: Do not allow
tabs be the default setting!

By the way, a better integration with checkstyle would be welcome.

Victor Williams Stafusa da Silva

2018-04-26 11:32 GMT-03:00 Wade Chandler :


On Mar 16, 2018, at 6:46 AM, Emilian Bold 

wrote:

Rather than discussing the actual conventions, make sure the IDE can

read and apply settings from Eclipse easily and exactly.

Not sure what this means. Just make sure plugins are able to format the

code?

Still, NetBeans does provide formatting and coding hints. Both should

follow /something/ and I assume Wade was wondering what standard to follow.
Exactly, and too, what makes the most sense.


My angle is that NetBeans, just like Eclipse, *is* a de-facto standard.

I don’t necessarily agree this makes the most sense, but I understand your
point. I guess for me this comes up as a source of friction when working on
projects. Intellij is by far the most used with Eclipse next, and then us.
I think either choosing some agnostic, and well written standard, or using
a real de-facto, sort of like how Spring became one over JEE, being used
more, makes for less friction.

Perhaps the answer is to provide NBs historical one as it is our code
base, and use that one with our project (NetBeans itself). Then provide
some others which are largely popular such as IntelliJ, Eclipse, Google,
and “Old Sun Java” for users of the IDE to use out of the box. It doesn’t
seem likely teams are going to go, oh, yeah, the few NB IDE users
formatting options win out over everybody else, and too, other projects are
not likely to provide a format which is easy to just import without some
upfront setup on behalf of the NB users. Too, most places in my experience
don’t come up with their own formatting. They generally pick one which
exists and is published. Us providing common ones makes that even easier
for IDE users.

Thanks for the replies and feedback all. I think I’ll look at this area
soon to see what can be done.

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


-
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: What Coding Conventions Should We Follow Now? What should the IDE default to?

[Victor Williams Stafusa da Silva]

Whatever is the convention adopted, I only implore one thing: Do not allow
tabs be the default setting!

By the way, a better integration with checkstyle would be welcome.

Victor Williams Stafusa da Silva

2018-04-26 11:32 GMT-03:00 Wade Chandler :

>
> > On Mar 16, 2018, at 6:46 AM, Emilian Bold 
> wrote:
> >
> >> Rather than discussing the actual conventions, make sure the IDE can
> read and apply settings from Eclipse easily and exactly.
> >
> > Not sure what this means. Just make sure plugins are able to format the
> code?
> >
> > Still, NetBeans does provide formatting and coding hints. Both should
> follow /something/ and I assume Wade was wondering what standard to follow.
> >
>
> Exactly, and too, what makes the most sense.
>
> > My angle is that NetBeans, just like Eclipse, *is* a de-facto standard.
>
> I don’t necessarily agree this makes the most sense, but I understand your
> point. I guess for me this comes up as a source of friction when working on
> projects. Intellij is by far the most used with Eclipse next, and then us.
> I think either choosing some agnostic, and well written standard, or using
> a real de-facto, sort of like how Spring became one over JEE, being used
> more, makes for less friction.
>
> Perhaps the answer is to provide NBs historical one as it is our code
> base, and use that one with our project (NetBeans itself). Then provide
> some others which are largely popular such as IntelliJ, Eclipse, Google,
> and “Old Sun Java” for users of the IDE to use out of the box. It doesn’t
> seem likely teams are going to go, oh, yeah, the few NB IDE users
> formatting options win out over everybody else, and too, other projects are
> not likely to provide a format which is easy to just import without some
> upfront setup on behalf of the NB users. Too, most places in my experience
> don’t come up with their own formatting. They generally pick one which
> exists and is published. Us providing common ones makes that even easier
> for IDE users.
>
> Thanks for the replies and feedback all. I think I’ll look at this area
> soon to see what can be done.
>
> Wade
>
>
> ===
>
> Wade Chandler
> e: cons...@wadechandler.com
> t: @wadechandler
> https://www.linkedin.com/in/wade-chandler
>
>
> -
> 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: What Coding Conventions Should We Follow Now? What should the IDE default to?

[Wade Chandler]

> On Mar 16, 2018, at 6:46 AM, Emilian Bold  wrote:
> 
>> Rather than discussing the actual conventions, make sure the IDE can read 
>> and apply settings from Eclipse easily and exactly.
> 
> Not sure what this means. Just make sure plugins are able to format the code?
> 
> Still, NetBeans does provide formatting and coding hints. Both should follow 
> /something/ and I assume Wade was wondering what standard to follow.
> 

Exactly, and too, what makes the most sense.

> My angle is that NetBeans, just like Eclipse, *is* a de-facto standard. 

I don’t necessarily agree this makes the most sense, but I understand your 
point. I guess for me this comes up as a source of friction when working on 
projects. Intellij is by far the most used with Eclipse next, and then us. I 
think either choosing some agnostic, and well written standard, or using a real 
de-facto, sort of like how Spring became one over JEE, being used more, makes 
for less friction.

Perhaps the answer is to provide NBs historical one as it is our code base, and 
use that one with our project (NetBeans itself). Then provide some others which 
are largely popular such as IntelliJ, Eclipse, Google, and “Old Sun Java” for 
users of the IDE to use out of the box. It doesn’t seem likely teams are going 
to go, oh, yeah, the few NB IDE users formatting options win out over everybody 
else, and too, other projects are not likely to provide a format which is easy 
to just import without some upfront setup on behalf of the NB users. Too, most 
places in my experience don’t come up with their own formatting. They generally 
pick one which exists and is published. Us providing common ones makes that 
even easier for IDE users.

Thanks for the replies and feedback all. I think I’ll look at this area soon to 
see what can be done.

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


-
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: Time to branch for the release candidate?

[Wade Chandler]

+1 and even if we don’t have a “dev” branch, I think we should be able to 
release from master without branching. We should be working to stabilize things 
near a release, and perhaps we ask folks not to merge new features to master, 
but only fixes for a period of time. If we could support feature flags, then 
even better, and for new modules and such I think we can through configuration 
and clusters, to not have them enabled and included by default, but not with 
big new features to existing modules. We would need new switches in the config 
file for those. Then new work can be enabled or disabled for a release 
depending on how far along it is.

Either way, I feel master should always build, run, and be as stable as 
possible. Now, in this interim phase where we are still trying to get over to 
Apache all that is NB, it may be harder or nearly impossible since it is so 
much to bring over, but I think that should be our goal going forward once the 
“drop” has happened.

My $0.02,

Wade


===

Wade Chandler
e: cons...@wadechandler.com
t: @wadechandler
https://www.linkedin.com/in/wade-chandler


> On Apr 17, 2018, at 10:09 AM, Christian Lenz  wrote:
> 
> Master shouldn’t be that one, where the wild development is going on. Master 
> should be that one which is already live.
> In General, what gitflow does. Wild development is going on on the dev 
> branch, for the next release. If whatever is finished, there is a release 
> branch. After that, it will merged into master and created a tag.
> 
> If this is not possible, then an other solution is that develop stays clean 
> and always releasable. You only work on Feature branches. After the Feature 
> is finished and ready to go, it will merged into develop. Someday you can 
> create a release branch of develop.
> 


-
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

which build?

[Glenn Holmer]

What's the difference between the builds from incubator-netbeans-linux
and those from incubator-netbeans-release?

-- 
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."

-
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: [EVENT] NetBeans Day UK Reminder

[Ovidijus Okinskas]

Just to follow-up on this. The live-stream will be available on this 
Twitter page: https://twitter.com/NetBeansDayUK


There is no direct link until the stream begins. You can expect the 
stream to be from ~9am-4:30pm although I'm not aware of specific details 
(if there will be downtime during breaks etc).


I can also confirm talks will be recorded and uploaded (with permission 
from the speakers).


Regards,

Ovi


On 26/04/2018 10:06, Ovidijus Okinskas wrote:
We have partnered up with media/marketing/graphic design students at 
the University of Greenwich who are keen to participate in making the 
event a success. They have produced marketing material targeted at 
other students and have been a big help so far.


They will be handling live-streaming of the event on Twitter and 
photography. I'm sure the live-stream will also produce videos of the 
talks which can be published later (if the speakers wish to do so).


I will follow-up to make sure the content is available and post again 
here when it is.


Hope that helps.

Ovi

On 26/04/2018 00:44, Ömer Halit Çizmeci wrote:

Hi all,

I wish I could attend the NetBeans day but unfortunately I am not 
living in
the UK. I've just joined this mailing group and I hope I can take a 
role in

NetBeans development.

It'd be great if somehow we could get video clips of the talks.

On 25 Apr 2018 17:48, "Ovi IDR"  wrote:

Hi all,

Just a quick reminder that NetBeans Day UK is this Friday, 27th 
April. If
you are interested and have not reserved your spot there are still 
tickets

available so be sure to register here (it’s free):

https://www.eventbrite.co.uk/e/apache-netbeans-day-uk-2018-tickets-43401128945 


<
https://www.eventbrite.co.uk/e/apache-netbeans-day-uk-2018-tickets-43401128945 

For those of you attending, I created a short blog post to remind 
attendees

of how to prepare for the event here:

https://blog.idrsolutions.com/2018/04/5-tips-for-getting-the-most-out-of-apache-netbeans-day-uk/ 


<
https://blog.idrsolutions.com/2018/04/5-tips-for-getting-the-most-out-of-apache-netbeans-day-uk/ 


Hope to see you there!


Ovi




-
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: [EVENT] NetBeans Day UK Reminder

[Ovidijus Okinskas]

We have partnered up with media/marketing/graphic design students at the 
University of Greenwich who are keen to participate in making the event 
a success. They have produced marketing material targeted at other 
students and have been a big help so far.


They will be handling live-streaming of the event on Twitter and 
photography. I'm sure the live-stream will also produce videos of the 
talks which can be published later (if the speakers wish to do so).


I will follow-up to make sure the content is available and post again 
here when it is.


Hope that helps.

Ovi

On 26/04/2018 00:44, Ömer Halit Çizmeci wrote:

Hi all,

I wish I could attend the NetBeans day but unfortunately I am not living in
the UK. I've just joined this mailing group and I hope I can take a role in
NetBeans development.

It'd be great if somehow we could get video clips of the talks.

On 25 Apr 2018 17:48, "Ovi IDR"  wrote:

Hi all,

Just a quick reminder that NetBeans Day UK is this Friday, 27th April. If
you are interested and have not reserved your spot there are still tickets
available so be sure to register here (it’s free):

https://www.eventbrite.co.uk/e/apache-netbeans-day-uk-2018-tickets-43401128945
<
https://www.eventbrite.co.uk/e/apache-netbeans-day-uk-2018-tickets-43401128945
For those of you attending, I created a short blog post to remind attendees
of how to prepare for the event here:

https://blog.idrsolutions.com/2018/04/5-tips-for-getting-the-most-out-of-apache-netbeans-day-uk/
<
https://blog.idrsolutions.com/2018/04/5-tips-for-getting-the-most-out-of-apache-netbeans-day-uk/
Hope to see you there!


Ovi




-
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