On Wed, Nov 1, 2017 at 5:49 PM, Jesse Glick wrote:
> On Wed, Nov 1, 2017 at 8:35 AM, Jan Lahoda wrote:
> > you propose to open the PR from the
> > personal fork and leave it open for moths or years so that the code is
> > "perpetually" submitted to the ASF and can (hopefully!) be used, while
> t
On Wed, Nov 1, 2017 at 8:35 AM, Jan Lahoda wrote:
> you propose to open the PR from the
> personal fork and leave it open for moths or years so that the code is
> "perpetually" submitted to the ASF and can (hopefully!) be used, while the
> actual development is still happening on a branch in a per
On Wed, Nov 1, 2017 at 12:49 PM, Neil C Smith wrote:
> On Wed, Nov 1, 2017 at 6:32 AM Jan Lahoda wrote:
>
> > -code provenance: when one opens a pull request against
> > apache/(incubating-)netbeans, then I think the code can be considered to
> be
> > submitted to ASF (per iCLA). Pushing a commi
On Wed, Nov 1, 2017 at 12:51 PM, Jesse Glick wrote:
> On Wed, Nov 1, 2017 at 2:31 AM, Jan Lahoda wrote:
> > when one opens a pull request against
> > apache/(incubating-)netbeans, then I think the code can be considered to
> be
> > submitted to ASF (per iCLA).
>
> IANAL but that sounds right.
>
On Wed, Nov 1, 2017 at 2:31 AM, Jan Lahoda wrote:
> when one opens a pull request against
> apache/(incubating-)netbeans, then I think the code can be considered to be
> submitted to ASF (per iCLA).
IANAL but that sounds right.
> for a long-running branch in a
> personal repository, if the autho
On Wed, Nov 1, 2017 at 6:32 AM Jan Lahoda wrote:
> -code provenance: when one opens a pull request against
> apache/(incubating-)netbeans, then I think the code can be considered to be
> submitted to ASF (per iCLA). Pushing a commit to a personal github
> repository does not feel that way. So, fo
Hi Jesse,
Thanks for the comments! A comment is inline.
On Wed, Nov 1, 2017 at 1:54 AM, Jesse Glick wrote:
> FWIW I have been working exclusively in GitHub for years now, and my
> advice is to have every change be a PR coming from a repository fork.
> Once you are accustomed to this workflow, i
FWIW I have been working exclusively in GitHub for years now, and my
advice is to have every change be a PR coming from a repository fork.
Once you are accustomed to this workflow, it is not onerous, and
provides a natural place to track discussion of changes and
relationships to other changes. It
Just adding 2 cents from a contributors point of view...
I might be staying the obvious, but to maximise Community involvement, you
probably want to build a baseline process around contributors rather than
committers. By definition the only way they can collaborate is via pull
requests (or patc
On Mon, Oct 23, 2017 at 3:23 PM, Ate Douma wrote:
> I'd like to provide some mentor guidance to this discussion.
>
Many thanks for these insights!
I think we all should read the below a few times, mainly from the
perspective of how to think about what we're doing at Apache and the way to
approa
On Sun, Oct 22, 2017 at 10:00 PM, Neil C Smith <
neilcsmith@googlemail.com> wrote:
> Hi,
>
> On Sat, 21 Oct 2017, 15:41 Jan Lahoda, wrote:
>
> >
> > I guess I could live with this (although it leaves it unclear how new
> > feature branches would be created), but it feels cumbersome to me and
I'd like to provide some mentor guidance to this discussion.
As an Apache project we need to ensure collaboration and provenance are
served and supported properly.
With that in mind, new feature development, and for that matter *all*
development should allow and enable collaboration by the whole
Hi,
On Sat, 21 Oct 2017, 15:41 Jan Lahoda, wrote:
>
> I guess I could live with this (although it leaves it unclear how new
> feature branches would be created), but it feels cumbersome to me and the
> advantages are not very clear to me. Why doing the pull request when there
> would be no need
Hi,
Am Sonntag, den 22.10.2017, 20:13 +0200 schrieb Geertjan Wielenga:
> I'm still in favor of keeping feature branches as branches off of the main
> repo, exactly the way you have it right now.
I agree. I don't see the benefit to host these feature branches outside
the main repository. So I'm in
I'm still in favor of keeping feature branches as branches off of the main
repo, exactly the way you have it right now.
Gj
On Sun, Oct 22, 2017 at 7:44 PM, Jan Lahoda wrote:
> Hi,
>
> Would there be any objections if I asked for a new repository,
> incubator-netbeans-prototypes, where any commi
Hi,
Would there be any objections if I asked for a new repository,
incubator-netbeans-prototypes, where any committer could create
development/feature branches and work on them without pull requests? That
would seem like a reasonable compromise, keeping the main repository clean,
keeping pull requ
On Sat, Oct 21, 2017 at 8:59 PM, Sven Reimers
wrote:
> Hi all..
>
> the important thing for me is what this branch is about and if we want to
> deliver any kind of release (and convenience binaries) for simple
> consumption. If we want to have those we need branches in the NetBeans ADD
> repo..
>
Hi all..
the important thing for me is what this branch is about and if we want to
deliver any kind of release (and convenience binaries) for simple
consumption. If we want to have those we need branches in the NetBeans ADD
repo..
-Sven
Am 21.10.2017 20:26 schrieb "Matthias Bläsing" :
Hey,
Am
My understanding is that Neil's proposal is to do the extensive work in ASF
repos, while your is to do extensive work outside of ASF repos. But maybe I
misunderstand something?
IANAL, but my understanding is that doing extensive work outside of ASF
repos can lead to trouble in the long term. For e
Hey,
Am Samstag, den 21.10.2017, 19:13 +0100 schrieb John McDonnell:
> If you or a group of developers are working on a feature then you can
> work on that branch there when the feature is ready to be merged into
> Netbeans then we keep the Netbeans ASF repo as clean as possible.
I disagree. For
"I guess I could live with this (although it leaves it unclear how new
feature branches would be created), but it feels cumbersome to me and the
advantages are not very clear to me. Why doing the pull request when there
would be no need to have a review from someone else? Overall, does not feel
lik
So, if I understand the proposal correctly the code would be in the ASF
repo, and the way it would get there would be:
-one would commit to a branch in their own GitHub fork
-then go to the GitHub UI, create a pull request from the private branch to
the feature branch on the ASF repo
-and since for
Hi,
On Sat, Oct 21, 2017 at 2:57 PM Geertjan Wielenga <
geertjan.wiele...@googlemail.com> wrote:
> I am in favor of feature branches being branches off of the master Apache
> NetBeans Git repo, that way one can clearly see which feature branches
> there are.
>
So am I! But that's not the same t
I am in favor of feature branches being branches off of the master Apache
NetBeans Git repo, that way one can clearly see which feature branches
there are.
If there's disagreement, this is something we could vote on.
Gj
On Sat, Oct 21, 2017 at 1:36 PM, Neil C Smith wrote:
> On Fri, Oct 20, 201
On Fri, Oct 20, 2017 at 10:50 PM Jan Lahoda wrote:
> I think the currently accepted practice is that we all do pull requests for
> changes that go to master.
>
> Committers doing pull requests for feature/development branches seems like
> an overkill to me. Such branches may often be niche, and i
To me, that is a TBD. But releasing from branches like amber(/patterns) is
one of the possible approaches, IMO.
Jan
On Fri, Oct 20, 2017 at 11:13 PM, Ciprian Ciubotariu
wrote:
> Would we also have netbeans releases from the amber branch?
>
> On 10/20/17 23:50, Jan Lahoda wrote:
> > For me, the
Would we also have netbeans releases from the amber branch?
On 10/20/17 23:50, Jan Lahoda wrote:
> For me, the main advantage of using the ASF repo is that the provenance of
> the code is clear. Having a long-lived branch on GitHub may cause issues if
> the code is merged into the mainline (I, of
For me, the main advantage of using the ASF repo is that the provenance of
the code is clear. Having a long-lived branch on GitHub may cause issues if
the code is merged into the mainline (I, of course, don't know if it will
happen with the code this e-mail is about). So if multiple people (can)
co
Fair enough, so but then you have people creating branches on the (for
lack of a better term) 'master' repository, without any checks and
balances... At least what we have now with PR's they can be easily
merged.
What is the proposed working solution? committers commit directly
against the ASF Ne
I think the Apache Way is to keep things as close to the Apache project as
possible, i.e, creating branches of Apache NetBeans is preferred over
forking (even though that’s what we’re doing with the IP clearance), so I
think Jan’s suggestion is in line with how it should be.
Gj
On Fri, 20 Oct 201
No objections, but it would make sense to create a fork on GitHub and
then create a branch on your own fork.
John
On 20 October 2017 at 19:16, Jan Lahoda wrote:
> Hi,
>
> I have a very crude sketch/prototype of support for pattern matching in
> Java (as currently prototyped in OpenJDK Amber
31 matches
Mail list logo
