[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cu-dev] Thoughts on how to manage PRs for new api features
|
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/104Everyone 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 AMSubject:
[EXTERNAL]
Re: [cu-dev] Thoughts on how to manage PRs for new api featuresSent
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