[GitHub] incubator-netbeans pull request #21: Fixing form files license headers

[jlahoda]

GitHub user jlahoda opened a pull request:

https://github.com/apache/incubator-netbeans/pull/21

Fixing form files license headers

There are intentionally 4 separate commits in this pull request:
1. fixing a typo in two license headers
2. running the header conversion tool so that it rewrites the license 
header in the two files fixed by the previous commit
3. running the (new) conversion tool AddFormLicense which adds the Apache 
licence header to form files that have an adjacent java file with the Apache 
license header (it won't touch files that don't have adjacent java files, or if 
the adjacent java file does not have the Apache license header).
4. excluding form/test/unit/data/goldenfiles/* (form module test data) from 
Rat report

After these, the Rat report shouldn't include any form files.

I have a prototype of a form module change to keep the leading comments in 
form files on modifications (which would keep the license header on 
modification), I'll submit this separately.

Comments are welcome.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jlahoda/incubator-netbeans 
form-files-license-headers

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-netbeans/pull/21.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #21


commit 557c70d31ffd45f0070aea60fb53c899a88d2ec2
Author: Jan Lahoda 
Date:   2017-09-28T05:27:48Z

Fixing typos in two license headers.

commit af9caae253ee49f32b6015aeb71a19fb86e4aeca
Author: Jan Lahoda 
Date:   2017-09-28T05:35:40Z

Applying the header conversion tool to the files fixed by the previous 
commit, so that the license header is re-written for these files.

commit c6d9bafda62db52d4471442589403bc017a7ba45
Author: Jan Lahoda 
Date:   2017-09-28T05:38:21Z

Adding license header to form files whose adjacent java files have the 
appropriate license header.

commit 3686243742d5c46279e964dd44ffd4f62e1ce3e4
Author: Jan Lahoda 
Date:   2017-09-28T05:47:41Z

Excluding form test data from Rat.




---

Podling Report Reminder - October 2017

[johndament]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 18 October 2017, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, October 04).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://wiki.apache.org/incubator/October2017

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

[GitHub] incubator-netbeans pull request #9: [NETBEANS-54] Module Review openide.util...

[emilianbold]

Github user emilianbold closed the pull request at:

https://github.com/apache/incubator-netbeans/pull/9


---

[GitHub] incubator-netbeans issue #9: [NETBEANS-54] Module Review openide.util.*

[emilianbold]

Github user emilianbold commented on the issue:

https://github.com/apache/incubator-netbeans/pull/9
  
I merged the PR changes into master.


---

[GitHub] incubator-netbeans issue #11: Fixes bug in FileChooserBuilderTest

[emilianbold]

Github user emilianbold commented on the issue:

https://github.com/apache/incubator-netbeans/pull/11
  
You are right about the cleanup, of course. I've pushed another commit that 
uses getWorkDir() instead. This seems to be the standard. Cleanup is not 
assumed unless clearWorkDir is called.


---

[GitHub] incubator-netbeans issue #6: [NETBEANS-54] Module Review db

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/6
  
@svenreimers @jlahoda thanks for taking time for review!

I merged the change into master. I'm manually closing this here, as the 
merge was done as a fast-forward merge and so no merge commit was created.


---

[GitHub] incubator-netbeans pull request #6: [NETBEANS-54] Module Review db

[matthiasblaesing]

Github user matthiasblaesing closed the pull request at:

https://github.com/apache/incubator-netbeans/pull/6


---

[GitHub] incubator-netbeans issue #19: [NETBEANS-54] Module Review openide.nodes

[jlahoda]

Github user jlahoda commented on the issue:

https://github.com/apache/incubator-netbeans/pull/19
  
Looks OK to me.


---

Re: [GitHub] incubator-netbeans issue #6: [NETBEANS-54] Module Review db

[Geertjan Wielenga]

Indeed, if there's been discussion about a PR and if there's agreement on
it (and no big disagreements) and if you're a comitter... go ahead and do
the push.

Gj

On Wed, 27 Sep 2017 at 20:54, jlahoda  wrote:

> Github user jlahoda commented on the issue:
>
> https://github.com/apache/incubator-netbeans/pull/6
>
> Matthias, you are an Apache Netbeans committer, right? So you should
> be able to push this directly to the apache repository (
> https://git-wip-us.apache.org/repos/asf/incubator-netbeans). (I would
> suggest to rebase the changes before merging so that there's no actual
> merge commit, but up to you, I am not a git expert.) Please let me know if
> you need any help.
>
> Thanks for working on this!
>
>
> ---
>

[GitHub] incubator-netbeans issue #17: [NETBEANS-54] Module Review openide.text

[jlahoda]

Github user jlahoda commented on the issue:

https://github.com/apache/incubator-netbeans/pull/17
  
Looks OK to me.


---

[GitHub] incubator-netbeans issue #6: [NETBEANS-54] Module Review db

[jlahoda]

Github user jlahoda commented on the issue:

https://github.com/apache/incubator-netbeans/pull/6
  
Matthias, you are an Apache Netbeans committer, right? So you should be 
able to push this directly to the apache repository 
(https://git-wip-us.apache.org/repos/asf/incubator-netbeans). (I would suggest 
to rebase the changes before merging so that there's no actual merge commit, 
but up to you, I am not a git expert.) Please let me know if you need any help.

Thanks for working on this!


---

[GitHub] incubator-netbeans issue #14: [NETBEANS-54] Module Review o.n.swing.tabcontr...

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/14
  
+1


---

[GitHub] incubator-netbeans issue #13: [NETBEANS-54] Module Review openide.modules

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/13
  
+1


---

[GitHub] incubator-netbeans issue #11: Fixes bug in FileChooserBuilderTest

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/11
  
I agree with your interpretation, but I'm missing cleanup of the created 
file in this test. What do you think about this alternative approach:
- use `java.io.File#createTempFile` to create a test file at the beginning 
of the test
- wrap the test procedure in to a `try {} finally {}` and delete the temp 
file in the finally clause


---

[GitHub] incubator-netbeans issue #10: [NETBEANS-54] Module Review openide.filesystem...

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/10
  
+1


---

[GitHub] incubator-netbeans issue #9: [NETBEANS-54] Module Review openide.util.*

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/9
  
+1


---

[GitHub] incubator-netbeans issue #8: [NETBEANS-54] Module Review api.htmlui

[matthiasblaesing]

Github user matthiasblaesing commented on the issue:

https://github.com/apache/incubator-netbeans/pull/8
  
+1


---

Re: How do we want to do merges?

[Matthias Bläsing]

Hi,

Am Mittwoch, den 27.09.2017, 10:25 +0200 schrieb Geertjan Wielenga:
> 
> So, the question is, how do we want to do merges of PRs and also what
> should the workflow be. These are decisions we can make as a
> community.
> 
> For example, this PR by Eric Barboni, seems a logical one to want to
> merge, i.e., its an addition to our Rat setup that we logically would
> want to have, i.e., there's no reason not to have it and everyone in
> the PR agrees with it:
> 
> https://github.com/apache/incubator-netbeans/pull/12
> 
> If the person providing a PR is a committer, after there is agreement
> on the PR, the committer could then push that PR to the Apache Git
> repo themselves, for example.

I agree with this assessment. This would need to be reevaluated, if
reviews are not done and thus fixes would be blocked from entering the
repository.

Greetings

Matthias

[GitHub] incubator-netbeans pull request #20: [NETBEANS-54] Module Review db.drivers

[matthiasblaesing]

GitHub user matthiasblaesing opened a pull request:

https://github.com/apache/incubator-netbeans/pull/20

[NETBEANS-54] Module Review db.drivers

- updated binaries-list to maven coordinates and ensured consitent
  naming after build

- checked Rat report: everything has been relicensed to Apache,
  included in 'central problems' list above, or excluded via Rat

- skimmed through module, did not notice additional problems

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/matthiasblaesing/incubator-netbeans 
db.drivers-review

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-netbeans/pull/20.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #20


commit 5757dd81645aa338084c48b8cb7f4e3147606e57
Author: Matthias Bläsing 
Date:   2017-09-27T17:27:36Z

[NETBEANS-54] Module Review db.drivers

- updated binaries-list to maven coordinates and ensured consitent
  naming after build

- checked Rat report: everything has been relicensed to Apache,
  included in 'central problems' list above, or excluded via Rat

- skimmed through module, did not notice additional problems




---

Re: [IP Clearance] Portions Copyrighted 2007 Sun Microsystems, Inc.

[Matthias Bläsing]

Hi,

Am Mittwoch, den 27.09.2017, 17:13 +0200 schrieb Geertjan Wielenga:
> Maybe you can look into the tool and add these into it.
> 

and before this tool is run again and does mass changes, the current
open PULLs should be pulled. Else you potentially destroy human work
and introduce merge conflicts.

Greetings

Matthias

Re: [Mentors] Towards release of HTML/Java API

[Jaroslav Tulach]

On pondělí 11. září 2017 9:29:02 CEST Bertrand Delacretaz wrote:
> On Sun, Sep 10, 2017 at 5:23 AM, Jaroslav Tulach
> 
>  wrote:
> > ...Dear mentors, please advice me how to proceed to release...
> 
> I have sent the relevant links to this list a few times already,
> please check the archives.

Hello Bertrand.
I found 
https://incubator.apache.org/policy/incubation.html
https://incubator.apache.org/guides/releasemanagement.html

I'd like to proceed with a release of HTML/Java API. Am I supposed to send an 
email like http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/
200601.mbox/%3c43c1c0a0.7040...@roguewave.com%3e
to this mailing list and wait for the votes?

> > ..and step out of incubator with the Apache HTML/Java NetBeans API
> > repository...
> The NetBeans podling will graduate as a whole when its community is
> ready for that.

OK, when you say so.
-jt

Re: [IP Clearance] Portions Copyrighted 2007 Sun Microsystems, Inc.

[Geertjan Wielenga]

Maybe you can look into the tool and add these into it.

Gj

On Wed, Sep 27, 2017 at 5:09 PM, Emilian Bold 
wrote:

> Sure, the tool should try to catch most of these.
>
> $ grep -R 'Sun Micro' . | grep -v  "/DTD " | grep -v "XMLSPY" | cut
> -f1 -d':' | uniq
>
> finds "Sun Microsystems" 351 times on my repo. But I think the same
> pattern repeats a lot of times, like:
>
> # The Original Software is NetBeans. The Initial Developer of the Original
> # Software is Sun Microsystems, Inc. Portions Copyright 2009-2010 Sun
> # Microsystems, Inc. All Rights Reserved.
>
>
> --emi
>
>
> On Wed, Sep 27, 2017 at 6:00 PM, Geertjan Wielenga
>  wrote:
> > Yes, those can be relicensed, but I'd suggest we (Jan?)
> > investigate/incorporate that pattern into the tool (
> > https://github.com/apache/incubator-netbeans-tools) so we can automate
> this
> > in order to (1) catch as many as possible at the same time and (2) avoid
> > error-prone and unnecessary manual changes.
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 4:57 PM, Emilian Bold 
> > wrote:
> >
> >> Hello,
> >>
> >> I see some headers (like [1]) with the usual Oracle copyright
> >>
> >> > Copyright 1997-2010 Oracle and/or its affiliates. All rights reserved.
> >>
> >> but some contributors listed as:
> >>
> >> > * The Original Software is NetBeans.
> >> > * Portions Copyrighted 2007 Sun Microsystems, Inc.
> >>
> >> Since I'm assuming there was a proper NetBeans -> Sun Microsystems ->
> >> Oracle IP transfer, we are clear to replace such headers, no?
> >>
> >> 1.
> >> https://github.com/apache/incubator-netbeans/blob/
> >> master/openide.text/src/org/openide/text/CloneableEditorSupportRedirect
> >> or.java
> >>
> >> --emi
> >>
>

Re: [IP Clearance] Portions Copyrighted 2007 Sun Microsystems, Inc.

[Emilian Bold]

Sure, the tool should try to catch most of these.

$ grep -R 'Sun Micro' . | grep -v  "/DTD " | grep -v "XMLSPY" | cut
-f1 -d':' | uniq

finds "Sun Microsystems" 351 times on my repo. But I think the same
pattern repeats a lot of times, like:

# The Original Software is NetBeans. The Initial Developer of the Original
# Software is Sun Microsystems, Inc. Portions Copyright 2009-2010 Sun
# Microsystems, Inc. All Rights Reserved.


--emi


On Wed, Sep 27, 2017 at 6:00 PM, Geertjan Wielenga
 wrote:
> Yes, those can be relicensed, but I'd suggest we (Jan?)
> investigate/incorporate that pattern into the tool (
> https://github.com/apache/incubator-netbeans-tools) so we can automate this
> in order to (1) catch as many as possible at the same time and (2) avoid
> error-prone and unnecessary manual changes.
>
> Gj
>
> On Wed, Sep 27, 2017 at 4:57 PM, Emilian Bold 
> wrote:
>
>> Hello,
>>
>> I see some headers (like [1]) with the usual Oracle copyright
>>
>> > Copyright 1997-2010 Oracle and/or its affiliates. All rights reserved.
>>
>> but some contributors listed as:
>>
>> > * The Original Software is NetBeans.
>> > * Portions Copyrighted 2007 Sun Microsystems, Inc.
>>
>> Since I'm assuming there was a proper NetBeans -> Sun Microsystems ->
>> Oracle IP transfer, we are clear to replace such headers, no?
>>
>> 1.
>> https://github.com/apache/incubator-netbeans/blob/
>> master/openide.text/src/org/openide/text/CloneableEditorSupportRedirect
>> or.java
>>
>> --emi
>>

Re: [IP Clearance] Portions Copyrighted 2007 Sun Microsystems, Inc.

[Geertjan Wielenga]

Yes, those can be relicensed, but I'd suggest we (Jan?)
investigate/incorporate that pattern into the tool (
https://github.com/apache/incubator-netbeans-tools) so we can automate this
in order to (1) catch as many as possible at the same time and (2) avoid
error-prone and unnecessary manual changes.

Gj

On Wed, Sep 27, 2017 at 4:57 PM, Emilian Bold 
wrote:

> Hello,
>
> I see some headers (like [1]) with the usual Oracle copyright
>
> > Copyright 1997-2010 Oracle and/or its affiliates. All rights reserved.
>
> but some contributors listed as:
>
> > * The Original Software is NetBeans.
> > * Portions Copyrighted 2007 Sun Microsystems, Inc.
>
> Since I'm assuming there was a proper NetBeans -> Sun Microsystems ->
> Oracle IP transfer, we are clear to replace such headers, no?
>
> 1.
> https://github.com/apache/incubator-netbeans/blob/
> master/openide.text/src/org/openide/text/CloneableEditorSupportRedirect
> or.java
>
> --emi
>

[IP Clearance] Portions Copyrighted 2007 Sun Microsystems, Inc.

[Emilian Bold]

Hello,

I see some headers (like [1]) with the usual Oracle copyright

> Copyright 1997-2010 Oracle and/or its affiliates. All rights reserved.

but some contributors listed as:

> * The Original Software is NetBeans.
> * Portions Copyrighted 2007 Sun Microsystems, Inc.

Since I'm assuming there was a proper NetBeans -> Sun Microsystems ->
Oracle IP transfer, we are clear to replace such headers, no?

1.
https://github.com/apache/incubator-netbeans/blob/master/openide.text/src/org/openide/text/CloneableEditorSupportRedirector.java

--emi

Re: YouTube -- explaining the Module Review process (and how to participate)

[John D. Ament]

To be honest, if you had a release where we know that all files granted by 
Oracle that have the Oracle/Sun header now wear the ASF license header + the 
files without headers are known to be licensed to Apache but don't have headers 
for $reasons, that may be a viable release.  Its not uncommon for podlings to 
be missing license headers, since we need to figure out the provenance.

John

On 2017-09-27 08:44, Geertjan Wielenga  
wrote: 
> A related question -- how imperfect does our first incubator release need
> to be? If we were to focus narrowly on the NetBeans Platform (i.e., the
> core, used by a significant number of significant organizations
> https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans),
> then we'd be including 3 GPL binaries -- SwingX, JDesktopLayout, and jhall
> (for JavaHelp).
> 
> My (and I think our) assumption has been that we absolutely must remove
> those JAR files or find some kind of solution that excludes them completely
> prior to our first incubator release.
> 
> But maybe that assumption is wrong? As long as we have clearly agreed and
> documented plans to replace these with something different -- and bear in
> mind we're not talking about source code here, i.e., none of these GPL
> sources are in Apache NetBeans, we're only talking about inclusion in the
> convenience binary -- then could we have our first incubator release with
> these GPL binaries included in the convenience binary?
> 
> Thanks, and just wondering.
> 
> Gj
> 
> On Wed, Sep 27, 2017 at 2:34 PM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
> 
> > We now have a disclaimer: https://github.com/apache/incubator-netbeans/
> > blob/master/DISCLAIMER
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 2:26 PM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> >
> >> Sure, thanks.
> >>
> >> I think we're aware it doesn't have to be perfect the first time around,
> >> and it's good to have this reconfirmed.
> >>
> >> The content of the video wasn't reviewed by our mentors, but I believe
> >> everything in there is basically a summary of mails and discussions, if
> >> something in there is incomplete or incorrect, that's good to know.
> >>
> >> Gj
> >>
> >> On Wed, Sep 27, 2017 at 1:57 PM, John D. Ament 
> >> wrote:
> >>
> >>> Geertjan,
> >>>
> >>> Did you review the content of this video with your mentors?  There's one
> >>> extremely important thing I heard in this video.  "During the incubation
> >>> process."  The Incubation process does not end at your first release.  It
> >>> ends when the community believes they have embraced the Apache Way well
> >>> enough.
> >>>
> >>> Basically what I'm trying to say is that your first release doesn't have
> >>> to be perfect, we expect every release performed by a podling to get
> >>> progressively better.  Every incubator project must include a DISCLAIMER
> >>> file indicating that the project is under going incubation, which implies:
> >>>
> >>> - The community could disappear due to lack of ability to become an
> >>> Apache project.
> >>> - The release contents may have issues within them, so please use
> >>> caution.
> >>>
> >>> It doesn't look like Netbeans has their disclaimer file yet, but here's
> >>> an example from Freemarker: https://github.com/apache/incu
> >>> bator-freemarker/blob/2.3-gae/DISCLAIMER
> >>>
> >>> John
> >>>
> >>> On 2017-09-26 09:21, Geertjan Wielenga 
> >>> wrote:
> >>> > Hi all,
> >>> >
> >>> > Made a quick 3 minute YouTube clip to help explain what and why we're
> >>> > trying to achieve with this page:
> >>> >
> >>> > https://cwiki.apache.org/confluence/display/NETBEANS/List+of
> >>> +Modules+to+Review
> >>> >
> >>> > Hope it clarifies things -- i.e., no knowledge of NetBeans APIs or even
> >>> > Java is needed, for the basic reviewing tasks and everyone should feel
> >>> > invited to participate:
> >>> >
> >>> > https://www.youtube.com/watch?v=Z4PBNSRp5g8
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Gj
> >>> >
> >>>
> >>
> >>
> >
> 

[GitHub] incubator-netbeans pull request #19: [NETBEANS-54] Module Review openide.nod...

[emilianbold]

GitHub user emilianbold opened a pull request:

https://github.com/apache/incubator-netbeans/pull/19

[NETBEANS-54] Module Review openide.nodes



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/emilianbold/incubator-netbeans 
emi-review-openide.nodes

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-netbeans/pull/19.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #19






---

Re: How do we want to do merges?

[Enrico Olivelli]

Hi,
in BookKeeper we have a script which deals with GitHub pull requests
https://github.com/apache/bookkeeper/blob/master/dev/bk-merge-pr.py

it creates tmp git branches, does squash merges and eventually pushes to
apache, handle commit messages, handles github bug tracker + ASF JIRA
bugtracker + does automatic QA checks

we originally take the idea from other Apache Projects

feel free to use and example

Cheers
Enrico

2017-09-27 15:07 GMT+02:00 Eric Barboni :

> Hi,
> Idea from other Apache project
>
> https://cwiki.apache.org/confluence/display/ROLLER/How+
> to+accept+a+GitHub+Pull+Request
>
> If contribution is not important a icla is not required.
>
> Only commiter can merge pr
>
> Regards
>
> Eric
> -Message d'origine-
> De : Geertjan Wielenga [mailto:geertjan.wiele...@googlemail.com]
> Envoyé : mercredi 27 septembre 2017 10:26
> À : dev@netbeans.incubator.apache.org
> Objet : How do we want to do merges?
>
> Hi all,
>
> Bear in mind that Apache GitHub is a readonly mirror of Apache Git.
>
> So, the question is, how do we want to do merges of PRs and also what
> should the workflow be. These are decisions we can make as a community.
>
> For example, this PR by Eric Barboni, seems a logical one to want to
> merge, i.e., its an addition to our Rat setup that we logically would want
> to have, i.e., there's no reason not to have it and everyone in the PR
> agrees with it:
>
> https://github.com/apache/incubator-netbeans/pull/12
>
> If the person providing a PR is a committer, after there is agreement on
> the PR, the committer could then push that PR to the Apache Git repo
> themselves, for example.
>
> Thoughts welcome.
>
> Gj
>
>

RE: How do we want to do merges?

[Eric Barboni]

Hi, 
Idea from other Apache project

https://cwiki.apache.org/confluence/display/ROLLER/How+to+accept+a+GitHub+Pull+Request

If contribution is not important a icla is not required.

Only commiter can merge pr

Regards

Eric
-Message d'origine-
De : Geertjan Wielenga [mailto:geertjan.wiele...@googlemail.com] 
Envoyé : mercredi 27 septembre 2017 10:26
À : dev@netbeans.incubator.apache.org
Objet : How do we want to do merges?

Hi all,

Bear in mind that Apache GitHub is a readonly mirror of Apache Git.

So, the question is, how do we want to do merges of PRs and also what should 
the workflow be. These are decisions we can make as a community.

For example, this PR by Eric Barboni, seems a logical one to want to merge, 
i.e., its an addition to our Rat setup that we logically would want to have, 
i.e., there's no reason not to have it and everyone in the PR agrees with it:

https://github.com/apache/incubator-netbeans/pull/12

If the person providing a PR is a committer, after there is agreement on the 
PR, the committer could then push that PR to the Apache Git repo themselves, 
for example.

Thoughts welcome.

Gj

Re: YouTube -- explaining the Module Review process (and how to participate)

[Geertjan Wielenga]

A related question -- how imperfect does our first incubator release need
to be? If we were to focus narrowly on the NetBeans Platform (i.e., the
core, used by a significant number of significant organizations
https://cwiki.apache.org/confluence/display/NETBEANS/on+top+of+NetBeans),
then we'd be including 3 GPL binaries -- SwingX, JDesktopLayout, and jhall
(for JavaHelp).

My (and I think our) assumption has been that we absolutely must remove
those JAR files or find some kind of solution that excludes them completely
prior to our first incubator release.

But maybe that assumption is wrong? As long as we have clearly agreed and
documented plans to replace these with something different -- and bear in
mind we're not talking about source code here, i.e., none of these GPL
sources are in Apache NetBeans, we're only talking about inclusion in the
convenience binary -- then could we have our first incubator release with
these GPL binaries included in the convenience binary?

Thanks, and just wondering.

Gj

On Wed, Sep 27, 2017 at 2:34 PM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> We now have a disclaimer: https://github.com/apache/incubator-netbeans/
> blob/master/DISCLAIMER
>
> Gj
>
> On Wed, Sep 27, 2017 at 2:26 PM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
>> Sure, thanks.
>>
>> I think we're aware it doesn't have to be perfect the first time around,
>> and it's good to have this reconfirmed.
>>
>> The content of the video wasn't reviewed by our mentors, but I believe
>> everything in there is basically a summary of mails and discussions, if
>> something in there is incomplete or incorrect, that's good to know.
>>
>> Gj
>>
>> On Wed, Sep 27, 2017 at 1:57 PM, John D. Ament 
>> wrote:
>>
>>> Geertjan,
>>>
>>> Did you review the content of this video with your mentors?  There's one
>>> extremely important thing I heard in this video.  "During the incubation
>>> process."  The Incubation process does not end at your first release.  It
>>> ends when the community believes they have embraced the Apache Way well
>>> enough.
>>>
>>> Basically what I'm trying to say is that your first release doesn't have
>>> to be perfect, we expect every release performed by a podling to get
>>> progressively better.  Every incubator project must include a DISCLAIMER
>>> file indicating that the project is under going incubation, which implies:
>>>
>>> - The community could disappear due to lack of ability to become an
>>> Apache project.
>>> - The release contents may have issues within them, so please use
>>> caution.
>>>
>>> It doesn't look like Netbeans has their disclaimer file yet, but here's
>>> an example from Freemarker: https://github.com/apache/incu
>>> bator-freemarker/blob/2.3-gae/DISCLAIMER
>>>
>>> John
>>>
>>> On 2017-09-26 09:21, Geertjan Wielenga 
>>> wrote:
>>> > Hi all,
>>> >
>>> > Made a quick 3 minute YouTube clip to help explain what and why we're
>>> > trying to achieve with this page:
>>> >
>>> > https://cwiki.apache.org/confluence/display/NETBEANS/List+of
>>> +Modules+to+Review
>>> >
>>> > Hope it clarifies things -- i.e., no knowledge of NetBeans APIs or even
>>> > Java is needed, for the basic reviewing tasks and everyone should feel
>>> > invited to participate:
>>> >
>>> > https://www.youtube.com/watch?v=Z4PBNSRp5g8
>>> >
>>> > Thanks,
>>> >
>>> > Gj
>>> >
>>>
>>
>>
>

Re: YouTube -- explaining the Module Review process (and how to participate)

[Geertjan Wielenga]

We now have a disclaimer:
https://github.com/apache/incubator-netbeans/blob/master/DISCLAIMER

Gj

On Wed, Sep 27, 2017 at 2:26 PM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Sure, thanks.
>
> I think we're aware it doesn't have to be perfect the first time around,
> and it's good to have this reconfirmed.
>
> The content of the video wasn't reviewed by our mentors, but I believe
> everything in there is basically a summary of mails and discussions, if
> something in there is incomplete or incorrect, that's good to know.
>
> Gj
>
> On Wed, Sep 27, 2017 at 1:57 PM, John D. Ament 
> wrote:
>
>> Geertjan,
>>
>> Did you review the content of this video with your mentors?  There's one
>> extremely important thing I heard in this video.  "During the incubation
>> process."  The Incubation process does not end at your first release.  It
>> ends when the community believes they have embraced the Apache Way well
>> enough.
>>
>> Basically what I'm trying to say is that your first release doesn't have
>> to be perfect, we expect every release performed by a podling to get
>> progressively better.  Every incubator project must include a DISCLAIMER
>> file indicating that the project is under going incubation, which implies:
>>
>> - The community could disappear due to lack of ability to become an
>> Apache project.
>> - The release contents may have issues within them, so please use caution.
>>
>> It doesn't look like Netbeans has their disclaimer file yet, but here's
>> an example from Freemarker: https://github.com/apache/incu
>> bator-freemarker/blob/2.3-gae/DISCLAIMER
>>
>> John
>>
>> On 2017-09-26 09:21, Geertjan Wielenga 
>> wrote:
>> > Hi all,
>> >
>> > Made a quick 3 minute YouTube clip to help explain what and why we're
>> > trying to achieve with this page:
>> >
>> > https://cwiki.apache.org/confluence/display/NETBEANS/List+
>> of+Modules+to+Review
>> >
>> > Hope it clarifies things -- i.e., no knowledge of NetBeans APIs or even
>> > Java is needed, for the basic reviewing tasks and everyone should feel
>> > invited to participate:
>> >
>> > https://www.youtube.com/watch?v=Z4PBNSRp5g8
>> >
>> > Thanks,
>> >
>> > Gj
>> >
>>
>
>

Re: YouTube -- explaining the Module Review process (and how to participate)

[Geertjan Wielenga]

Sure, thanks.

I think we're aware it doesn't have to be perfect the first time around,
and it's good to have this reconfirmed.

The content of the video wasn't reviewed by our mentors, but I believe
everything in there is basically a summary of mails and discussions, if
something in there is incomplete or incorrect, that's good to know.

Gj

On Wed, Sep 27, 2017 at 1:57 PM, John D. Ament 
wrote:

> Geertjan,
>
> Did you review the content of this video with your mentors?  There's one
> extremely important thing I heard in this video.  "During the incubation
> process."  The Incubation process does not end at your first release.  It
> ends when the community believes they have embraced the Apache Way well
> enough.
>
> Basically what I'm trying to say is that your first release doesn't have
> to be perfect, we expect every release performed by a podling to get
> progressively better.  Every incubator project must include a DISCLAIMER
> file indicating that the project is under going incubation, which implies:
>
> - The community could disappear due to lack of ability to become an Apache
> project.
> - The release contents may have issues within them, so please use caution.
>
> It doesn't look like Netbeans has their disclaimer file yet, but here's an
> example from Freemarker: https://github.com/apache/
> incubator-freemarker/blob/2.3-gae/DISCLAIMER
>
> John
>
> On 2017-09-26 09:21, Geertjan Wielenga 
> wrote:
> > Hi all,
> >
> > Made a quick 3 minute YouTube clip to help explain what and why we're
> > trying to achieve with this page:
> >
> > https://cwiki.apache.org/confluence/display/NETBEANS/
> List+of+Modules+to+Review
> >
> > Hope it clarifies things -- i.e., no knowledge of NetBeans APIs or even
> > Java is needed, for the basic reviewing tasks and everyone should feel
> > invited to participate:
> >
> > https://www.youtube.com/watch?v=Z4PBNSRp5g8
> >
> > Thanks,
> >
> > Gj
> >
>

Re: YouTube -- explaining the Module Review process (and how to participate)

[John D. Ament]

Geertjan,

Did you review the content of this video with your mentors?  There's one 
extremely important thing I heard in this video.  "During the incubation 
process."  The Incubation process does not end at your first release.  It ends 
when the community believes they have embraced the Apache Way well enough.  

Basically what I'm trying to say is that your first release doesn't have to be 
perfect, we expect every release performed by a podling to get progressively 
better.  Every incubator project must include a DISCLAIMER file indicating that 
the project is under going incubation, which implies:

- The community could disappear due to lack of ability to become an Apache 
project.
- The release contents may have issues within them, so please use caution.

It doesn't look like Netbeans has their disclaimer file yet, but here's an 
example from Freemarker: 
https://github.com/apache/incubator-freemarker/blob/2.3-gae/DISCLAIMER

John

On 2017-09-26 09:21, Geertjan Wielenga  
wrote: 
> Hi all,
> 
> Made a quick 3 minute YouTube clip to help explain what and why we're
> trying to achieve with this page:
> 
> https://cwiki.apache.org/confluence/display/NETBEANS/List+of+Modules+to+Review
> 
> Hope it clarifies things -- i.e., no knowledge of NetBeans APIs or even
> Java is needed, for the basic reviewing tasks and everyone should feel
> invited to participate:
> 
> https://www.youtube.com/watch?v=Z4PBNSRp5g8
> 
> Thanks,
> 
> Gj
> 

Re: Allow code contributions or focus on release only?

[Jan Lahoda]

Hi Emilian,

I appreciate your work on the cleanup.

I guess (virtually) everyone would like to work on new features (like in my
case (Java) Local Variable Type Inference support,
https://cwiki.apache.org/confluence/display/NETBEANS/JDK+Modules+Support+in+NetBeans+Module+System
and others).

But I suspect the first few releases will be very difficult, so my
suggestion would be to use master and code review bandwidth for the cleanup
and the first couple of (Platform and Java IDE) releases for now, and use
branches for features.

Jan


On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
wrote:

> We should also allow some new features and improvements. We cannot have
> NetBeans under Apache for 1 year and basically have no Apache-contributed
> feature to show for, only IP cleanup and stuff like that.
>
> There's a whole lot of contributors and committers: does everybody want to
> do only this? Because I don't!
>
> BTW, how many are being involved in the new Apache build system or IP
> clearance, etc.? I don't see people jumping in on this rather boring job.
>
> So, I *am* doing IP cleanup, but I would most certainly want to commit new
> features and bugfixes! I found and fixed a few bugs just these weeks while
> working on yameter.com
>
> I don't remember agreeing on a feature freeze within Apache, we just got
> the codebase donated.
>
> The community should be able to walk and chew bubble gum at the same time.
> If some people are focusing on the build system I don't see why other
> people can't focus on something else as long as they don't break something
> or get in the way?
>
> The real question is: are we really distributing the load *and trust* among
> committers or not? Because it seems to me everybody is very willing to
> heavily restrict what we should be allowed to do.
>
>
>
> --emi
>
> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
> mblaes...@doppel-helix.eu
> > wrote:
>
> > Hey,
> >
> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
> > > [Discuss-Request: Focus on getting a release out or adding functions]
> >
> > if I'm not mistaken, the netbeans 9 feature freeze had already happened
> >  when the migration to apache began. I would focus on bugfixing and
> > blocking new features.
> >
> > With the apache migration process there is enough development needed,
> > just to get the codebase releaseable. Libraries need to
> > removed/replaced, if the are incompatibe with the apache project
> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
> > installers to get these libraries at runtime need to be implemented.
> >
> > While I agree, that adding new features would pull more potential
> > contributers, I would consider a stable base more important, to get
> > going from there. Java 9 is out and the excitement is already there and
> > people ask for netbeans 9, so I would prioritize that.
> >
> > My 2 cent
> >
> > Matthias
> >
> >
> >
>

[GitHub] incubator-netbeans pull request #18: [NETBEANS-54] Module Review settings

[emilianbold]

GitHub user emilianbold opened a pull request:

https://github.com/apache/incubator-netbeans/pull/18

[NETBEANS-54] Module Review settings



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/emilianbold/incubator-netbeans 
emi-review-settings

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-netbeans/pull/18.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #18


commit ff62698079f4e628618550dc33e84e51b09f4727
Author: Emilian Bold 
Date:   2017-09-27T09:13:15Z

[NETBEANS-54] Module Review settings




---

[GitHub] incubator-netbeans pull request #17: [NETBEANS-54] Module Review openide.tex...

[emilianbold]

GitHub user emilianbold opened a pull request:

https://github.com/apache/incubator-netbeans/pull/17

[NETBEANS-54] Module Review openide.text



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/emilianbold/incubator-netbeans 
emi-review-openide.text

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/incubator-netbeans/pull/17.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #17


commit 67c571bcca67f425fecc6814bfbc8d94264ebb0b
Author: Emilian Bold 
Date:   2017-09-27T08:44:36Z

[NETBEANS-54] Module Review openide.text




---

Re: How to deal with module review without modifications

[Geertjan Wielenga]

Right. And in that case the choice is between extending the tool to capture
that variation or to fix it manually, possibly hundreds of times. Don't
know the 'right' answer or if there is one, but those are the two solutions.

Gj

On Wed, Sep 27, 2017 at 10:34 AM, Emilian Bold 
wrote:

> Well, most Bundle.properties have been automatically updated but if some
> remained I guess the header was slightly off?
>
>
> --emi
>
> On Wed, Sep 27, 2017 at 11:30 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > To me, a "Bundle.properties" is also something that should be solved
> > centrally, since that's a general problem, rather than being a unique or
> > special file type in the module. That's something that should be added to
> > the central problems list, in my understanding of it.
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 10:26 AM, Emilian Bold 
> > wrote:
> >
> > > That's the way I see it.
> > >
> > > Note that Dave mentioned some oversights. For example,
> Bundle.properties
> > > with an Oracle license header.
> > >
> > > Such a thing should be easily double-checked with some 'grep -R Oracle
> '
> > at
> > > some point.
> > >
> > >
> > > --emi
> > >
> > > On Wed, Sep 27, 2017 at 11:11 AM, Geertjan Wielenga <
> > > geertjan.wiele...@googlemail.com> wrote:
> > >
> > > > OK, so, if everything is done except for the central things, then
> it's
> > > > done. I'll revert my "To dos" back to "Dones" and add a note re this
> to
> > > the
> > > > status section at the top of the page.
> > > >
> > > > Gj
> > > >
> > > > On Wed, Sep 27, 2017 at 10:08 AM, Emilian Bold <
> emilian.b...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > I believe modules that still have .form files or other "Problems to
> > be
> > > > > solved centrally" should be marked as "Done".
> > > > >
> > > > > The whole point is to look at everything else. Those problems will
> be
> > > > > solved... centrally.
> > > > >
> > > > >
> > > > > --emi
> > > > >
> > > > > On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > >
> > > > > > OK, I have marked all mine as "To do", since I am relying on the
> > > > central
> > > > > > problems being handled via the tool, i.e., I think all "form"
> > files,
> > > > for
> > > > > > example, should be processed via the tool, rather than doing them
> > > > > > individually and manually per module.
> > > > > >
> > > > > > I think a peer review would be good, and yes, it is very
> important
> > to
> > > > get
> > > > > > the license headers right. A peer review column would be great, I
> > > > think,
> > > > > > i.e., when a row is marked as Done someone could check that and
> > > provide
> > > > > any
> > > > > > comments in the peer review column.
> > > > > >
> > > > > > Gj
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> > > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > > >
> > > > > > > Actually, that means I shouldn't mark those modules as "Done"
> but
> > > as
> > > > > "To
> > > > > > > do".
> > > > > > >
> > > > > > > Gj
> > > > > > >
> > > > > > > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > > > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > > > >
> > > > > > >> My preference is for trying to handle those common things via
> > the
> > > > > tool,
> > > > > > >> i.e., rather than manually fixing apichanges.xml by hand, the
> > > point
> > > > to
> > > > > > me
> > > > > > >> is to identify that that needs to be fixed, or XML files in
> > > general,
> > > > > and
> > > > > > >> add them to the generally problematic list at the top of the
> > page.
> > > > > > >>
> > > > > > >> Gj
> > > > > > >>
> > > > > > >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl <
> > dscho...@bkwi.nl>
> > > > > > wrote:
> > > > > > >>
> > > > > > >>> Hi all,
> > > > > > >>>
> > > > > > >>> When you check a module for license headers and suspicious
> > files
> > > > > (files
> > > > > > >>> that maybe were not owned by Oracle), make changes and do a
> > Pull
> > > > > > Request
> > > > > > >>> (PR), the PR is checked by one or more committers. On the
> other
> > > > hand,
> > > > > > when
> > > > > > >>> the person checking a module thinks no modifications are
> > needed,
> > > no
> > > > > PR
> > > > > > is
> > > > > > >>> made and no code review is done (obviously). However, review
> of
> > > the
> > > > > > module
> > > > > > >>> check does not seem to take place either. What do we think of
> > > that?
> > > > > > >>>
> > > > > > >>> E.g., Geertjan is wotking his ass off, checking one module
> > after
> > > > > > >>> another, but making very little PR's compared to the number
> of
> > > > > modules
> > > > > > he
> > > > > > >>> processes. When I review a couple of these modules, I think
> > there
> > > > > > might be
> > > > > > >>> some oversights. E.g.
> > > > > > >>>
> > > > > > >>> api.intent has a Bundle.properties with an Oracle license
> > header
> > > > > > >>>
> > > > > > >>> api

Re: How to deal with module review without modifications

[Emilian Bold]

Well, most Bundle.properties have been automatically updated but if some
remained I guess the header was slightly off?


--emi

On Wed, Sep 27, 2017 at 11:30 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> To me, a "Bundle.properties" is also something that should be solved
> centrally, since that's a general problem, rather than being a unique or
> special file type in the module. That's something that should be added to
> the central problems list, in my understanding of it.
>
> Gj
>
> On Wed, Sep 27, 2017 at 10:26 AM, Emilian Bold 
> wrote:
>
> > That's the way I see it.
> >
> > Note that Dave mentioned some oversights. For example, Bundle.properties
> > with an Oracle license header.
> >
> > Such a thing should be easily double-checked with some 'grep -R Oracle '
> at
> > some point.
> >
> >
> > --emi
> >
> > On Wed, Sep 27, 2017 at 11:11 AM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> >
> > > OK, so, if everything is done except for the central things, then it's
> > > done. I'll revert my "To dos" back to "Dones" and add a note re this to
> > the
> > > status section at the top of the page.
> > >
> > > Gj
> > >
> > > On Wed, Sep 27, 2017 at 10:08 AM, Emilian Bold  >
> > > wrote:
> > >
> > > > I believe modules that still have .form files or other "Problems to
> be
> > > > solved centrally" should be marked as "Done".
> > > >
> > > > The whole point is to look at everything else. Those problems will be
> > > > solved... centrally.
> > > >
> > > >
> > > > --emi
> > > >
> > > > On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> > > > geertjan.wiele...@googlemail.com> wrote:
> > > >
> > > > > OK, I have marked all mine as "To do", since I am relying on the
> > > central
> > > > > problems being handled via the tool, i.e., I think all "form"
> files,
> > > for
> > > > > example, should be processed via the tool, rather than doing them
> > > > > individually and manually per module.
> > > > >
> > > > > I think a peer review would be good, and yes, it is very important
> to
> > > get
> > > > > the license headers right. A peer review column would be great, I
> > > think,
> > > > > i.e., when a row is marked as Done someone could check that and
> > provide
> > > > any
> > > > > comments in the peer review column.
> > > > >
> > > > > Gj
> > > > >
> > > > > On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > >
> > > > > > Actually, that means I shouldn't mark those modules as "Done" but
> > as
> > > > "To
> > > > > > do".
> > > > > >
> > > > > > Gj
> > > > > >
> > > > > > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > > >
> > > > > >> My preference is for trying to handle those common things via
> the
> > > > tool,
> > > > > >> i.e., rather than manually fixing apichanges.xml by hand, the
> > point
> > > to
> > > > > me
> > > > > >> is to identify that that needs to be fixed, or XML files in
> > general,
> > > > and
> > > > > >> add them to the generally problematic list at the top of the
> page.
> > > > > >>
> > > > > >> Gj
> > > > > >>
> > > > > >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl <
> dscho...@bkwi.nl>
> > > > > wrote:
> > > > > >>
> > > > > >>> Hi all,
> > > > > >>>
> > > > > >>> When you check a module for license headers and suspicious
> files
> > > > (files
> > > > > >>> that maybe were not owned by Oracle), make changes and do a
> Pull
> > > > > Request
> > > > > >>> (PR), the PR is checked by one or more committers. On the other
> > > hand,
> > > > > when
> > > > > >>> the person checking a module thinks no modifications are
> needed,
> > no
> > > > PR
> > > > > is
> > > > > >>> made and no code review is done (obviously). However, review of
> > the
> > > > > module
> > > > > >>> check does not seem to take place either. What do we think of
> > that?
> > > > > >>>
> > > > > >>> E.g., Geertjan is wotking his ass off, checking one module
> after
> > > > > >>> another, but making very little PR's compared to the number of
> > > > modules
> > > > > he
> > > > > >>> processes. When I review a couple of these modules, I think
> there
> > > > > might be
> > > > > >>> some oversights. E.g.
> > > > > >>>
> > > > > >>> api.intent has a Bundle.properties with an Oracle license
> header
> > > > > >>>
> > > > > >>> api.progress has a apichanges.xml with an Oracle license header
> > > > > >>>
> > > > > >>> api.progress.nb has aapichanges.xml with an Oracle license
> header
> > > > > >>>
> > > > > >>> I would expect those Oracle license headers to be removed or
> > > replaced
> > > > > >>> with Apache license headers.
> > > > > >>>
> > > > > >>>
> > > > > >>> How important is it to get the license headers right? Do we
> need
> > a
> > > > peer
> > > > > >>> review on modules that seem okay? A second name in the name
> > column
> > > on
> > > > > the
> > > > > >>> wiki page, confirming that no changes are needed?
> > > > > >>>
> > 

Re: How to deal with module review without modifications

[Geertjan Wielenga]

To me, a "Bundle.properties" is also something that should be solved
centrally, since that's a general problem, rather than being a unique or
special file type in the module. That's something that should be added to
the central problems list, in my understanding of it.

Gj

On Wed, Sep 27, 2017 at 10:26 AM, Emilian Bold 
wrote:

> That's the way I see it.
>
> Note that Dave mentioned some oversights. For example, Bundle.properties
> with an Oracle license header.
>
> Such a thing should be easily double-checked with some 'grep -R Oracle ' at
> some point.
>
>
> --emi
>
> On Wed, Sep 27, 2017 at 11:11 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > OK, so, if everything is done except for the central things, then it's
> > done. I'll revert my "To dos" back to "Dones" and add a note re this to
> the
> > status section at the top of the page.
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 10:08 AM, Emilian Bold 
> > wrote:
> >
> > > I believe modules that still have .form files or other "Problems to be
> > > solved centrally" should be marked as "Done".
> > >
> > > The whole point is to look at everything else. Those problems will be
> > > solved... centrally.
> > >
> > >
> > > --emi
> > >
> > > On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> > > geertjan.wiele...@googlemail.com> wrote:
> > >
> > > > OK, I have marked all mine as "To do", since I am relying on the
> > central
> > > > problems being handled via the tool, i.e., I think all "form" files,
> > for
> > > > example, should be processed via the tool, rather than doing them
> > > > individually and manually per module.
> > > >
> > > > I think a peer review would be good, and yes, it is very important to
> > get
> > > > the license headers right. A peer review column would be great, I
> > think,
> > > > i.e., when a row is marked as Done someone could check that and
> provide
> > > any
> > > > comments in the peer review column.
> > > >
> > > > Gj
> > > >
> > > > On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> > > > geertjan.wiele...@googlemail.com> wrote:
> > > >
> > > > > Actually, that means I shouldn't mark those modules as "Done" but
> as
> > > "To
> > > > > do".
> > > > >
> > > > > Gj
> > > > >
> > > > > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > > > > geertjan.wiele...@googlemail.com> wrote:
> > > > >
> > > > >> My preference is for trying to handle those common things via the
> > > tool,
> > > > >> i.e., rather than manually fixing apichanges.xml by hand, the
> point
> > to
> > > > me
> > > > >> is to identify that that needs to be fixed, or XML files in
> general,
> > > and
> > > > >> add them to the generally problematic list at the top of the page.
> > > > >>
> > > > >> Gj
> > > > >>
> > > > >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl 
> > > > wrote:
> > > > >>
> > > > >>> Hi all,
> > > > >>>
> > > > >>> When you check a module for license headers and suspicious files
> > > (files
> > > > >>> that maybe were not owned by Oracle), make changes and do a Pull
> > > > Request
> > > > >>> (PR), the PR is checked by one or more committers. On the other
> > hand,
> > > > when
> > > > >>> the person checking a module thinks no modifications are needed,
> no
> > > PR
> > > > is
> > > > >>> made and no code review is done (obviously). However, review of
> the
> > > > module
> > > > >>> check does not seem to take place either. What do we think of
> that?
> > > > >>>
> > > > >>> E.g., Geertjan is wotking his ass off, checking one module after
> > > > >>> another, but making very little PR's compared to the number of
> > > modules
> > > > he
> > > > >>> processes. When I review a couple of these modules, I think there
> > > > might be
> > > > >>> some oversights. E.g.
> > > > >>>
> > > > >>> api.intent has a Bundle.properties with an Oracle license header
> > > > >>>
> > > > >>> api.progress has a apichanges.xml with an Oracle license header
> > > > >>>
> > > > >>> api.progress.nb has aapichanges.xml with an Oracle license header
> > > > >>>
> > > > >>> I would expect those Oracle license headers to be removed or
> > replaced
> > > > >>> with Apache license headers.
> > > > >>>
> > > > >>>
> > > > >>> How important is it to get the license headers right? Do we need
> a
> > > peer
> > > > >>> review on modules that seem okay? A second name in the name
> column
> > on
> > > > the
> > > > >>> wiki page, confirming that no changes are needed?
> > > > >>>
> > > > >>> Please advise.
> > > > >>>
> > > > >>>
> > > > >>> /Dave
> > > > >>>
> > > > >>>
> > > > >>> @Geertjan: sorry to have used you as an example.
> > > > >>>
> > > > >>
> > > > >>
> > > > >
> > > >
> > >
> >
>

Re: How to deal with module review without modifications

[Emilian Bold]

That's the way I see it.

Note that Dave mentioned some oversights. For example, Bundle.properties
with an Oracle license header.

Such a thing should be easily double-checked with some 'grep -R Oracle ' at
some point.


--emi

On Wed, Sep 27, 2017 at 11:11 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> OK, so, if everything is done except for the central things, then it's
> done. I'll revert my "To dos" back to "Dones" and add a note re this to the
> status section at the top of the page.
>
> Gj
>
> On Wed, Sep 27, 2017 at 10:08 AM, Emilian Bold 
> wrote:
>
> > I believe modules that still have .form files or other "Problems to be
> > solved centrally" should be marked as "Done".
> >
> > The whole point is to look at everything else. Those problems will be
> > solved... centrally.
> >
> >
> > --emi
> >
> > On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> >
> > > OK, I have marked all mine as "To do", since I am relying on the
> central
> > > problems being handled via the tool, i.e., I think all "form" files,
> for
> > > example, should be processed via the tool, rather than doing them
> > > individually and manually per module.
> > >
> > > I think a peer review would be good, and yes, it is very important to
> get
> > > the license headers right. A peer review column would be great, I
> think,
> > > i.e., when a row is marked as Done someone could check that and provide
> > any
> > > comments in the peer review column.
> > >
> > > Gj
> > >
> > > On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> > > geertjan.wiele...@googlemail.com> wrote:
> > >
> > > > Actually, that means I shouldn't mark those modules as "Done" but as
> > "To
> > > > do".
> > > >
> > > > Gj
> > > >
> > > > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > > > geertjan.wiele...@googlemail.com> wrote:
> > > >
> > > >> My preference is for trying to handle those common things via the
> > tool,
> > > >> i.e., rather than manually fixing apichanges.xml by hand, the point
> to
> > > me
> > > >> is to identify that that needs to be fixed, or XML files in general,
> > and
> > > >> add them to the generally problematic list at the top of the page.
> > > >>
> > > >> Gj
> > > >>
> > > >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl 
> > > wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> When you check a module for license headers and suspicious files
> > (files
> > > >>> that maybe were not owned by Oracle), make changes and do a Pull
> > > Request
> > > >>> (PR), the PR is checked by one or more committers. On the other
> hand,
> > > when
> > > >>> the person checking a module thinks no modifications are needed, no
> > PR
> > > is
> > > >>> made and no code review is done (obviously). However, review of the
> > > module
> > > >>> check does not seem to take place either. What do we think of that?
> > > >>>
> > > >>> E.g., Geertjan is wotking his ass off, checking one module after
> > > >>> another, but making very little PR's compared to the number of
> > modules
> > > he
> > > >>> processes. When I review a couple of these modules, I think there
> > > might be
> > > >>> some oversights. E.g.
> > > >>>
> > > >>> api.intent has a Bundle.properties with an Oracle license header
> > > >>>
> > > >>> api.progress has a apichanges.xml with an Oracle license header
> > > >>>
> > > >>> api.progress.nb has aapichanges.xml with an Oracle license header
> > > >>>
> > > >>> I would expect those Oracle license headers to be removed or
> replaced
> > > >>> with Apache license headers.
> > > >>>
> > > >>>
> > > >>> How important is it to get the license headers right? Do we need a
> > peer
> > > >>> review on modules that seem okay? A second name in the name column
> on
> > > the
> > > >>> wiki page, confirming that no changes are needed?
> > > >>>
> > > >>> Please advise.
> > > >>>
> > > >>>
> > > >>> /Dave
> > > >>>
> > > >>>
> > > >>> @Geertjan: sorry to have used you as an example.
> > > >>>
> > > >>
> > > >>
> > > >
> > >
> >
>

How do we want to do merges?

[Geertjan Wielenga]

Hi all,

Bear in mind that Apache GitHub is a readonly mirror of Apache Git.

So, the question is, how do we want to do merges of PRs and also what
should the workflow be. These are decisions we can make as a community.

For example, this PR by Eric Barboni, seems a logical one to want to merge,
i.e., its an addition to our Rat setup that we logically would want to
have, i.e., there's no reason not to have it and everyone in the PR agrees
with it:

https://github.com/apache/incubator-netbeans/pull/12

If the person providing a PR is a committer, after there is agreement on
the PR, the committer could then push that PR to the Apache Git repo
themselves, for example.

Thoughts welcome.

Gj

Re: How to deal with module review without modifications

[Geertjan Wielenga]

OK, so, if everything is done except for the central things, then it's
done. I'll revert my "To dos" back to "Dones" and add a note re this to the
status section at the top of the page.

Gj

On Wed, Sep 27, 2017 at 10:08 AM, Emilian Bold 
wrote:

> I believe modules that still have .form files or other "Problems to be
> solved centrally" should be marked as "Done".
>
> The whole point is to look at everything else. Those problems will be
> solved... centrally.
>
>
> --emi
>
> On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > OK, I have marked all mine as "To do", since I am relying on the central
> > problems being handled via the tool, i.e., I think all "form" files, for
> > example, should be processed via the tool, rather than doing them
> > individually and manually per module.
> >
> > I think a peer review would be good, and yes, it is very important to get
> > the license headers right. A peer review column would be great, I think,
> > i.e., when a row is marked as Done someone could check that and provide
> any
> > comments in the peer review column.
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> >
> > > Actually, that means I shouldn't mark those modules as "Done" but as
> "To
> > > do".
> > >
> > > Gj
> > >
> > > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > > geertjan.wiele...@googlemail.com> wrote:
> > >
> > >> My preference is for trying to handle those common things via the
> tool,
> > >> i.e., rather than manually fixing apichanges.xml by hand, the point to
> > me
> > >> is to identify that that needs to be fixed, or XML files in general,
> and
> > >> add them to the generally problematic list at the top of the page.
> > >>
> > >> Gj
> > >>
> > >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl 
> > wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> When you check a module for license headers and suspicious files
> (files
> > >>> that maybe were not owned by Oracle), make changes and do a Pull
> > Request
> > >>> (PR), the PR is checked by one or more committers. On the other hand,
> > when
> > >>> the person checking a module thinks no modifications are needed, no
> PR
> > is
> > >>> made and no code review is done (obviously). However, review of the
> > module
> > >>> check does not seem to take place either. What do we think of that?
> > >>>
> > >>> E.g., Geertjan is wotking his ass off, checking one module after
> > >>> another, but making very little PR's compared to the number of
> modules
> > he
> > >>> processes. When I review a couple of these modules, I think there
> > might be
> > >>> some oversights. E.g.
> > >>>
> > >>> api.intent has a Bundle.properties with an Oracle license header
> > >>>
> > >>> api.progress has a apichanges.xml with an Oracle license header
> > >>>
> > >>> api.progress.nb has aapichanges.xml with an Oracle license header
> > >>>
> > >>> I would expect those Oracle license headers to be removed or replaced
> > >>> with Apache license headers.
> > >>>
> > >>>
> > >>> How important is it to get the license headers right? Do we need a
> peer
> > >>> review on modules that seem okay? A second name in the name column on
> > the
> > >>> wiki page, confirming that no changes are needed?
> > >>>
> > >>> Please advise.
> > >>>
> > >>>
> > >>> /Dave
> > >>>
> > >>>
> > >>> @Geertjan: sorry to have used you as an example.
> > >>>
> > >>
> > >>
> > >
> >
>

Re: How to deal with module review without modifications

[Emilian Bold]

I mean, the whole phrase mentions this:

> -checked Rat report: everything has been relicensed to Apache, included
in 'central problems' list above, or excluded via Rat



--emi

On Wed, Sep 27, 2017 at 11:08 AM, Emilian Bold 
wrote:

> I believe modules that still have .form files or other "Problems to be
> solved centrally" should be marked as "Done".
>
> The whole point is to look at everything else. Those problems will be
> solved... centrally.
>
>
> --emi
>
> On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
>> OK, I have marked all mine as "To do", since I am relying on the central
>> problems being handled via the tool, i.e., I think all "form" files, for
>> example, should be processed via the tool, rather than doing them
>> individually and manually per module.
>>
>> I think a peer review would be good, and yes, it is very important to get
>> the license headers right. A peer review column would be great, I think,
>> i.e., when a row is marked as Done someone could check that and provide
>> any
>> comments in the peer review column.
>>
>> Gj
>>
>> On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
>> geertjan.wiele...@googlemail.com> wrote:
>>
>> > Actually, that means I shouldn't mark those modules as "Done" but as "To
>> > do".
>> >
>> > Gj
>> >
>> > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
>> > geertjan.wiele...@googlemail.com> wrote:
>> >
>> >> My preference is for trying to handle those common things via the tool,
>> >> i.e., rather than manually fixing apichanges.xml by hand, the point to
>> me
>> >> is to identify that that needs to be fixed, or XML files in general,
>> and
>> >> add them to the generally problematic list at the top of the page.
>> >>
>> >> Gj
>> >>
>> >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl 
>> wrote:
>> >>
>> >>> Hi all,
>> >>>
>> >>> When you check a module for license headers and suspicious files
>> (files
>> >>> that maybe were not owned by Oracle), make changes and do a Pull
>> Request
>> >>> (PR), the PR is checked by one or more committers. On the other hand,
>> when
>> >>> the person checking a module thinks no modifications are needed, no
>> PR is
>> >>> made and no code review is done (obviously). However, review of the
>> module
>> >>> check does not seem to take place either. What do we think of that?
>> >>>
>> >>> E.g., Geertjan is wotking his ass off, checking one module after
>> >>> another, but making very little PR's compared to the number of
>> modules he
>> >>> processes. When I review a couple of these modules, I think there
>> might be
>> >>> some oversights. E.g.
>> >>>
>> >>> api.intent has a Bundle.properties with an Oracle license header
>> >>>
>> >>> api.progress has a apichanges.xml with an Oracle license header
>> >>>
>> >>> api.progress.nb has aapichanges.xml with an Oracle license header
>> >>>
>> >>> I would expect those Oracle license headers to be removed or replaced
>> >>> with Apache license headers.
>> >>>
>> >>>
>> >>> How important is it to get the license headers right? Do we need a
>> peer
>> >>> review on modules that seem okay? A second name in the name column on
>> the
>> >>> wiki page, confirming that no changes are needed?
>> >>>
>> >>> Please advise.
>> >>>
>> >>>
>> >>> /Dave
>> >>>
>> >>>
>> >>> @Geertjan: sorry to have used you as an example.
>> >>>
>> >>
>> >>
>> >
>>
>
>

Re: How to deal with module review without modifications

[Emilian Bold]

I believe modules that still have .form files or other "Problems to be
solved centrally" should be marked as "Done".

The whole point is to look at everything else. Those problems will be
solved... centrally.


--emi

On Wed, Sep 27, 2017 at 11:02 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> OK, I have marked all mine as "To do", since I am relying on the central
> problems being handled via the tool, i.e., I think all "form" files, for
> example, should be processed via the tool, rather than doing them
> individually and manually per module.
>
> I think a peer review would be good, and yes, it is very important to get
> the license headers right. A peer review column would be great, I think,
> i.e., when a row is marked as Done someone could check that and provide any
> comments in the peer review column.
>
> Gj
>
> On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > Actually, that means I shouldn't mark those modules as "Done" but as "To
> > do".
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> > geertjan.wiele...@googlemail.com> wrote:
> >
> >> My preference is for trying to handle those common things via the tool,
> >> i.e., rather than manually fixing apichanges.xml by hand, the point to
> me
> >> is to identify that that needs to be fixed, or XML files in general, and
> >> add them to the generally problematic list at the top of the page.
> >>
> >> Gj
> >>
> >> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl 
> wrote:
> >>
> >>> Hi all,
> >>>
> >>> When you check a module for license headers and suspicious files (files
> >>> that maybe were not owned by Oracle), make changes and do a Pull
> Request
> >>> (PR), the PR is checked by one or more committers. On the other hand,
> when
> >>> the person checking a module thinks no modifications are needed, no PR
> is
> >>> made and no code review is done (obviously). However, review of the
> module
> >>> check does not seem to take place either. What do we think of that?
> >>>
> >>> E.g., Geertjan is wotking his ass off, checking one module after
> >>> another, but making very little PR's compared to the number of modules
> he
> >>> processes. When I review a couple of these modules, I think there
> might be
> >>> some oversights. E.g.
> >>>
> >>> api.intent has a Bundle.properties with an Oracle license header
> >>>
> >>> api.progress has a apichanges.xml with an Oracle license header
> >>>
> >>> api.progress.nb has aapichanges.xml with an Oracle license header
> >>>
> >>> I would expect those Oracle license headers to be removed or replaced
> >>> with Apache license headers.
> >>>
> >>>
> >>> How important is it to get the license headers right? Do we need a peer
> >>> review on modules that seem okay? A second name in the name column on
> the
> >>> wiki page, confirming that no changes are needed?
> >>>
> >>> Please advise.
> >>>
> >>>
> >>> /Dave
> >>>
> >>>
> >>> @Geertjan: sorry to have used you as an example.
> >>>
> >>
> >>
> >
>

Re: How to deal with module review without modifications

[Geertjan Wielenga]

OK, I have marked all mine as "To do", since I am relying on the central
problems being handled via the tool, i.e., I think all "form" files, for
example, should be processed via the tool, rather than doing them
individually and manually per module.

I think a peer review would be good, and yes, it is very important to get
the license headers right. A peer review column would be great, I think,
i.e., when a row is marked as Done someone could check that and provide any
comments in the peer review column.

Gj

On Wed, Sep 27, 2017 at 12:32 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Actually, that means I shouldn't mark those modules as "Done" but as "To
> do".
>
> Gj
>
> On Wed, Sep 27, 2017 at 12:27 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
>> My preference is for trying to handle those common things via the tool,
>> i.e., rather than manually fixing apichanges.xml by hand, the point to me
>> is to identify that that needs to be fixed, or XML files in general, and
>> add them to the generally problematic list at the top of the page.
>>
>> Gj
>>
>> On Wed, Sep 27, 2017 at 12:20 AM, Dave Schoorl  wrote:
>>
>>> Hi all,
>>>
>>> When you check a module for license headers and suspicious files (files
>>> that maybe were not owned by Oracle), make changes and do a Pull Request
>>> (PR), the PR is checked by one or more committers. On the other hand, when
>>> the person checking a module thinks no modifications are needed, no PR is
>>> made and no code review is done (obviously). However, review of the module
>>> check does not seem to take place either. What do we think of that?
>>>
>>> E.g., Geertjan is wotking his ass off, checking one module after
>>> another, but making very little PR's compared to the number of modules he
>>> processes. When I review a couple of these modules, I think there might be
>>> some oversights. E.g.
>>>
>>> api.intent has a Bundle.properties with an Oracle license header
>>>
>>> api.progress has a apichanges.xml with an Oracle license header
>>>
>>> api.progress.nb has aapichanges.xml with an Oracle license header
>>>
>>> I would expect those Oracle license headers to be removed or replaced
>>> with Apache license headers.
>>>
>>>
>>> How important is it to get the license headers right? Do we need a peer
>>> review on modules that seem okay? A second name in the name column on the
>>> wiki page, confirming that no changes are needed?
>>>
>>> Please advise.
>>>
>>>
>>> /Dave
>>>
>>>
>>> @Geertjan: sorry to have used you as an example.
>>>
>>
>>
>

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

Yup, that's all true. However, the point is, there's many new features that
have not been released yet that are in the Apache NetBeans code base.

Again, I have no fixed opinion myself, and I agree it would be great to
have lots of new features and lots of bug fixes.

The only point I have, if any at all, is that we will never release those
bugs or features until we work through the Modules Review. And the
knowledge required to do that review is really minimal, it is not a code
review, just a license review. Without completing that, Apache NetBeans
will never be released and is, in fact, dead.

Gj


On Wed, Sep 27, 2017 at 9:39 AM, Christian Lenz 
wrote:

> The page will not show the list of any bug fixes. Only Features and I
> think or hope that this list is not completed yet, because it is only a
> countable amount of Features. When we have a look into older Major
> Releases, there was a lot of more AND the other, 2nd Code donation here is
> missing, so PHP too (I think) All, what is not Java will not coming in the
> first NB 9 release. Afaik. So no C/C++ Features and no PHP Support.
>
> Gesendet von Mail für Windows 10
>
> Von: Geertjan Wielenga
> Gesendet: Mittwoch, 27. September 2017 09:35
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Allow code contributions or focus on release only?
>
> Sure, this is why I opened this discussion thread, to see how people feel
> about this. I.e., this is precisely the discussion, do people think we
> should focus narrowly on getting the Apache NetBeans release done or should
> we focus on bug fixes and features too. All options are open.
>
> Gj
>
> On Wed, Sep 27, 2017 at 9:33 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
> > There's heaps of improvements: https://cwiki.
> > apache.org/confluence/display/NETBEANS/NetBeans+9.0+-+New+and+Noteworthy
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
> > wrote:
> >
> >> We should also allow some new features and improvements. We cannot have
> >> NetBeans under Apache for 1 year and basically have no
> Apache-contributed
> >> feature to show for, only IP cleanup and stuff like that.
> >>
> >> There's a whole lot of contributors and committers: does everybody want
> to
> >> do only this? Because I don't!
> >>
> >> BTW, how many are being involved in the new Apache build system or IP
> >> clearance, etc.? I don't see people jumping in on this rather boring
> job.
> >>
> >> So, I *am* doing IP cleanup, but I would most certainly want to commit
> new
> >> features and bugfixes! I found and fixed a few bugs just these weeks
> while
> >> working on yameter.com
> >>
> >> I don't remember agreeing on a feature freeze within Apache, we just got
> >> the codebase donated.
> >>
> >> The community should be able to walk and chew bubble gum at the same
> time.
> >> If some people are focusing on the build system I don't see why other
> >> people can't focus on something else as long as they don't break
> something
> >> or get in the way?
> >>
> >> The real question is: are we really distributing the load *and trust*
> >> among
> >> committers or not? Because it seems to me everybody is very willing to
> >> heavily restrict what we should be allowed to do.
> >>
> >>
> >>
> >> --emi
> >>
> >> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
> >> mblaes...@doppel-helix.eu
> >> > wrote:
> >>
> >> > Hey,
> >> >
> >> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
> >> > > [Discuss-Request: Focus on getting a release out or adding
> functions]
> >> >
> >> > if I'm not mistaken, the netbeans 9 feature freeze had already
> happened
> >> >  when the migration to apache began. I would focus on bugfixing and
> >> > blocking new features.
> >> >
> >> > With the apache migration process there is enough development needed,
> >> > just to get the codebase releaseable. Libraries need to
> >> > removed/replaced, if the are incompatibe with the apache project
> >> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
> >> > installers to get these libraries at runtime need to be implemented.
> >> >
> >> > While I agree, that adding new features would pull more potential
> >> > contributers, I would consider a stable base more important, to get
> >> > going from there. Java 9 is out and the excitement is already there
> and
> >> > people ask for netbeans 9, so I would prioritize that.
> >> >
> >> > My 2 cent
> >> >
> >> > Matthias
> >> >
> >> >
> >> >
> >>
> >
> >
>
>

AW: Allow code contributions or focus on release only?

[Christian Lenz]

The page will not show the list of any bug fixes. Only Features and I think or 
hope that this list is not completed yet, because it is only a countable amount 
of Features. When we have a look into older Major Releases, there was a lot of 
more AND the other, 2nd Code donation here is missing, so PHP too (I think) 
All, what is not Java will not coming in the first NB 9 release. Afaik. So no 
C/C++ Features and no PHP Support.

Gesendet von Mail für Windows 10

Von: Geertjan Wielenga
Gesendet: Mittwoch, 27. September 2017 09:35
An: dev@netbeans.incubator.apache.org
Betreff: Re: Allow code contributions or focus on release only?

Sure, this is why I opened this discussion thread, to see how people feel
about this. I.e., this is precisely the discussion, do people think we
should focus narrowly on getting the Apache NetBeans release done or should
we focus on bug fixes and features too. All options are open.

Gj

On Wed, Sep 27, 2017 at 9:33 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> There's heaps of improvements: https://cwiki.
> apache.org/confluence/display/NETBEANS/NetBeans+9.0+-+New+and+Noteworthy
>
> Gj
>
> On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
> wrote:
>
>> We should also allow some new features and improvements. We cannot have
>> NetBeans under Apache for 1 year and basically have no Apache-contributed
>> feature to show for, only IP cleanup and stuff like that.
>>
>> There's a whole lot of contributors and committers: does everybody want to
>> do only this? Because I don't!
>>
>> BTW, how many are being involved in the new Apache build system or IP
>> clearance, etc.? I don't see people jumping in on this rather boring job.
>>
>> So, I *am* doing IP cleanup, but I would most certainly want to commit new
>> features and bugfixes! I found and fixed a few bugs just these weeks while
>> working on yameter.com
>>
>> I don't remember agreeing on a feature freeze within Apache, we just got
>> the codebase donated.
>>
>> The community should be able to walk and chew bubble gum at the same time.
>> If some people are focusing on the build system I don't see why other
>> people can't focus on something else as long as they don't break something
>> or get in the way?
>>
>> The real question is: are we really distributing the load *and trust*
>> among
>> committers or not? Because it seems to me everybody is very willing to
>> heavily restrict what we should be allowed to do.
>>
>>
>>
>> --emi
>>
>> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
>> mblaes...@doppel-helix.eu
>> > wrote:
>>
>> > Hey,
>> >
>> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
>> > > [Discuss-Request: Focus on getting a release out or adding functions]
>> >
>> > if I'm not mistaken, the netbeans 9 feature freeze had already happened
>> >  when the migration to apache began. I would focus on bugfixing and
>> > blocking new features.
>> >
>> > With the apache migration process there is enough development needed,
>> > just to get the codebase releaseable. Libraries need to
>> > removed/replaced, if the are incompatibe with the apache project
>> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
>> > installers to get these libraries at runtime need to be implemented.
>> >
>> > While I agree, that adding new features would pull more potential
>> > contributers, I would consider a stable base more important, to get
>> > going from there. Java 9 is out and the excitement is already there and
>> > people ask for netbeans 9, so I would prioritize that.
>> >
>> > My 2 cent
>> >
>> > Matthias
>> >
>> >
>> >
>>
>
>

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

Also, do take note of the advice earlier in this thread from Craig Russell:

I have no dog in this particular hunt, but if it were up to me I'd
> prioritize:
>
> getting code into repositories with clean RAT reports
> getting Netbeans to build and run
> creating release(s) for major platforms
> ...
> serious bug reports
> ...
> features (in branches)
>

However, sure, we can take a different path.

Gj

On Wed, Sep 27, 2017 at 9:35 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> Sure, this is why I opened this discussion thread, to see how people feel
> about this. I.e., this is precisely the discussion, do people think we
> should focus narrowly on getting the Apache NetBeans release done or should
> we focus on bug fixes and features too. All options are open.
>
> Gj
>
> On Wed, Sep 27, 2017 at 9:33 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
>
>> There's heaps of improvements: https://cwiki.ap
>> ache.org/confluence/display/NETBEANS/NetBeans+9.0+-+New+and+Noteworthy
>>
>> Gj
>>
>> On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
>> wrote:
>>
>>> We should also allow some new features and improvements. We cannot have
>>> NetBeans under Apache for 1 year and basically have no Apache-contributed
>>> feature to show for, only IP cleanup and stuff like that.
>>>
>>> There's a whole lot of contributors and committers: does everybody want
>>> to
>>> do only this? Because I don't!
>>>
>>> BTW, how many are being involved in the new Apache build system or IP
>>> clearance, etc.? I don't see people jumping in on this rather boring job.
>>>
>>> So, I *am* doing IP cleanup, but I would most certainly want to commit
>>> new
>>> features and bugfixes! I found and fixed a few bugs just these weeks
>>> while
>>> working on yameter.com
>>>
>>> I don't remember agreeing on a feature freeze within Apache, we just got
>>> the codebase donated.
>>>
>>> The community should be able to walk and chew bubble gum at the same
>>> time.
>>> If some people are focusing on the build system I don't see why other
>>> people can't focus on something else as long as they don't break
>>> something
>>> or get in the way?
>>>
>>> The real question is: are we really distributing the load *and trust*
>>> among
>>> committers or not? Because it seems to me everybody is very willing to
>>> heavily restrict what we should be allowed to do.
>>>
>>>
>>>
>>> --emi
>>>
>>> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
>>> mblaes...@doppel-helix.eu
>>> > wrote:
>>>
>>> > Hey,
>>> >
>>> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
>>> > > [Discuss-Request: Focus on getting a release out or adding functions]
>>> >
>>> > if I'm not mistaken, the netbeans 9 feature freeze had already happened
>>> >  when the migration to apache began. I would focus on bugfixing and
>>> > blocking new features.
>>> >
>>> > With the apache migration process there is enough development needed,
>>> > just to get the codebase releaseable. Libraries need to
>>> > removed/replaced, if the are incompatibe with the apache project
>>> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
>>> > installers to get these libraries at runtime need to be implemented.
>>> >
>>> > While I agree, that adding new features would pull more potential
>>> > contributers, I would consider a stable base more important, to get
>>> > going from there. Java 9 is out and the excitement is already there and
>>> > people ask for netbeans 9, so I would prioritize that.
>>> >
>>> > My 2 cent
>>> >
>>> > Matthias
>>> >
>>> >
>>> >
>>>
>>
>>
>

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

Sure, this is why I opened this discussion thread, to see how people feel
about this. I.e., this is precisely the discussion, do people think we
should focus narrowly on getting the Apache NetBeans release done or should
we focus on bug fixes and features too. All options are open.

Gj

On Wed, Sep 27, 2017 at 9:33 AM, Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:

> There's heaps of improvements: https://cwiki.
> apache.org/confluence/display/NETBEANS/NetBeans+9.0+-+New+and+Noteworthy
>
> Gj
>
> On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
> wrote:
>
>> We should also allow some new features and improvements. We cannot have
>> NetBeans under Apache for 1 year and basically have no Apache-contributed
>> feature to show for, only IP cleanup and stuff like that.
>>
>> There's a whole lot of contributors and committers: does everybody want to
>> do only this? Because I don't!
>>
>> BTW, how many are being involved in the new Apache build system or IP
>> clearance, etc.? I don't see people jumping in on this rather boring job.
>>
>> So, I *am* doing IP cleanup, but I would most certainly want to commit new
>> features and bugfixes! I found and fixed a few bugs just these weeks while
>> working on yameter.com
>>
>> I don't remember agreeing on a feature freeze within Apache, we just got
>> the codebase donated.
>>
>> The community should be able to walk and chew bubble gum at the same time.
>> If some people are focusing on the build system I don't see why other
>> people can't focus on something else as long as they don't break something
>> or get in the way?
>>
>> The real question is: are we really distributing the load *and trust*
>> among
>> committers or not? Because it seems to me everybody is very willing to
>> heavily restrict what we should be allowed to do.
>>
>>
>>
>> --emi
>>
>> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
>> mblaes...@doppel-helix.eu
>> > wrote:
>>
>> > Hey,
>> >
>> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
>> > > [Discuss-Request: Focus on getting a release out or adding functions]
>> >
>> > if I'm not mistaken, the netbeans 9 feature freeze had already happened
>> >  when the migration to apache began. I would focus on bugfixing and
>> > blocking new features.
>> >
>> > With the apache migration process there is enough development needed,
>> > just to get the codebase releaseable. Libraries need to
>> > removed/replaced, if the are incompatibe with the apache project
>> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
>> > installers to get these libraries at runtime need to be implemented.
>> >
>> > While I agree, that adding new features would pull more potential
>> > contributers, I would consider a stable base more important, to get
>> > going from there. Java 9 is out and the excitement is already there and
>> > people ask for netbeans 9, so I would prioritize that.
>> >
>> > My 2 cent
>> >
>> > Matthias
>> >
>> >
>> >
>>
>
>

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

There's heaps of improvements:
https://cwiki.apache.org/confluence/display/NETBEANS/NetBeans+9.0+-+New+and+Noteworthy

Gj

On Wed, Sep 27, 2017 at 9:27 AM, Emilian Bold 
wrote:

> We should also allow some new features and improvements. We cannot have
> NetBeans under Apache for 1 year and basically have no Apache-contributed
> feature to show for, only IP cleanup and stuff like that.
>
> There's a whole lot of contributors and committers: does everybody want to
> do only this? Because I don't!
>
> BTW, how many are being involved in the new Apache build system or IP
> clearance, etc.? I don't see people jumping in on this rather boring job.
>
> So, I *am* doing IP cleanup, but I would most certainly want to commit new
> features and bugfixes! I found and fixed a few bugs just these weeks while
> working on yameter.com
>
> I don't remember agreeing on a feature freeze within Apache, we just got
> the codebase donated.
>
> The community should be able to walk and chew bubble gum at the same time.
> If some people are focusing on the build system I don't see why other
> people can't focus on something else as long as they don't break something
> or get in the way?
>
> The real question is: are we really distributing the load *and trust* among
> committers or not? Because it seems to me everybody is very willing to
> heavily restrict what we should be allowed to do.
>
>
>
> --emi
>
> On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing <
> mblaes...@doppel-helix.eu
> > wrote:
>
> > Hey,
> >
> > Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
> > > [Discuss-Request: Focus on getting a release out or adding functions]
> >
> > if I'm not mistaken, the netbeans 9 feature freeze had already happened
> >  when the migration to apache began. I would focus on bugfixing and
> > blocking new features.
> >
> > With the apache migration process there is enough development needed,
> > just to get the codebase releaseable. Libraries need to
> > removed/replaced, if the are incompatibe with the apache project
> > (SwingX is LGPL and so can't be distributed with apache netbeans) or
> > installers to get these libraries at runtime need to be implemented.
> >
> > While I agree, that adding new features would pull more potential
> > contributers, I would consider a stable base more important, to get
> > going from there. Java 9 is out and the excitement is already there and
> > people ask for netbeans 9, so I would prioritize that.
> >
> > My 2 cent
> >
> > Matthias
> >
> >
> >
>

Re: Allow code contributions or focus on release only?

[Emilian Bold]

We should also allow some new features and improvements. We cannot have
NetBeans under Apache for 1 year and basically have no Apache-contributed
feature to show for, only IP cleanup and stuff like that.

There's a whole lot of contributors and committers: does everybody want to
do only this? Because I don't!

BTW, how many are being involved in the new Apache build system or IP
clearance, etc.? I don't see people jumping in on this rather boring job.

So, I *am* doing IP cleanup, but I would most certainly want to commit new
features and bugfixes! I found and fixed a few bugs just these weeks while
working on yameter.com

I don't remember agreeing on a feature freeze within Apache, we just got
the codebase donated.

The community should be able to walk and chew bubble gum at the same time.
If some people are focusing on the build system I don't see why other
people can't focus on something else as long as they don't break something
or get in the way?

The real question is: are we really distributing the load *and trust* among
committers or not? Because it seems to me everybody is very willing to
heavily restrict what we should be allowed to do.



--emi

On Tue, Sep 26, 2017 at 9:14 PM, Matthias Bläsing  wrote:

> Hey,
>
> Am Dienstag, den 26.09.2017, 09:17 +0200 schrieb Geertjan Wielenga:
> > [Discuss-Request: Focus on getting a release out or adding functions]
>
> if I'm not mistaken, the netbeans 9 feature freeze had already happened
>  when the migration to apache began. I would focus on bugfixing and
> blocking new features.
>
> With the apache migration process there is enough development needed,
> just to get the codebase releaseable. Libraries need to
> removed/replaced, if the are incompatibe with the apache project
> (SwingX is LGPL and so can't be distributed with apache netbeans) or
> installers to get these libraries at runtime need to be implemented.
>
> While I agree, that adding new features would pull more potential
> contributers, I would consider a stable base more important, to get
> going from there. Java 9 is out and the excitement is already there and
> people ask for netbeans 9, so I would prioritize that.
>
> My 2 cent
>
> Matthias
>
>
>

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

Nope. No special knowledge needed, at all:
https://www.youtube.com/watch?v=Z4PBNSRp5g8

Gj



On Wed, Sep 27, 2017 at 9:13 AM, Christian Lenz 
wrote:

> I don’t know as much for this Review, so it would be better if there is
> someone else who is doing this, with more advanced experiences.
>
> Gesendet von Mail für Windows 10
>
> Von: Geertjan Wielenga
> Gesendet: Mittwoch, 27. September 2017 09:11
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Allow code contributions or focus on release only?
>
> Sure your PR will get merged, just not right now since we're focused on
> getting Apache NetBeans released. Do you want to join in with the Module
> Review?
>
> Gj
>
> On Wed, 27 Sep 2017 at 09:06, Christian Lenz 
> wrote:
>
> > So I should not doing any PR (my #3 PR will not be merged, right?) and I
> > should do it on Feature Branches? How is the process for Review and
> > merging? If we have 19275 feature branches, no one knows, when the
> Feature
> > is finish. Maybe we should have a release branch where we should merge
> the
> > stuff from Feature into release or whatever to make it clear: my Feature
> is
> > ready for Review/use etc.
> >
> > Gesendet von Mail für Windows 10
> >
> > Von: Geertjan Wielenga
> > Gesendet: Mittwoch, 27. September 2017 00:28
> > An: dev@netbeans.incubator.apache.org
> > Betreff: Re: Allow code contributions or focus on release only?
> >
> > Yup -- and corresponds with what we're doing.
> >
> > I love it when a plan comes together.
> >
> > Gj
> >
> > On Wed, Sep 27, 2017 at 12:03 AM, Wade Chandler  >
> > wrote:
> >
> > > That all sounds like a good strategy to me.
> > >
> > > +1
> > >
> > > Wade
> > >
> > > On Sep 26, 2017 17:44, "Craig Russell"  wrote:
> > >
> > > > I have no dog in this particular hunt, but if it were up to me I'd
> > > > prioritize:
> > > >
> > > > getting code into repositories with clean RAT reports
> > > > getting Netbeans to build and run
> > > > creating release(s) for major platforms
> > > > ...
> > > > serious bug reports
> > > > ...
> > > > features (in branches)
> > > >
> > > > Craig
> > > >
> > > > > On Sep 26, 2017, at 1:16 PM, Sven Reimers 
> > > > wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I fully agree with Jan..
> > > > >
> > > > > Let's try to get something released first so we know the process..
> > > > >
> > > > > Hope to have some time to review modules real soon now..
> > > > >
> > > > > -Sven
> > > > >
> > > > > Am 26.09.2017 22:13 schrieb "Jan Lahoda" :
> > > > >
> > > > >> +1 (I think that if we want to get some rest and fun, we could use
> > > > branches
> > > > >> to experiment with some new features (and I may do so at some
> > point),
> > > > but
> > > > >> we should limit unnecessary changes to master, and use our code
> > > > >> review/discussion bandwidth as much as possible for working on a
> > > > release)
> > > > >>
> > > > >> I personally even think we could try to release just the platform
> > > (e.g.
> > > > >> NetBeans Platform 9.0 beta) once the platform modules are
> reviewed.
> > > That
> > > > >> would help us validate whether the approach we are taking makes
> > sense
> > > > (and
> > > > >> what needs to be improved) and would help us learn about the
> release
> > > > >> process (and the platform is a useful thing on its own, so
> releasing
> > > it
> > > > >> wouldn't be just an artificial move).
> > > > >>
> > > > >> Jan
> > > > >>
> > > > >>
> > > > >> On Tue, Sep 26, 2017 at 8:23 PM, Michael Nascimento <
> > > mist...@gmail.com>
> > > > >> wrote:
> > > > >>
> > > > >>> Definitely we should focus on getting an Apache NetBeans release.
> > > > >>> Sincerely, at this point, I think we should maybe have a Apache
> > > > NetBeans
> > > > >>> 9.0 Java edition, so we can have something release and then a
> full
> > > > Apache
> > > > >>> NB 9.0. Otherwise, sounds like we'll get no release this year,
> > which
> > > > >> would
> > > > >>> be pretty sad.
> > > > >>>
> > > > >>> Regards,
> > > > >>> Michael
> > > > >>>
> > > > >>>  > > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > >>> Virus-free.
> > > > >>> www.avg.com
> > > > >>>  > > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > > >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > > >>>
> > > > >>> On Tue, Sep 26, 2017 at 4:17 AM, Geertjan Wielenga <
> > > > >>> geertjan.wiele...@googlemail.com> wrote:
> > > > >>>
> > > >  Hi all,
> > > > 
> > > >  We need to discuss something, I think -- do we begin accepting
> > pull
> > > >  requests, and thereby encourage pull requests to be created --
> or
> > do
> > > > we
> > > >  focus very narrowly on preparing Apache NetBeans for its first
> > > > >> incubator
> > > >  release?
> > > > 
> > > >  If we were to focus narrowly on preparing the Apache release,
> then
> > > > this
> > > > >>> is
> > > >  what we wou

AW: Allow code contributions or focus on release only?

[Christian Lenz]

I don’t know as much for this Review, so it would be better if there is someone 
else who is doing this, with more advanced experiences. 

Gesendet von Mail für Windows 10

Von: Geertjan Wielenga
Gesendet: Mittwoch, 27. September 2017 09:11
An: dev@netbeans.incubator.apache.org
Betreff: Re: Allow code contributions or focus on release only?

Sure your PR will get merged, just not right now since we're focused on
getting Apache NetBeans released. Do you want to join in with the Module
Review?

Gj

On Wed, 27 Sep 2017 at 09:06, Christian Lenz  wrote:

> So I should not doing any PR (my #3 PR will not be merged, right?) and I
> should do it on Feature Branches? How is the process for Review and
> merging? If we have 19275 feature branches, no one knows, when the Feature
> is finish. Maybe we should have a release branch where we should merge the
> stuff from Feature into release or whatever to make it clear: my Feature is
> ready for Review/use etc.
>
> Gesendet von Mail für Windows 10
>
> Von: Geertjan Wielenga
> Gesendet: Mittwoch, 27. September 2017 00:28
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Allow code contributions or focus on release only?
>
> Yup -- and corresponds with what we're doing.
>
> I love it when a plan comes together.
>
> Gj
>
> On Wed, Sep 27, 2017 at 12:03 AM, Wade Chandler 
> wrote:
>
> > That all sounds like a good strategy to me.
> >
> > +1
> >
> > Wade
> >
> > On Sep 26, 2017 17:44, "Craig Russell"  wrote:
> >
> > > I have no dog in this particular hunt, but if it were up to me I'd
> > > prioritize:
> > >
> > > getting code into repositories with clean RAT reports
> > > getting Netbeans to build and run
> > > creating release(s) for major platforms
> > > ...
> > > serious bug reports
> > > ...
> > > features (in branches)
> > >
> > > Craig
> > >
> > > > On Sep 26, 2017, at 1:16 PM, Sven Reimers 
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I fully agree with Jan..
> > > >
> > > > Let's try to get something released first so we know the process..
> > > >
> > > > Hope to have some time to review modules real soon now..
> > > >
> > > > -Sven
> > > >
> > > > Am 26.09.2017 22:13 schrieb "Jan Lahoda" :
> > > >
> > > >> +1 (I think that if we want to get some rest and fun, we could use
> > > branches
> > > >> to experiment with some new features (and I may do so at some
> point),
> > > but
> > > >> we should limit unnecessary changes to master, and use our code
> > > >> review/discussion bandwidth as much as possible for working on a
> > > release)
> > > >>
> > > >> I personally even think we could try to release just the platform
> > (e.g.
> > > >> NetBeans Platform 9.0 beta) once the platform modules are reviewed.
> > That
> > > >> would help us validate whether the approach we are taking makes
> sense
> > > (and
> > > >> what needs to be improved) and would help us learn about the release
> > > >> process (and the platform is a useful thing on its own, so releasing
> > it
> > > >> wouldn't be just an artificial move).
> > > >>
> > > >> Jan
> > > >>
> > > >>
> > > >> On Tue, Sep 26, 2017 at 8:23 PM, Michael Nascimento <
> > mist...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Definitely we should focus on getting an Apache NetBeans release.
> > > >>> Sincerely, at this point, I think we should maybe have a Apache
> > > NetBeans
> > > >>> 9.0 Java edition, so we can have something release and then a full
> > > Apache
> > > >>> NB 9.0. Otherwise, sounds like we'll get no release this year,
> which
> > > >> would
> > > >>> be pretty sad.
> > > >>>
> > > >>> Regards,
> > > >>> Michael
> > > >>>
> > > >>>  > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > >>> Virus-free.
> > > >>> www.avg.com
> > > >>>  > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >>>
> > > >>> On Tue, Sep 26, 2017 at 4:17 AM, Geertjan Wielenga <
> > > >>> geertjan.wiele...@googlemail.com> wrote:
> > > >>>
> > >  Hi all,
> > > 
> > >  We need to discuss something, I think -- do we begin accepting
> pull
> > >  requests, and thereby encourage pull requests to be created -- or
> do
> > > we
> > >  focus very narrowly on preparing Apache NetBeans for its first
> > > >> incubator
> > >  release?
> > > 
> > >  If we were to focus narrowly on preparing the Apache release, then
> > > this
> > > >>> is
> > >  what we would focus on, nothing else:
> > > 
> > >  https://cwiki.apache.org/confluence/display/NETBEANS/
> > >  List+of+Modules+to+Review
> > > 
> > >  At the same time, of course, people want to add their mark to
> Apache
> > >  NetBeans. And that means code or an icon, a menu item, a new UI
> > thing
> > > >> to
> > >  point at and say -- see, I did that! These kinds of enhancements
> > could
> > > >> be
> > >  done at the sa

Re: Allow code contributions or focus on release only?

[Geertjan Wielenga]

Sure your PR will get merged, just not right now since we're focused on
getting Apache NetBeans released. Do you want to join in with the Module
Review?

Gj

On Wed, 27 Sep 2017 at 09:06, Christian Lenz  wrote:

> So I should not doing any PR (my #3 PR will not be merged, right?) and I
> should do it on Feature Branches? How is the process for Review and
> merging? If we have 19275 feature branches, no one knows, when the Feature
> is finish. Maybe we should have a release branch where we should merge the
> stuff from Feature into release or whatever to make it clear: my Feature is
> ready for Review/use etc.
>
> Gesendet von Mail für Windows 10
>
> Von: Geertjan Wielenga
> Gesendet: Mittwoch, 27. September 2017 00:28
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Allow code contributions or focus on release only?
>
> Yup -- and corresponds with what we're doing.
>
> I love it when a plan comes together.
>
> Gj
>
> On Wed, Sep 27, 2017 at 12:03 AM, Wade Chandler 
> wrote:
>
> > That all sounds like a good strategy to me.
> >
> > +1
> >
> > Wade
> >
> > On Sep 26, 2017 17:44, "Craig Russell"  wrote:
> >
> > > I have no dog in this particular hunt, but if it were up to me I'd
> > > prioritize:
> > >
> > > getting code into repositories with clean RAT reports
> > > getting Netbeans to build and run
> > > creating release(s) for major platforms
> > > ...
> > > serious bug reports
> > > ...
> > > features (in branches)
> > >
> > > Craig
> > >
> > > > On Sep 26, 2017, at 1:16 PM, Sven Reimers 
> > > wrote:
> > > >
> > > > Hi all,
> > > >
> > > > I fully agree with Jan..
> > > >
> > > > Let's try to get something released first so we know the process..
> > > >
> > > > Hope to have some time to review modules real soon now..
> > > >
> > > > -Sven
> > > >
> > > > Am 26.09.2017 22:13 schrieb "Jan Lahoda" :
> > > >
> > > >> +1 (I think that if we want to get some rest and fun, we could use
> > > branches
> > > >> to experiment with some new features (and I may do so at some
> point),
> > > but
> > > >> we should limit unnecessary changes to master, and use our code
> > > >> review/discussion bandwidth as much as possible for working on a
> > > release)
> > > >>
> > > >> I personally even think we could try to release just the platform
> > (e.g.
> > > >> NetBeans Platform 9.0 beta) once the platform modules are reviewed.
> > That
> > > >> would help us validate whether the approach we are taking makes
> sense
> > > (and
> > > >> what needs to be improved) and would help us learn about the release
> > > >> process (and the platform is a useful thing on its own, so releasing
> > it
> > > >> wouldn't be just an artificial move).
> > > >>
> > > >> Jan
> > > >>
> > > >>
> > > >> On Tue, Sep 26, 2017 at 8:23 PM, Michael Nascimento <
> > mist...@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Definitely we should focus on getting an Apache NetBeans release.
> > > >>> Sincerely, at this point, I think we should maybe have a Apache
> > > NetBeans
> > > >>> 9.0 Java edition, so we can have something release and then a full
> > > Apache
> > > >>> NB 9.0. Otherwise, sounds like we'll get no release this year,
> which
> > > >> would
> > > >>> be pretty sad.
> > > >>>
> > > >>> Regards,
> > > >>> Michael
> > > >>>
> > > >>>  > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > >>> Virus-free.
> > > >>> www.avg.com
> > > >>>  > > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > > >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > > >>>
> > > >>> On Tue, Sep 26, 2017 at 4:17 AM, Geertjan Wielenga <
> > > >>> geertjan.wiele...@googlemail.com> wrote:
> > > >>>
> > >  Hi all,
> > > 
> > >  We need to discuss something, I think -- do we begin accepting
> pull
> > >  requests, and thereby encourage pull requests to be created -- or
> do
> > > we
> > >  focus very narrowly on preparing Apache NetBeans for its first
> > > >> incubator
> > >  release?
> > > 
> > >  If we were to focus narrowly on preparing the Apache release, then
> > > this
> > > >>> is
> > >  what we would focus on, nothing else:
> > > 
> > >  https://cwiki.apache.org/confluence/display/NETBEANS/
> > >  List+of+Modules+to+Review
> > > 
> > >  At the same time, of course, people want to add their mark to
> Apache
> > >  NetBeans. And that means code or an icon, a menu item, a new UI
> > thing
> > > >> to
> > >  point at and say -- see, I did that! These kinds of enhancements
> > could
> > > >> be
> > >  done at the same time as the above, and would require that some
> > people
> > >  split their time between doing the module reviews and reviewing
> pull
> > >  requests.
> > > 
> > >  I'm not stating a preference here, just putting the discussion out
> > > >> there,
> > >  since I've seen conflicting opinions about this and I think it
>

AW: Allow code contributions or focus on release only?

[Christian Lenz]

So I should not doing any PR (my #3 PR will not be merged, right?) and I should 
do it on Feature Branches? How is the process for Review and merging? If we 
have 19275 feature branches, no one knows, when the Feature is finish. Maybe we 
should have a release branch where we should merge the stuff from Feature into 
release or whatever to make it clear: my Feature is ready for Review/use etc.

Gesendet von Mail für Windows 10

Von: Geertjan Wielenga
Gesendet: Mittwoch, 27. September 2017 00:28
An: dev@netbeans.incubator.apache.org
Betreff: Re: Allow code contributions or focus on release only?

Yup -- and corresponds with what we're doing.

I love it when a plan comes together.

Gj

On Wed, Sep 27, 2017 at 12:03 AM, Wade Chandler 
wrote:

> That all sounds like a good strategy to me.
>
> +1
>
> Wade
>
> On Sep 26, 2017 17:44, "Craig Russell"  wrote:
>
> > I have no dog in this particular hunt, but if it were up to me I'd
> > prioritize:
> >
> > getting code into repositories with clean RAT reports
> > getting Netbeans to build and run
> > creating release(s) for major platforms
> > ...
> > serious bug reports
> > ...
> > features (in branches)
> >
> > Craig
> >
> > > On Sep 26, 2017, at 1:16 PM, Sven Reimers 
> > wrote:
> > >
> > > Hi all,
> > >
> > > I fully agree with Jan..
> > >
> > > Let's try to get something released first so we know the process..
> > >
> > > Hope to have some time to review modules real soon now..
> > >
> > > -Sven
> > >
> > > Am 26.09.2017 22:13 schrieb "Jan Lahoda" :
> > >
> > >> +1 (I think that if we want to get some rest and fun, we could use
> > branches
> > >> to experiment with some new features (and I may do so at some point),
> > but
> > >> we should limit unnecessary changes to master, and use our code
> > >> review/discussion bandwidth as much as possible for working on a
> > release)
> > >>
> > >> I personally even think we could try to release just the platform
> (e.g.
> > >> NetBeans Platform 9.0 beta) once the platform modules are reviewed.
> That
> > >> would help us validate whether the approach we are taking makes sense
> > (and
> > >> what needs to be improved) and would help us learn about the release
> > >> process (and the platform is a useful thing on its own, so releasing
> it
> > >> wouldn't be just an artificial move).
> > >>
> > >> Jan
> > >>
> > >>
> > >> On Tue, Sep 26, 2017 at 8:23 PM, Michael Nascimento <
> mist...@gmail.com>
> > >> wrote:
> > >>
> > >>> Definitely we should focus on getting an Apache NetBeans release.
> > >>> Sincerely, at this point, I think we should maybe have a Apache
> > NetBeans
> > >>> 9.0 Java edition, so we can have something release and then a full
> > Apache
> > >>> NB 9.0. Otherwise, sounds like we'll get no release this year, which
> > >> would
> > >>> be pretty sad.
> > >>>
> > >>> Regards,
> > >>> Michael
> > >>>
> > >>>  > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > >>> Virus-free.
> > >>> www.avg.com
> > >>>  > >>> utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> > >>> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> > >>>
> > >>> On Tue, Sep 26, 2017 at 4:17 AM, Geertjan Wielenga <
> > >>> geertjan.wiele...@googlemail.com> wrote:
> > >>>
> >  Hi all,
> > 
> >  We need to discuss something, I think -- do we begin accepting pull
> >  requests, and thereby encourage pull requests to be created -- or do
> > we
> >  focus very narrowly on preparing Apache NetBeans for its first
> > >> incubator
> >  release?
> > 
> >  If we were to focus narrowly on preparing the Apache release, then
> > this
> > >>> is
> >  what we would focus on, nothing else:
> > 
> >  https://cwiki.apache.org/confluence/display/NETBEANS/
> >  List+of+Modules+to+Review
> > 
> >  At the same time, of course, people want to add their mark to Apache
> >  NetBeans. And that means code or an icon, a menu item, a new UI
> thing
> > >> to
> >  point at and say -- see, I did that! These kinds of enhancements
> could
> > >> be
> >  done at the same time as the above, and would require that some
> people
> >  split their time between doing the module reviews and reviewing pull
> >  requests.
> > 
> >  I'm not stating a preference here, just putting the discussion out
> > >> there,
> >  since I've seen conflicting opinions about this and I think it would
> > be
> >  good to discuss this centrally.
> > 
> >  Thanks,
> > 
> >  Gj
> > 
> > >>>
> > >>
> >
> > Craig L Russell
> > Secretary, Apache Software Foundation
> > c...@apache.org http://db.apache.org/jdo
> >
> >
>