Re: [DISCUSS] AsterixDB Proposed Enhancements (APEs)

[Till Westmann <ti...@gmail.com>]

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 dev@asterixdb.apache.org 
> 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.

Re: [DISCUSS] AsterixDB Proposed Enhancements (APEs)

[Ian Maxon <im...@uci.edu>]

 That would be just fine. The proposal's acceptance doesn't mean it becomes
set in stone; we can modify it as we go.

On Mar 5, 2023 at 20:40:50, Ahmed Eldawy <el...@ucr.edu> wrote:

> I think the proposal is good but it might get some feedback when developers
> start adopting it.
>
> On Sun, Mar 5, 2023 at 8:00 PM Mike Carey <dt...@gmail.com> wrote:
>
> I’d say a)!  I think it can help a lot with info sharing across subprojects
>
> involving different components of the project.
>
>
> On Sun, Mar 5, 2023 at 7:36 PM Till Westmann <ti...@gmail.com>
>
> wrote:
>
>
> > 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 dev@asterixdb.apache.org
>
> > > 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.
>
> >
>
>
>

Re: [DISCUSS] AsterixDB Proposed Enhancements (APEs)

[Ahmed Eldawy <el...@ucr.edu>]

I think the proposal is good but it might get some feedback when developers
start adopting it.

On Sun, Mar 5, 2023 at 8:00 PM Mike Carey <dt...@gmail.com> wrote:

> I’d say a)!  I think it can help a lot with info sharing across subprojects
> involving different components of the project.
>
> On Sun, Mar 5, 2023 at 7:36 PM Till Westmann <ti...@gmail.com>
> wrote:
>
> > 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 dev@asterixdb.apache.org
> > > 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.
> >
>

Re: [DISCUSS] AsterixDB Proposed Enhancements (APEs)

[Mike Carey <dt...@gmail.com>]

I’d say a)!  I think it can help a lot with info sharing across subprojects
involving different components of the project.

On Sun, Mar 5, 2023 at 7:36 PM Till Westmann <ti...@gmail.com> wrote:

> 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 dev@asterixdb.apache.org
> > 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.
>