Hi,
there were no comments on this proposal so far and I’m wondering why
that is.
Do you think that the proposal is
a) obviously great or
b) obviously useless or
c) you didn’t have time to read it or
c) it needs some improvement or
d) it just adds overhead or
e) ...
Please let us know what you think about the proposal.
Cheers,
Till
On 21 Feb 2023, at 11:14, Ian Maxon wrote:
Hi everyone. On one of our quarterly reports to the ASF board we got
some
comments about how dev@ is a ghost town. It would be very hard to
discern
the direction of the project from it at this point. So, Mike, Till and
I
discussed and came up with something that hopefully should remedy that
and
breathe some life back into the list.
The general idea is to discuss major new features or improvements on
the
list, and to have a vote and some sort of PMC involvement with them.
That
way hopefully knowledge of them will be more distributed among all the
committers.
Please discuss the proposal. It's not set in stone of course, we can
change
things. This was mostly gleaned from similar processes in other
projects,
ASF and otherwise.
---------
Rationale
---------
AsterixDB, being a database system, is designed to be a user-facing
system,
but also to be a foundation for other applications. Therefore any
changes,
improvements, or alterations made can be of great consequence to those
dependent applications. Given this, these types of changes need to be
considered closely and clearly in public, to give the greatest insight
as
to what the consequences of them might be. Many of these processes
already
exist informally within the project, and this document is in part an
attempt to codify them.
------------------
When is it needed?
------------------
If the change is:
- adding a new feature
- changing the interface (internal or otherwise) of an existing
feature or
otherwise fundamentally modifying its behavior
- introducing any kind of potential backwards incompatibility to the
persistent artifacts produced by AsterixDB
---------------------------
Components and Requirements
---------------------------
An APE should consist of:
- A Confluence document describing the proposed design of the
enhancement,
it's risks and rewards, and possible alternatives (if applicable)
- A JIRA issue to track the improvement, linking to the aforementioned
document
- A designated PMC member (who can be the proposer) to shepherd the
enhancement
- A list of the Committers and Contributors who will work on the
enhancement
By default all APEs should go to the latest development branch, but if
it
is intended for an older stabilization branch this should be
explicitly
mentioned as it is an important consideration.
All of this information should be posted to [email protected]
in a
[DISCUSS] thread. After the discussion seems to come to a conclusion
of
some sort, then a [VOTE] should be issued and kept open for 72 hours.
The
vote is analogous to the process for releases.
