Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Emilian Bold]

We used Bugzilla before, why not use JIRA?

I notice that Jmeter does user the Github PR but they have a bot that mirrors 
any comment/PR on the dev mailing list. This seems a nice way to also preserve 
history.

--emi

Pe 21 iun. 2017, la 15:13, John McDonnell  a scris:

> One point is that these API reviews could happen in Github.
> 
> Users might want to start using Pull Requests with their changes
> against the public repo and we can use the PR to review and discuss
> the proposed changes.
> 
> Might be easier when we move then patches
> 
> 
> 
>> On 21 June 2017 at 10:16, Bertrand Delacretaz  wrote:
>>> On Wed, Jun 21, 2017 at 1:54 AM, Ross Lamont  
>>> wrote:
>>> ...can we establish an apache API mailing list and move away from the 
>>> Netbeans one?...
>> 
>> With my incubation mentor hat on - please don't, at least not until
>> it's *really* needed.
>> 
>> Using [tags] in subjects works very well for separating things out,
>> and keeps the community together. People can then filter on those
>> [tags] however they like.
>> 
>> -Bertrand
> 
> 
> 
> -- 
> John

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[John McDonnell]

One point is that these API reviews could happen in Github.

Users might want to start using Pull Requests with their changes
against the public repo and we can use the PR to review and discuss
the proposed changes.

Might be easier when we move then patches



On 21 June 2017 at 10:16, Bertrand Delacretaz  wrote:
> On Wed, Jun 21, 2017 at 1:54 AM, Ross Lamont  
> wrote:
>> ...can we establish an apache API mailing list and move away from the 
>> Netbeans one?...
>
> With my incubation mentor hat on - please don't, at least not until
> it's *really* needed.
>
> Using [tags] in subjects works very well for separating things out,
> and keeps the community together. People can then filter on those
> [tags] however they like.
>
> -Bertrand



-- 
John

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Bertrand Delacretaz]

On Wed, Jun 21, 2017 at 1:54 AM, Ross Lamont  wrote:
> ...can we establish an apache API mailing list and move away from the 
> Netbeans one?...

With my incubation mentor hat on - please don't, at least not until
it's *really* needed.

Using [tags] in subjects works very well for separating things out,
and keeps the community together. People can then filter on those
[tags] however they like.

-Bertrand

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Ross Lamont]

Regardless of how the new API review process works (FWIW something similar to 
the current makes sense to me - now that I’ve read it) I think it’s safe to say 
that there will be such a process.

To that end, can we establish an apache API mailing list and move away from the 
Netbeans one?

Also, given that UX is a big thumbs up for Netbeans, can I suggest that 
establishing a review process for UX should be a very early post migration 
priority.

- Ross

> On 20 Jun 2017, at 8:15 pm, Emilian Bold  wrote:
> 
> I agree that in theory the processes should remain. But:
> 
> * there is no official list of such processes. I only know the ones I 
> interacted with. (I remembered how hard I had to ask long ago to clarify how 
> the release branching process works).
> 
> * they should be filtered anyhow based on Apache compatibility and/or 
> replaced by existing Apache processes, plus
> 
> * these processes were not decided by the community at large, but were mostly 
> an emanation of the core Sun/Oracle developer group. Which means that they 
> are not necessarily a good fit for the new situation.
> 
> --emi
> 
> Pe 20 iun. 2017, la 12:03, Neil C Smith  a 
> scris:
> 
>> 
>>> On Tue, Jun 20, 2017 at 9:39 AM Emilian Bold  wrote:
>>> I do. The previous API Review had some logic to it. I don't believe we
>>> can do without it entirely.
>> 
>> Or at all!  I agree with much of what you suggest, but I'm interested to 
>> turn that around - why do you believe things need to change now / what 
>> aspects are not going to meet Apache compliance?
>> 
>> My point was that I don't see the point in changing processes that have 
>> worked for the project for years right now, unless it's something where our 
>> hand is forced.  Surely better to establish a regular review of processes 
>> (quarterly, post-releases, ?) and then evolve things where need be?  IMO 
>> this is the wrong time to be changing too much.
>> 
>> Best wishes,
>> 
>> Neil
>> -- 
>> Neil C Smith
>> Artist & Technologist
>> www.neilcsmith.net
>> 
>> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Submitting patches for Netbeans 9.

[Ross Lamont]

Thanks Emi, I’ll work through all the comments on this thread and post a bug 
and patch in JIRA.

Cheers
Ross

