+1 to use wiki like Cassandra project.
--
Regards,
Salar Rahmanian
email: [email protected]
On 11/3/22 1:30 AM, Claude Warren, Jr wrote:
We do have a wiki. The Cassandra project has CEPs created in the Cassandra
wiki [1]. This keeps long documents out of the email list and provides a
single Apache controlled space to record the permanent documents. I think
we should make use of the pekko wiki to document all processes and PIPs as
well as provide other information that users/developers may want.
[1]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=95652201
On Thu, Nov 3, 2022 at 1:47 AM Greg Methvin <[email protected]> wrote:
+1 on all these suggestions.
We also have to decide on the details of how PIP should work. My rough idea
is:
1. Create a PIP ticket on GitHub using a predefined PIP template.
2. Start a discussion on the mailing list referencing the ticket.
3. Once a consensus is reached, perform a vote using the Apache voting
process.
4. If the PIP passes, the author and other contributors create PRs
referencing the original PIP ticket on GitHub. Code review follows the
normal code review process.
I'm thinking we probably should have an entirely separate PIP section in
our process doc?
On Wed, Nov 2, 2022 at 7:05 AM Claude Warren, Jr
<[email protected]> wrote:
I suggest changing "Examples of such issues include:" to "Examples of
such
issues include, but are not limited to:"
On Wed, Nov 2, 2022 at 1:46 PM Matthew Benedict de Detrich
<[email protected]> wrote:
New point 3 (pushing down existing point 3 to 4, etc.)
3. For major/breaking changes, we require that a Pekko Improvement
Process (PIP) proposal is submitted on the dev mailing list before a
PR is made. After allowing some time for discussion, a vote will be
required on the dev mailing list using the code modifications process
documented in the Apache voting process document. When we have general
agreement on the proposal, we can proceed to submitting PRs. Examples
of such issues include:
a. new Pekko features/libraries
b. changes to public APIs
c. significant upgrades to jar dependencies
d. changes to wire protocol
e. large changes across many Pekko components
My suggestion would be to further equivocate this so that its more
accurate. For example, for both the contributors and users of Akka (and
now
Pekko), breaking binary compatibility is something that was checked
with
sbt-mima (see https://github.com/lightbend/mima). Furthermore,
forwards
breaking changes that weren’t major was actually allowed in with just a
standard basic review (which also involved putting in ProblemFilters
into
sbt-mima, see the currently existing mina-filters folders). Such
changes
were also sometimes put behind the @ApiMayChange annotation if there
was
a
chance that the API may change future because but the merits of adding
in
the change outweighed perfect stability, this was quite a common
occurrence
in fast moving modules such as akka (and now pekko) streams
There is also another @InternalApi annotation whereby you can break
anything you want and is only meant for internal use.
It would be good to also add these details into the process document. I
think there is a lot of merit in being quite precise here for what
requires
a Pekko Improvement Proposal because we can run the risk of making it
to
budersome to contribute to Pekko if the keep on throwing the “this
needs
a
Pekko Improvement Proposal” due to unclear rules.
--
Matthew de Detrich
Aiven Deutschland GmbH
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
m: +491603708037
w: aiven.io e: [email protected]
On 2. Nov 2022, 14:34 +0100, PJ Fanning <[email protected]>, wrote:
Can I suggest these amendments to
https://cwiki.apache.org/confluence/display/PEKKO/Processes ? I'm
happy for any of these proposed changes to be adjusted or discussed
further.
Change
1. Defects are recorded in the git issue for the associated Pekko
module.
to
1. Defects are recorded in the Github issue tracker for the
associated
Pekko module.
New point 3 (pushing down existing point 3 to 4, etc.)
3. For major/breaking changes, we require that a Pekko Improvement
Process (PIP) proposal is submitted on the dev mailing list before a
PR is made. After allowing some time for discussion, a vote will be
required on the dev mailing list using the code modifications process
documented in the Apache voting process document. When we have
general
agreement on the proposal, we can proceed to submitting PRs. Examples
of such issues include:
a. new Pekko features/libraries
b. changes to public APIs
c. significant upgrades to jar dependencies
d. changes to wire protocol
e. large changes across many Pekko components
Change 3c (which becomes 4c because of new point 3 above)
c. if a Pekko committer requests that the PR changes should be
discussed more widely, the changes should be discussed on the dev
mailing list and voted on using the code modifications process
documented in the Apache voting process document.
Change 5c (which becomes 6c because of new point 3 above)
c. if a Pekko committer requests that the PR changes should be
discussed more widely, the changes should be discussed on the dev
mailing list and voted on using the code modifications process
documented in the Apache voting process document.
On Thu, 27 Oct 2022 at 09:55, Claude Warren, Jr
<[email protected]> wrote:
One of the first things this team needs to do is to decide how
development
will be done. I have drafted a process document to kick this
discussion
off.
The draft document is found at
https://cwiki.apache.org/confluence/display/PEKKO/Processes
For purposes of this discussion:
1. No changes will be made until a code modification vote is taken.
See
https://www.apache.org/foundation/voting.html for requirements.
For
those of you who have edit access to the document please do not
change
it
until we have a vote.
2. Committers and Mentors have binding votes. All other votes are
advisory.
3. Discussions of proposed changes must be posted to the
[email protected] mailing list and the subject should be
prefixed
with "[DISCUSS]".
4. Calls for votes on the proposed changes must be made on the
[email protected] mailing list and the subject should be
prefixed
with "[VOTE]" to make it easy to identify.
5. Results of votes will be published on the dev mailing list with
"[RESULT]" prefixing the subject.
6. A vote to accept the document may be taken once all proposed
changes
are voted on.
7. A vote to accept the document will close all discussion under
the
process documented in this email
8. Once the document is accepted any subsequent changes will be
performed as specified in the accepted process document.
The purpose of this exercise is to arrive at a consensus for how
this
project will operate within the guidelines and requirements of the
Apache
organization.
Thanks for participating,
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Regards,
Salar Rahmanian
email: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
