Perfect.
Gj
On Mon, Feb 27, 2017 at 7:48 PM, Emilian Bold
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!
>
> 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 wrote:
> On Mon, F
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 m
Hi,
On 27 February 2017 at 18:03, Wade Chandler wrote:
> There are logging solutions to deal with that which we are discussing on
> Slack. Too, I think “key” conversations is the key ... we will bring
> important things to the list once we feel like we have something logical to
> say.
I wasn'
@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 abl
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
>
There are logging solutions to deal with that which we are discussing on Slack.
Too, I think “key” conversations is the key. A dynamic conversation between a
couple to a few people is exactly what we would do if at a conference too, and
we are not going to sit there emailing each other or the li
On 27 February 2017 at 16:02, Bertrand Delacretaz
wrote:
> My (own, unwritten) rule in Apache projects is to move things to the
> dev list as soon as they go beyond the level of a coffee machine
> discussion - and when they do, restart the discussions here stating
> what happened at the coffee mac
On Mon, Feb 27, 2017 at 5:48 PM, Emilian Bold 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 fo
> On Feb 27, 2017, at 11:48, Emilian Bold 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
> 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 com
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,
On Mon, Feb 27, 2017 at 5:06 PM, Wade Chandler wrote:
> ...It really started off with us discussing the way some code works, and then
> led to some other conversations, and now has led here...
That's great then!
I didn't follow the whole trail, just was under the impression that
things were hap
Isn’t that perhaps the way it has worked out in this case? I agree with the
base premise of what you are saying, but wondering how it would bubble up in a
different way. It really started off with us discussing the way some code
works, and then led to some other conversations, and now has led he
Hi,
On Mon, Feb 27, 2017 at 4:33 PM, someone wrote:
> ...(he) 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...
It would be great to bring such discussions here as soon as they
become "important".
My (own,
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
Hi all,
It was really great at DevNexus last week:
1. DevNexus donated a Silver Sponsorship to NetBeans, in support of our
move to Apache. Thanks again DevNexus!
2. As a result of the above, we had a booth, where we were able to engage
with a lot of NetBeans users. Most people stopping by the bo
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 gener
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 #
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
a scris:
> That's true. Good point.
>
> Still, we'll need some kind of proce
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
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
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
wrote:
> > I fear a future where everyone can simply put anything
> into NetBea
> 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
a scris:
> I fear a future w
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.wiele
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
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
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 t
27 matches
Mail list logo