> On 20 Jun 2017, at 3:36 pm, Emilian Bold  wrote:
> 
> For small contributions an ICLA is not mandatory but since you want to
> work on a bigger feature it would certainly help. There's only one
> ICLA but signing one won't make you a committer without a vote.
> 
> While your patch may be slim it seems to introduce a SPI so it would
> require an API Review (http://wiki.netbeans.org/APIReviews ).
> 
> API Reviews are a old pre-Apache process but I believe we will have
> something similar under Apache too. We cannot just allow hooks all
> over the place if they impact the overall architecture.
> 
> 
> --emi
> 
> 
> On Tue, Jun 20, 2017 at 4:19 AM, Ross Lamont  
> wrote:
>> Hi folks,
>> 
>> Given that there are a lot of balls in the air with regard to apache 
>> transition and Netbeans 9 release schedule, what is the correct process for 
>> submitting a patch, and what chance of getting it into Netbeans 9?
>> 
>> Specifically:
>> 1. Do I create a bug/feature in Jira or in Bugzilla?
>> 2. I have not yet signed a contributor agreement.  Do I sign the old Oracle 
>> one, or do I only deal with the Apache ICLA? Is there a different ICLA for 
>> contributor vs committer?
>> 3. Is there any sort of code freeze (soft or otherwise) in place at the 
>> moment for Netbeans 9.0, 8.3 or 8.2.1? The patch I’m proposing will be slim 
>> - it is just a refactoring to replace some hardwired construction of Cookies 
>> with a factory interface and Service Provider semantics (affecting 
>> XMLDataObject).  This will allow me (and others) to develop new XML 
>> validation algorithms as a plugin in isolation from the main build.
>> 
>> Cheers
>> Ross

Re: Submitting patches for Netbeans 9.

[Craig Russell]

Hi Ross,

> On Jun 19, 2017, at 6:19 PM, Ross Lamont  wrote:
> 
> Hi folks,
> 
> Given that there are a lot of balls in the air with regard to apache 
> transition and Netbeans 9 release schedule, what is the correct process for 
> submitting a patch, and what chance of getting it into Netbeans 9?
> 
> Specifically:
> 1. Do I create a bug/feature in Jira or in Bugzilla?
> 2. I have not yet signed a contributor agreement.  Do I sign the old Oracle 
> one,

As Geertjan says, the Oracle agreement is not relevant to Apache. 

> or do I only deal with the Apache ICLA?

As you intend to participate in the Apache Netbeans project, I would recommend 
filing an ICLA. Detailed information is available at 
http://www.apache.org/licenses/#submitting

> Is there a different ICLA for contributor vs committer?

As Geertjan says, there is only one ICLA. 

Regards,

Craig

> 3. Is there any sort of code freeze (soft or otherwise) in place at the 
> moment for Netbeans 9.0, 8.3 or 8.2.1? The patch I’m proposing will be slim - 
> it is just a refactoring to replace some hardwired construction of Cookies 
> with a factory interface and Service Provider semantics (affecting 
> XMLDataObject).  This will allow me (and others) to develop new XML 
> validation algorithms as a plugin in isolation from the main build.
> 
> Cheers
> Ross

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Emilian Bold]

I agree we don't have to change everything, but it's a good moment to document 
our existing processes at least.

Note that I started this thread from the question

> Do you envision a voting for new API/SPI's?

So it was an Apache angle on SPI/API changes.

--emi

Pe 20 iun. 2017, la 13:55, Neil C Smith  a scris:

> On Tue, Jun 20, 2017 at 11:15 AM Emilian Bold 
> wrote:
> 
>> 
>> * these processes were not decided by the community at large, but were
>> mostly an emanation of the core Sun/Oracle developer group. Which means
>> that they are not necessarily a good fit for the new situation.
>> 
>> 
> Agreed, just don't think now is the right time to decide what fits
> better.  One of the biggest threats to projects transitioning as we are is
> throwing out too many existing processes, that are known to the existing
> contributors, before better-fit processes are ready.  I think we have time
> to work that out.  Personally I think this is better reviewed as
> "Submitting patches for NetBeans 9.1"! :-)
> 
> 2c
> 
> Best wishes,
> 
> Neil
> -- 
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Neil C Smith]

On Tue, Jun 20, 2017 at 11:15 AM Emilian Bold 
wrote:

>
> * these processes were not decided by the community at large, but were
> mostly an emanation of the core Sun/Oracle developer group. Which means
> that they are not necessarily a good fit for the new situation.
>
>
 Agreed, just don't think now is the right time to decide what fits
better.  One of the biggest threats to projects transitioning as we are is
throwing out too many existing processes, that are known to the existing
contributors, before better-fit processes are ready.  I think we have time
to work that out.  Personally I think this is better reviewed as
"Submitting patches for NetBeans 9.1"! :-)

2c

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Bertrand Delacretaz]

On Tue, Jun 20, 2017 at 12:21 PM, Emilian Bold  wrote:
> ...It's also unclear to me how "product management" and "user experience 
> design" would work under Apache

The (P)PMC drives the project and can setup those things however it
wants (although hearing of "product management" here gives me the
corporate shivers ;-)

