Re: [cu-dev] Thoughts on how to manage PRs for new api features

["Nathan Rauh" <nathan.rauh@xxxxxxxxxx>]

We can try this out
on https://github.com/eclipse-ee4j/concurrency-api/issues/40(Completion stage backed by ManagedExecutorService).  I had created
a pull for it back in 2019, copying the method signatures and JavaDoc from
MP Context Propagation 1.0, and it just needed a rebase onto master plus
copying over 2 more interface methods from MP Context Propagation 1.2's
ManagedExecutor, plus a few mentions in the spec doc and it should be ready
now for review by the community.

Here's a link
to the pull:
https://github.com/eclipse-ee4j/concurrency-api/pull/104

Everyone is welcome
to add themselves as reviewers/approvers and make comments. Let's see how
it goes.





From:
       "Nathan
Rauh" <nathan.rauh@xxxxxxxxxx>
To:
       cu
developer discussions <cu-dev@xxxxxxxxxxx>
Date:
       03/17/2021
10:54 AM
Subject:
       [EXTERNAL]
Re: [cu-dev] Thoughts on how to manage PRs for new api features
Sent
by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

I'd say let's try the simpler
approach first (create pull against master, discuss & vote, iterating
if needed, and merge after agreed upon) and if that is found to become
cumbersome at any point, then consider the other approach. From: 
I'd say let's try the simpler approach first (create pull against master,
discuss & vote, iterating if needed, and merge after agreed upon) and
if that is found to become cumbersome at any point, then consider the other
approach.




From:        "Steve
Millidge (Payara)" <steve.millidge@xxxxxxxxxxx>
To:        cu
developer discussions <cu-dev@xxxxxxxxxxx>
Date:        03/17/2021
10:45 AM
Subject:        [EXTERNAL]
[cu-dev] Thoughts on how to manage PRs for new api features
Sent by:        "cu-dev"
<cu-dev-bounces@xxxxxxxxxxx>

---

How do people feel we should manage feature development in the repo for
Jakarta EE 10? A couple of options from me. People make PRs to master for
api proposals? When agreed and voted on the PR we merge the PR? This could
become cumbersome with

How do people feel we should manage feature development in the repo for Jakarta EE 10?

 

A couple of options from me.

People make PRs to master for api proposals? When agreed and voted on the PR we merge the PR?

This could become cumbersome with a lot of comments on a single PR.

 

We create a feature branch, one per issue, and allow PRs and merge PRs to the feature branch. Then when we are happy with a feature create a final PR to master where people can vote?

 

Any other options?

 

Thanks

 

Steve_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev