You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Christian Lenz <Ch...@gmx.net> on 2017/02/27 13:48:04 UTC
Code contribution process.
I know there is long way to go to bring NetBeans to apache, but a lot of people signed such CLAs and atm, I contribute directly to the code via Pull Requests to the netbeans-releases repo of Emilian Bold. He is the only one atm, to accept such pull requests. So tell me, how can we improve this task? I have a lot of feature branches and I can finished some of them soon and will start with new one. How can I contribute directly to the code or how is the best way? Because of emilian is the only one who can accept pull requests, this is kind of bottle neck.
Regards
Chris
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
I agree and think we need a process. There are certain aspects of NetBeans that make it what it is. 1) First, it is a rich client platform. 2) There is an IDE built on the platform. 3) Much has been extensible and we often want it more so; look at recent discussions of “friend". 4) We have generally had pretty good documentation in both javadoc and tutorials, and we want to keep that up. 5) There is a good sized community, and we hope to grow it plus the number of contributors.
As the contributor community grows, surely we want everyone contributing to understand the first points about the system, and I’m sure there are other more granular items some of us believe strongly about. Pull Requests give us an opportunity to validate things are the way they “should” be (the NB way), even among voted contributors, and too, having some things enumerated and understood up front helps people make sure they don’t spend a bunch of time doing something which may be complicated to redo/refactor to the NB way, which may limit their passion for contributing.
Chris and I have been having some DM discussions offline on Slack as an example, and we have been discussing what it means to have modules as well as what it means for certain modules to be the “core”, some the IDE, and others community modules as well as dependency leak with action references etc, i.e. where if one wants a running system, and a module is dependent on something specific in the “layer”, then some producing module will have to be present, and what that can mean in say a “core” module (one with say EditorView). I also fear there is a misconception that just because something is a module, that inherently means it slows the system down, or is some how related to some of NetBeans IDEs performance issues, versus modules with issues or some bug which needs tracked down and fixed. Modules allow the points above to be adhered to. I think these things are very important for people to understand when contributing.
Wade
===================
Wade Chandler
e: consult@wadechandler.com
> On Feb 27, 2017, at 09:43, Geertjan Wielenga <ge...@googlemail.com> wrote:
>
> That's true. Good point.
>
> Still, we'll need some kind of process, i.e., a staging process as well as
> test specifications for those who'll be testing new releases etc.
>
> Gj
>
> On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
> wrote:
>
>>> I fear a future where everyone can simply put anything
>> into NetBeans in Apache without any kind of intermediate or staging
>> process.
>>
>> Not everybody will be an Apache committer and that's why we have a vote
>> for it.
>>
>> --emi
>>
>> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> a scris:
>>
>>> I fear a future where everyone can simply put anything
>>> into NetBeans in Apache without any kind of intermediate or staging
>> process.
>>
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
> On Feb 27, 2017, at 11:48, Emilian Bold <em...@gmail.com> wrote:
> I really don't see an empowered committer as someone outside the community.
>
I’m not sure that has been stated. I don’t see someone sending a patch as outside the community either; they are just newer. Having a process to follow doesn’t have to be a negative thing, and certainly doesn’t mean you are outside the community regardless of which level a process applies.
>
>> If becoming a contributor means I don’t have to sync up with the “herd”
> or “pack", and can just push changes in, without any review, or
> repercussion, then that isn’t exactly community or being responsible
>
> As a committer I expect *precisely* to be able to push changes without any
> review. As a committer I will take responsibility for my actions and I
> accept the repercussions ranging from personal embarrassment to full-blown
> vote against.
>
>
> I believe the Apache "Lazy Consensus" matches my view perfectly.
>
> Of course, changing public APIs or doing massive refactoring or large new
> features without some review is one thing, but day to day bug fixing, small
> improvements and features, etc. really need no oversight. Just a single
> committer with the time and know how.
And without a process between committers and a formal understanding when does that get driven home? I agree some simple bug fix or a few line change is a different matter, and that too can be enumerated, but as you state here, there are definitely times which require reviews as well as up front discussions. There are also some basic levels of understanding committers need to know, which I believe you would also agree with, and I think enumerating those things, and then also agreeing on them as a community makes sure those are in fact the basic imperatives, guidelines, and understandings we have from the start, and then there is no confusion about what they are.
Then, when someone is having a conversation with someone about how some changes should perhaps be organized, there is a clear document to point to to back that up versus reiterating conversations which eventually lead to repetitive email threads; we all know people don’t actually search email lists :-)
Wade
>
> --emi
>
> On Mon, Feb 27, 2017 at 6:17 PM, Wade Chandler <wadechandler@apache.org <ma...@apache.org>>
> wrote:
>
>> I think it already does mean something. Contributors have the right to
>> actually vote, where as someone sending a patch doesn’t. Contributors can
>> actually merge something in. Contributors get a massive deal on ApacheConf
>> tickets. We have Apache user IDs and other items of access many don’t. But,
>> I think one of our responsibilities is laying out a process which helps
>> makes working in our community better, more efficient, able to make
>> progress, and at the same time help keep the quality of the project high.
>>
>> If becoming a contributor means I don’t have to sync up with the “herd” or
>> “pack", and can just push changes in, without any review, or repercussion,
>> then that isn’t exactly community or being responsible, and certainly we
>> can “vote someone out” or have a bigger discussion after the fact were
>> someone to be that way, but this feels the difference in being proactive
>> virus waiting for something like that to happen. Imagine we could all put a
>> road, side walk, or park where we wanted just because we were on some city
>> council some where, even if we had the best intentions, and thought
>> everyone else would think it was a good idea. That seems a decent analogy.
>>
>> I also don’t believe a process has to be very heavy versus some general
>> imperatives of NetBeans, guidelines, and a very transparent and light PR
>> process to allow imperative and guideline review, plus help us all reduce
>> bugs ahead of time. A review doesn’t mean one isn’t trusted, but is
>> technically a mutual trust exercise:
>> http://www.davidwhitney.co.uk/Blog/2016/04/ <http://www.davidwhitney.co.uk/Blog/2016/04/> <http://www.davidwhitney.co <http://www.davidwhitney.co/>.
>> uk/Blog/2016/04/>
>>
>> Wade
>>
>>
>>> On Feb 27, 2017, at 10:16, Emilian Bold <em...@gmail.com> wrote:
>>>
>>> A process will emerge but I find it important that a committer should
>> actually *mean* something.
>>>
>>> It does and should mean extra rights and extra responsibilities.
>>>
>>>
>>>
>>> --emi
>>>
>>> Pe 27 feb. 2017, la 16:43, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> a scris:
>>>
>>>> That's true. Good point.
>>>>
>>>> Still, we'll need some kind of process, i.e., a staging process as well
>> as
>>>> test specifications for those who'll be testing new releases etc.
>>>>
>>>> Gj
>>>>
>>>> On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
>>>> wrote:
>>>>
>>>>>> I fear a future where everyone can simply put anything
>>>>> into NetBeans in Apache without any kind of intermediate or staging
>>>>> process.
>>>>>
>>>>> Not everybody will be an Apache committer and that's why we have a vote
>>>>> for it.
>>>>>
>>>>> --emi
>>>>>
>>>>> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
>>>>> geertjan.wielenga@googlemail.com> a scris:
>>>>>
>>>>>> I fear a future where everyone can simply put anything
>>>>>> into NetBeans in Apache without any kind of intermediate or staging
>>>>> process.
Re: Code contribution process.
Posted by John McDonnell <mc...@gmail.com>.
Apologies, too much confusion in the last email...
> @Emilian,
>
> Would you not want someone else to review your code changes anyways?
>
>
> Yes as a committer you have more access, than say I do, but without any checks and balances, not every committer might be writing their code to the same quality. Maybe another committer has better knowledge of a certain area that your change is for, and could be in a better position to point out something during a review etc...
>
> Why not submit a PR, and let another committer review, and you/he then pushes when both are happy. You're still maintain better access/standing but you allow others to see that everyone is following the same process.
>
> Regards
>
> John
> On 27 Feb 2017, at 18:28, John McDonnell <mc...@gmail.com> wrote:
>
> @Emilian,
>
> Would you not want someone else to review anyways?
>
>
> Yes as a committer you have more access, than say I do, but without any checks and balances not every committer might be writing code to the same quality. - Or maybe another committer has better knowledge of a certain area and is able to point out something during a review etc...
>
> Why not you submit a PR, another committer reviews, and you/he then pushes. You still maintain better access/standing but you allow others to see that everyone is following the same process.
>
> Regards
>
> John
>
>
>
>> On 27 Feb 2017, at 17:21, Bertrand Delacretaz <bd...@apache.org> wrote:
>>
>> On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com> wrote:
>>> ...As a committer I expect *precisely* to be able to push changes without any
>>> review...
>>
>>> ...I believe the Apache "Lazy Consensus" matches my view perfectly...
>>
>> IIUC what you're describing is CTR, Commit-Then-Review.
>>
>> It's perfectly fine for an Apache project to use CTR for some parts of
>> its code and RTC (Review-Then-Commit) for other, more critical parts.
>>
>> -Bertrand
>
Re: Code contribution process.
Posted by John McDonnell <mc...@gmail.com>.
@Emilian,
Would you not want someone else to review anyways?
Yes as a committer you have more access, than say I do, but without any checks and balances not every committer might be writing code to the same quality. - Or maybe another committer has better knowledge of a certain area and is able to point out something during a review etc...
Why not you submit a PR, another committer reviews, and you/he then pushes. You still maintain better access/standing but you allow others to see that everyone is following the same process.
Regards
John
> On 27 Feb 2017, at 17:21, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com> wrote:
>> ...As a committer I expect *precisely* to be able to push changes without any
>> review...
>
>> ...I believe the Apache "Lazy Consensus" matches my view perfectly...
>
> IIUC what you're describing is CTR, Commit-Then-Review.
>
> It's perfectly fine for an Apache project to use CTR for some parts of
> its code and RTC (Review-Then-Commit) for other, more critical parts.
>
> -Bertrand
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
If nobody objects, I volunteer to setup a Wiki page, make a layout, and write up some things. Then, the community can review, add, remove, etc, and then make some decisions, and one decision may be we defer, but having something to look at to give a better idea of what we are all talking about may be helpful.
Wade
> On Feb 27, 2017, at 12:21, Bertrand Delacretaz <bd...@apache.org> wrote:
>
> On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com> wrote:
>> ...As a committer I expect *precisely* to be able to push changes without any
>> review...
>
>> ...I believe the Apache "Lazy Consensus" matches my view perfectly...
>
> IIUC what you're describing is CTR, Commit-Then-Review.
>
> It's perfectly fine for an Apache project to use CTR for some parts of
> its code and RTC (Review-Then-Commit) for other, more critical parts.
>
> -Bertrand
Re: Code contribution process.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Perfect.
Gj
On Mon, Feb 27, 2017 at 7:48 PM, Emilian Bold <em...@gmail.com>
wrote:
> >
> > IIUC what you're describing is CTR, Commit-Then-Review.
> > It's perfectly fine for an Apache project to use CTR for some parts of
> > its code and RTC (Review-Then-Commit) for other, more critical parts.
>
>
> Bless you!
>
> --emi
>
> On Mon, Feb 27, 2017 at 7:21 PM, Bertrand Delacretaz <
> bdelacretaz@apache.org
> > wrote:
>
> > On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com>
> > wrote:
> > > ...As a committer I expect *precisely* to be able to push changes
> > without any
> > > review...
> >
> > > ...I believe the Apache "Lazy Consensus" matches my view perfectly...
> >
> > IIUC what you're describing is CTR, Commit-Then-Review.
> >
> > It's perfectly fine for an Apache project to use CTR for some parts of
> > its code and RTC (Review-Then-Commit) for other, more critical parts.
> >
> > -Bertrand
> >
>
Re: Code contribution process.
Posted by Emilian Bold <em...@gmail.com>.
>
> IIUC what you're describing is CTR, Commit-Then-Review.
> It's perfectly fine for an Apache project to use CTR for some parts of
> its code and RTC (Review-Then-Commit) for other, more critical parts.
Bless you!
--emi
On Mon, Feb 27, 2017 at 7:21 PM, Bertrand Delacretaz <bdelacretaz@apache.org
> wrote:
> On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com>
> wrote:
> > ...As a committer I expect *precisely* to be able to push changes
> without any
> > review...
>
> > ...I believe the Apache "Lazy Consensus" matches my view perfectly...
>
> IIUC what you're describing is CTR, Commit-Then-Review.
>
> It's perfectly fine for an Apache project to use CTR for some parts of
> its code and RTC (Review-Then-Commit) for other, more critical parts.
>
> -Bertrand
>
Re: Code contribution process.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold <em...@gmail.com> wrote:
> ...As a committer I expect *precisely* to be able to push changes without any
> review...
> ...I believe the Apache "Lazy Consensus" matches my view perfectly...
IIUC what you're describing is CTR, Commit-Then-Review.
It's perfectly fine for an Apache project to use CTR for some parts of
its code and RTC (Review-Then-Commit) for other, more critical parts.
-Bertrand
Re: Code contribution process.
Posted by Emilian Bold <em...@gmail.com>.
> If becoming a contributor means I don’t have to sync up with the “herd”
or “pack", and can just push changes in, without any review, or
repercussion, then that isn’t exactly community or being responsible
As a committer I expect *precisely* to be able to push changes without any
review. As a committer I will take responsibility for my actions and I
accept the repercussions ranging from personal embarrassment to full-blown
vote against.
I really don't see an empowered committer as someone outside the community.
I believe the Apache "Lazy Consensus" matches my view perfectly.
Of course, changing public APIs or doing massive refactoring or large new
features without some review is one thing, but day to day bug fixing, small
improvements and features, etc. really need no oversight. Just a single
committer with the time and know how.
--emi
On Mon, Feb 27, 2017 at 6:17 PM, Wade Chandler <wa...@apache.org>
wrote:
> I think it already does mean something. Contributors have the right to
> actually vote, where as someone sending a patch doesn’t. Contributors can
> actually merge something in. Contributors get a massive deal on ApacheConf
> tickets. We have Apache user IDs and other items of access many don’t. But,
> I think one of our responsibilities is laying out a process which helps
> makes working in our community better, more efficient, able to make
> progress, and at the same time help keep the quality of the project high.
>
> If becoming a contributor means I don’t have to sync up with the “herd” or
> “pack", and can just push changes in, without any review, or repercussion,
> then that isn’t exactly community or being responsible, and certainly we
> can “vote someone out” or have a bigger discussion after the fact were
> someone to be that way, but this feels the difference in being proactive
> virus waiting for something like that to happen. Imagine we could all put a
> road, side walk, or park where we wanted just because we were on some city
> council some where, even if we had the best intentions, and thought
> everyone else would think it was a good idea. That seems a decent analogy.
>
> I also don’t believe a process has to be very heavy versus some general
> imperatives of NetBeans, guidelines, and a very transparent and light PR
> process to allow imperative and guideline review, plus help us all reduce
> bugs ahead of time. A review doesn’t mean one isn’t trusted, but is
> technically a mutual trust exercise:
> http://www.davidwhitney.co.uk/Blog/2016/04/ <http://www.davidwhitney.co.
> uk/Blog/2016/04/>
>
> Wade
>
>
> > On Feb 27, 2017, at 10:16, Emilian Bold <em...@gmail.com> wrote:
> >
> > A process will emerge but I find it important that a committer should
> actually *mean* something.
> >
> > It does and should mean extra rights and extra responsibilities.
> >
> >
> >
> > --emi
> >
> > Pe 27 feb. 2017, la 16:43, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> a scris:
> >
> >> That's true. Good point.
> >>
> >> Still, we'll need some kind of process, i.e., a staging process as well
> as
> >> test specifications for those who'll be testing new releases etc.
> >>
> >> Gj
> >>
> >> On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
> >> wrote:
> >>
> >>>> I fear a future where everyone can simply put anything
> >>> into NetBeans in Apache without any kind of intermediate or staging
> >>> process.
> >>>
> >>> Not everybody will be an Apache committer and that's why we have a vote
> >>> for it.
> >>>
> >>> --emi
> >>>
> >>> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
> >>> geertjan.wielenga@googlemail.com> a scris:
> >>>
> >>>> I fear a future where everyone can simply put anything
> >>>> into NetBeans in Apache without any kind of intermediate or staging
> >>> process.
> >>>
>
>
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
> On Feb 28, 2017, at 05:17, Emmanuel Lécharny <el...@gmail.com> wrote:
>
>
>
> Le 27/02/2017 à 17:17, Wade Chandler a écrit :
>> I think it already does mean something. Contributors have the right to actually vote, where as someone sending a patch doesn’t.
>
> Actually, no.
>
> Of course, everyone can vote, but some votes are binding votes, when
> others are just informative.
>
> Typically, committers don't have a binding vote, only PMC members have.
>
> Does it mean committers vote are useless ? Certainly not ! But it's
> important to understand the difference.
>
> Please have a look at http://apache.org/foundation/voting.html <http://apache.org/foundation/voting.html>
Thanks for the clarification on that point. Definitely slipped my mind considering our PPMC of initial committers, but definitely a facet to consider in the conversation, and seems this thread would be typical for PPMCs to have depending on the type of project which they are responsible; project and development methodologies for the project/product.
Thanks,
Wade
Re: Code contribution process.
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 27/02/2017 à 17:17, Wade Chandler a écrit :
> I think it already does mean something. Contributors have the right to actually vote, where as someone sending a patch doesn’t.
Actually, no.
Of course, everyone can vote, but some votes are binding votes, when
others are just informative.
Typically, committers don't have a binding vote, only PMC members have.
Does it mean committers vote are useless ? Certainly not ! But it's
important to understand the difference.
Please have a look at http://apache.org/foundation/voting.html
--
Emmanuel Lecharny
Symas.com
directory.apache.org
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
I think it already does mean something. Contributors have the right to actually vote, where as someone sending a patch doesn’t. Contributors can actually merge something in. Contributors get a massive deal on ApacheConf tickets. We have Apache user IDs and other items of access many don’t. But, I think one of our responsibilities is laying out a process which helps makes working in our community better, more efficient, able to make progress, and at the same time help keep the quality of the project high.
If becoming a contributor means I don’t have to sync up with the “herd” or “pack", and can just push changes in, without any review, or repercussion, then that isn’t exactly community or being responsible, and certainly we can “vote someone out” or have a bigger discussion after the fact were someone to be that way, but this feels the difference in being proactive virus waiting for something like that to happen. Imagine we could all put a road, side walk, or park where we wanted just because we were on some city council some where, even if we had the best intentions, and thought everyone else would think it was a good idea. That seems a decent analogy.
I also don’t believe a process has to be very heavy versus some general imperatives of NetBeans, guidelines, and a very transparent and light PR process to allow imperative and guideline review, plus help us all reduce bugs ahead of time. A review doesn’t mean one isn’t trusted, but is technically a mutual trust exercise:
http://www.davidwhitney.co.uk/Blog/2016/04/ <http://www.davidwhitney.co.uk/Blog/2016/04/>
Wade
> On Feb 27, 2017, at 10:16, Emilian Bold <em...@gmail.com> wrote:
>
> A process will emerge but I find it important that a committer should actually *mean* something.
>
> It does and should mean extra rights and extra responsibilities.
>
>
>
> --emi
>
> Pe 27 feb. 2017, la 16:43, Geertjan Wielenga <ge...@googlemail.com> a scris:
>
>> That's true. Good point.
>>
>> Still, we'll need some kind of process, i.e., a staging process as well as
>> test specifications for those who'll be testing new releases etc.
>>
>> Gj
>>
>> On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
>> wrote:
>>
>>>> I fear a future where everyone can simply put anything
>>> into NetBeans in Apache without any kind of intermediate or staging
>>> process.
>>>
>>> Not everybody will be an Apache committer and that's why we have a vote
>>> for it.
>>>
>>> --emi
>>>
>>> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
>>> geertjan.wielenga@googlemail.com> a scris:
>>>
>>>> I fear a future where everyone can simply put anything
>>>> into NetBeans in Apache without any kind of intermediate or staging
>>> process.
>>>
Re: Code contribution process.
Posted by Emilian Bold <em...@gmail.com>.
A process will emerge but I find it important that a committer should actually *mean* something.
It does and should mean extra rights and extra responsibilities.
--emi
Pe 27 feb. 2017, la 16:43, Geertjan Wielenga <ge...@googlemail.com> a scris:
> That's true. Good point.
>
> Still, we'll need some kind of process, i.e., a staging process as well as
> test specifications for those who'll be testing new releases etc.
>
> Gj
>
> On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
> wrote:
>
>>> I fear a future where everyone can simply put anything
>> into NetBeans in Apache without any kind of intermediate or staging
>> process.
>>
>> Not everybody will be an Apache committer and that's why we have a vote
>> for it.
>>
>> --emi
>>
>> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
>> geertjan.wielenga@googlemail.com> a scris:
>>
>>> I fear a future where everyone can simply put anything
>>> into NetBeans in Apache without any kind of intermediate or staging
>> process.
>>
Re: Code contribution process.
Posted by Glenn Holmer <ce...@kolabnow.com>.
On 02/27/2017 08:43 AM, Geertjan Wielenga wrote:
> Still, we'll need some kind of process, i.e., a staging process as well as
> test specifications for those who'll be testing new releases etc.
Will there still be something like NetCAT for major releases?
--
Glenn Holmer (Linux registered user #16682)
"After the vintage season came the aftermath -- and Cenbe."
Re: Code contribution process.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
That's true. Good point.
Still, we'll need some kind of process, i.e., a staging process as well as
test specifications for those who'll be testing new releases etc.
Gj
On Mon, Feb 27, 2017 at 3:41 PM, Emilian Bold <em...@gmail.com>
wrote:
> > I fear a future where everyone can simply put anything
> into NetBeans in Apache without any kind of intermediate or staging
> process.
>
> Not everybody will be an Apache committer and that's why we have a vote
> for it.
>
> --emi
>
> Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <
> geertjan.wielenga@googlemail.com> a scris:
>
> > I fear a future where everyone can simply put anything
> > into NetBeans in Apache without any kind of intermediate or staging
> process.
>
Re: Code contribution process.
Posted by Emilian Bold <em...@gmail.com>.
> I fear a future where everyone can simply put anything
into NetBeans in Apache without any kind of intermediate or staging process.
Not everybody will be an Apache committer and that's why we have a vote for it.
--emi
Pe 27 feb. 2017, la 16:08, Geertjan Wielenga <ge...@googlemail.com> a scris:
> I fear a future where everyone can simply put anything
> into NetBeans in Apache without any kind of intermediate or staging process.
Re: Code contribution process.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
We also need to figure out a way to do some kind of code quality checks and
tests and so on -- I fear a future where everyone can simply put anything
into NetBeans in Apache without any kind of intermediate or staging process.
Gj
On Mon, Feb 27, 2017 at 3:07 PM, Geertjan Wielenga <
geertjan.wielenga@googlemail.com> wrote:
> Best to wait until the code has moved from Oracle to Apache and to use the
> official repository once it is set up.
>
> Gj
>
> On Mon, Feb 27, 2017 at 2:48 PM, Christian Lenz <Ch...@gmx.net>
> wrote:
>
>> I know there is long way to go to bring NetBeans to apache, but a lot of
>> people signed such CLAs and atm, I contribute directly to the code via Pull
>> Requests to the netbeans-releases repo of Emilian Bold. He is the only one
>> atm, to accept such pull requests. So tell me, how can we improve this
>> task? I have a lot of feature branches and I can finished some of them soon
>> and will start with new one. How can I contribute directly to the code or
>> how is the best way? Because of emilian is the only one who can accept pull
>> requests, this is kind of bottle neck.
>>
>>
>> Regards
>>
>> Chris
>>
>
>
Re: Code contribution process.
Posted by Geertjan Wielenga <ge...@googlemail.com>.
Best to wait until the code has moved from Oracle to Apache and to use the
official repository once it is set up.
Gj
On Mon, Feb 27, 2017 at 2:48 PM, Christian Lenz <Ch...@gmx.net>
wrote:
> I know there is long way to go to bring NetBeans to apache, but a lot of
> people signed such CLAs and atm, I contribute directly to the code via Pull
> Requests to the netbeans-releases repo of Emilian Bold. He is the only one
> atm, to accept such pull requests. So tell me, how can we improve this
> task? I have a lot of feature branches and I can finished some of them soon
> and will start with new one. How can I contribute directly to the code or
> how is the best way? Because of emilian is the only one who can accept pull
> requests, this is kind of bottle neck.
>
>
> Regards
>
> Chris
>
Re: Code contribution process.
Posted by Wade Chandler <wa...@apache.org>.
A PR can be very specific to one specific feature or fix; features and fixes can sometimes be fairly small. It could also be specific to a single facet of a larger feature or fix such as setting up some base library or adding some new and dependent API or SPI, or some set of changes which can be isolated and tested. How the granularity gets broken up as well as documentation to go along with that granularity, say as a small subset of a larger plan, can help chew off smaller pieces in clearer contexts. So there are some nuanced ways of handling and presenting granularity to aid human issues of flow and complexity of a code review considering an open source projects workers are often also quite focused on other work, employment, and life:
https://en.wikipedia.org/wiki/Flow_(psychology) <https://en.wikipedia.org/wiki/Flow_(psychology)>
https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/ <https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/>
Wade
> On Feb 27, 2017, at 10:09, Christian Lenz <Ch...@gmx.net> wrote:
>
> Hey Emi,
>
> no problem and thx for the info. I know such PR with a lots of commits is not that easy. The PR gets bigger and bigger the more I commit and pushed to my forked repo.
> This is normal work, if we working as real contributors, I think. I will have a look whether I can create a patch with my stuff which I already commited and pushed. Thx.
>
>
> Regards
>
> Chris
>
>> Gesendet: Montag, 27. Februar 2017 um 15:57 Uhr
>> Von: "Emilian Bold" <em...@gmail.com>
>> An: dev@netbeans.incubator.apache.org
>> Betreff: Re: Code contribution process.
>>
>> Hello Chris,
>>
>> I was busy with a site I'm releasing these days but I should be good after that.
>>
>> Generally the smaller the patch the easier to review and tweak.
>>
>> I know I briefly looked at your PR but it seemed big so I postponed it.
>>
>> Of course, this won't be such a problem anymore after we have the code in Apache.
>>
>> --emi
>>
>> Pe 27 feb. 2017, la 15:48, Christian Lenz <Ch...@gmx.net> a scris:
>>
>>> I know there is long way to go to bring NetBeans to apache, but a lot of people signed such CLAs and atm, I contribute directly to the code via Pull Requests to the netbeans-releases repo of Emilian Bold. He is the only one atm, to accept such pull requests. So tell me, how can we improve this task? I have a lot of feature branches and I can finished some of them soon and will start with new one. How can I contribute directly to the code or how is the best way? Because of emilian is the only one who can accept pull requests, this is kind of bottle neck.
>>>
>>>
>>> Regards
>>>
>>> Chris
>>
Aw: Re: Code contribution process.
Posted by Christian Lenz <Ch...@gmx.net>.
Hey Emi,
no problem and thx for the info. I know such PR with a lots of commits is not that easy. The PR gets bigger and bigger the more I commit and pushed to my forked repo.
This is normal work, if we working as real contributors, I think. I will have a look whether I can create a patch with my stuff which I already commited and pushed. Thx.
Regards
Chris
> Gesendet: Montag, 27. Februar 2017 um 15:57 Uhr
> Von: "Emilian Bold" <em...@gmail.com>
> An: dev@netbeans.incubator.apache.org
> Betreff: Re: Code contribution process.
>
> Hello Chris,
>
> I was busy with a site I'm releasing these days but I should be good after that.
>
> Generally the smaller the patch the easier to review and tweak.
>
> I know I briefly looked at your PR but it seemed big so I postponed it.
>
> Of course, this won't be such a problem anymore after we have the code in Apache.
>
> --emi
>
> Pe 27 feb. 2017, la 15:48, Christian Lenz <Ch...@gmx.net> a scris:
>
> > I know there is long way to go to bring NetBeans to apache, but a lot of people signed such CLAs and atm, I contribute directly to the code via Pull Requests to the netbeans-releases repo of Emilian Bold. He is the only one atm, to accept such pull requests. So tell me, how can we improve this task? I have a lot of feature branches and I can finished some of them soon and will start with new one. How can I contribute directly to the code or how is the best way? Because of emilian is the only one who can accept pull requests, this is kind of bottle neck.
> >
> >
> > Regards
> >
> > Chris
>
Re: Code contribution process.
Posted by Emilian Bold <em...@gmail.com>.
Hello Chris,
I was busy with a site I'm releasing these days but I should be good after that.
Generally the smaller the patch the easier to review and tweak.
I know I briefly looked at your PR but it seemed big so I postponed it.
Of course, this won't be such a problem anymore after we have the code in Apache.
--emi
Pe 27 feb. 2017, la 15:48, Christian Lenz <Ch...@gmx.net> a scris:
> I know there is long way to go to bring NetBeans to apache, but a lot of people signed such CLAs and atm, I contribute directly to the code via Pull Requests to the netbeans-releases repo of Emilian Bold. He is the only one atm, to accept such pull requests. So tell me, how can we improve this task? I have a lot of feature branches and I can finished some of them soon and will start with new one. How can I contribute directly to the code or how is the best way? Because of emilian is the only one who can accept pull requests, this is kind of bottle neck.
>
>
> Regards
>
> Chris