UI and UX are in my experience very hard to get right in open source
projects as it's quite easy to get into bikeshedding about minor
things.

I don't know how NetBeans does that but I suppose supporting themes
that are independent from the code helps - people can then contribute
their own themes inside or outside of Apache NetBeans. There might
even be a business in creating commercial themes, as getting those
right requires a lot of effort and focus that can be hard to find in a
participative project - and Apache loves to enable businesses
(although they don't have a voice inside our projects).

-Bertrand

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Emilian Bold]

Yes, it's CTR vs RTC with variations on the seriousness of the review. A small 
impact change needs a single review from another committer while a big change 
needs a binding vote majority.

It's also unclear to me how "product management" and "user experience design" 
would work under Apache. Because here we could decide to reject a contribution 
on UX/product considerations alone. Not sure how voting would help/work here.

--emi

Pe 20 iun. 2017, la 12:17, Bertrand Delacretaz  a scris:

> Hi,
> 
>> On Tue, Jun 20, 2017 at 10:38 AM, Emilian Bold  
>> wrote:
>> ...high impacting API / SPI changes must have proper voting
> 
> I think what you're describing is CTR vs. RTC
> (https://www.apache.org/foundation/glossary.html)
> 
> Many projects have some areas of their codebase under RTC, typically
> based on module names or attributes like "it's an API", based on a
> documented list of where CTR applies.
> 
> OTOH if all changes are consistently and relatively quickly reviewed,
> source code control is your friend and nothing bad can happen.
> 
> -Bertrand

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Emilian Bold]

I agree that in theory the processes should remain. But:

* there is no official list of such processes. I only know the ones I 
interacted with. (I remembered how hard I had to ask long ago to clarify how 
the release branching process works).

* they should be filtered anyhow based on Apache compatibility and/or replaced 
by existing Apache processes, plus

* these processes were not decided by the community at large, but were mostly 
an emanation of the core Sun/Oracle developer group. Which means that they are 
not necessarily a good fit for the new situation.

--emi

Pe 20 iun. 2017, la 12:03, Neil C Smith  a scris:

> 
>> On Tue, Jun 20, 2017 at 9:39 AM Emilian Bold  wrote:
>> I do. The previous API Review had some logic to it. I don't believe we
>> can do without it entirely.
> 
> Or at all!  I agree with much of what you suggest, but I'm interested to turn 
> that around - why do you believe things need to change now / what aspects are 
> not going to meet Apache compliance?
> 
> My point was that I don't see the point in changing processes that have 
> worked for the project for years right now, unless it's something where our 
> hand is forced.  Surely better to establish a regular review of processes 
> (quarterly, post-releases, ?) and then evolve things where need be?  IMO this 
> is the wrong time to be changing too much.
> 
> Best wishes,
> 
> Neil
> -- 
> Neil C Smith
> Artist & Technologist
> www.neilcsmith.net
> 
> Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

Re: Submitting patches for Netbeans 9.

[Jaroslav Tulach]

On úterý 20. června 2017 9:58:01 CEST Sven Reimers wrote:
> Do you envision a voting for new API/SPI's?

I would be pleased if the project continued to do API changes in the spirit of 
http://wiki.netbeans.org/APIReviews

-jt

Re: API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Neil C Smith]

On Tue, Jun 20, 2017 at 9:39 AM Emilian Bold  wrote:

> I do. The previous API Review had some logic to it. I don't believe we
> can do without it entirely.
>

Or at all!  I agree with much of what you suggest, but I'm interested to
turn that around - why do you believe things need to change now / what
aspects are not going to meet Apache compliance?

My point was that I don't see the point in changing processes that have
worked for the project for years right now, unless it's something where our
hand is forced.  Surely better to establish a regular review of processes
(quarterly, post-releases, ?) and then evolve things where need be?  IMO
this is the wrong time to be changing too much.

Best wishes,

Neil
-- 
Neil C Smith
Artist & Technologist
www.neilcsmith.net

Praxis LIVE - hybrid visual IDE for creative coding - www.praxislive.org

API Review under Apache [WAS: Re: Submitting patches for Netbeans 9.]

[Emilian Bold]

I do. The previous API Review had some logic to it. I don't believe we
can do without it entirely.

I see a spectrum of options here:

* A bugfix with no external impact may be added by a single committer directly.
* low impact API / SPI changes must have some API review to them, ie.
at least 2 committers involved. Ideally one of the them with some
experience in that area.
* high impacting API / SPI changes must have proper voting.
* also, visible UI changes should have some voting in. Good UX is also
about saying no. Otherwise there will always be this little menu item
/ toolbar icon to squeeze.

--emi

On Tue, Jun 20, 2017 at 10:58 AM, Sven Reimers  wrote:
> Do you envision a voting for new API/SPI's?
>
> Seems if we see a need we should clarify the process snd the gatekeepers...
>
> -Sven
>
> Am 20.06.2017 07:37 schrieb "Emilian Bold" :
>
>> For small contributions an ICLA is not mandatory but since you want to
>> work on a bigger feature it would certainly help. There's only one
>> ICLA but signing one won't make you a committer without a vote.
>>
>> While your patch may be slim it seems to introduce a SPI so it would
>> require an API Review (http://wiki.netbeans.org/APIReviews ).
>>
>> API Reviews are a old pre-Apache process but I believe we will have
>> something similar under Apache too. We cannot just allow hooks all
>> over the place if they impact the overall architecture.
>>
>>
>> --emi
>>
>>
>> On Tue, Jun 20, 2017 at 4:19 AM, Ross Lamont 
>> wrote:
>> > Hi folks,
>> >
>> > Given that there are a lot of balls in the air with regard to apache
>> transition and Netbeans 9 release schedule, what is the correct process for
>> submitting a patch, and what chance of getting it into Netbeans 9?
>> >
>> > Specifically:
>> >  1. Do I create a bug/feature in Jira or in Bugzilla?
>> >  2. I have not yet signed a contributor agreement.  Do I sign the old
>> Oracle one, or do I only deal with the Apache ICLA? Is there a different
>> ICLA for contributor vs committer?
>> >  3. Is there any sort of code freeze (soft or otherwise) in place at the
>> moment for Netbeans 9.0, 8.3 or 8.2.1? The patch I’m proposing will be slim
>> - it is just a refactoring to replace some hardwired construction of
>> Cookies with a factory interface and Service Provider semantics (affecting
>> XMLDataObject).  This will allow me (and others) to develop new XML
>> validation algorithms as a plugin in isolation from the main build.
>> >
>> > Cheers
>> > Ross
>>

Re: Submitting patches for Netbeans 9.

[Geertjan Wielenga]

Here's how to participate:

https://cwiki.apache.org/confluence/display/NETBEANS/How+to+Participate

Yes, please create bug/feature requests in Apache NetBens Jira:

https://issues.apache.org/jira/projects/NETBEANS/issues/NETBEANS-7?filter=allopenissues

No, an Oracle Contributor Agreement is irrelevant in Apache. The approach
would be to create an issue and attach your patch there. Someone who is a
committer will integrate it. Over time, depending on your level of
activity, you'll be asked whether you'd like to become a committer. You
don't apply to become a committer, it's something that the existing
committers will approach you about, based on your activity. In the
meantime, providing patches is the way to get your fixes and enhancements
into the Apache NetBeans codebase.

As soon as we get the 1st code donation into Apache, we'd like to begin
wrapping it up and doing our first incubator release. We'd probably start
accepting code fixes and patches and so on after that first release, which
we need to go through to get out of the incubator.

Gj

On Tue, Jun 20, 2017 at 3:19 AM, Ross Lamont 
wrote:

> Hi folks,
>
> Given that there are a lot of balls in the air with regard to apache
> transition and Netbeans 9 release schedule, what is the correct process for
> submitting a patch, and what chance of getting it into Netbeans 9?
>
> Specifically:
>  1. Do I create a bug/feature in Jira or in Bugzilla?
>  2. I have not yet signed a contributor agreement.  Do I sign the old
> Oracle one, or do I only deal with the Apache ICLA? Is there a different
> ICLA for contributor vs committer?
>  3. Is there any sort of code freeze (soft or otherwise) in place at the
> moment for Netbeans 9.0, 8.3 or 8.2.1? The patch I’m proposing will be slim
> - it is just a refactoring to replace some hardwired construction of
> Cookies with a factory interface and Service Provider semantics (affecting
> XMLDataObject).  This will allow me (and others) to develop new XML
> validation algorithms as a plugin in isolation from the main build.
>
> Cheers
> Ross
>

Submitting patches for Netbeans 9.

[Ross Lamont]

Hi folks,

Given that there are a lot of balls in the air with regard to apache transition 
and Netbeans 9 release schedule, what is the correct process for submitting a 
patch, and what chance of getting it into Netbeans 9?

Specifically:
 1. Do I create a bug/feature in Jira or in Bugzilla?
 2. I have not yet signed a contributor agreement.  Do I sign the old Oracle 
one, or do I only deal with the Apache ICLA? Is there a different ICLA for 
contributor vs committer?
 3. Is there any sort of code freeze (soft or otherwise) in place at the moment 
for Netbeans 9.0, 8.3 or 8.2.1? The patch I’m proposing will be slim - it is 
just a refactoring to replace some hardwired construction of Cookies with a 
factory interface and Service Provider semantics (affecting XMLDataObject).  
This will allow me (and others) to develop new XML validation algorithms as a 
plugin in isolation from the main build.

Cheers
Ross