ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maxim Muzafarov <maxmu...@gmail.com>
Subject [DISCUSSION] The process of creating an Ignite Enhancement Proposal
Date Wed, 07 Nov 2018 16:35:51 GMT

I think, our community have accumulated enough experience with the process of
Ignite Enhancement Proposal (IEP) of introducing the major changes
into the Apache
Ignite. Now we have to take one step forward and make every major change and\or
improvement clear not only for community developers but also for the
Apache Ignite
users too.

Currently, I've seen two different strategies with creating IEPs:
 - Single IEP per single major improvement;
 - Single IEP per unit of functionality (group a few major improvements);

Both of them have different advantages and disadvantages.

Let's remove the ambiguity and build a convenient working process. For example,
we may consider the best practices used in other open-source projects [2] [3].

I propose to (and also propose to update the corresponding wiki page [1] and our
community processes):
 - use to "Single IEP per single major improvement" approach;
 - do not group the major enhancements into the single IEP;
 - avoid inaccurate proposal names (e.g. optimization, improvement,
stabilization of etc.);
 - for any public API changes create the IEP;
 - add a `compatibility\mirgration` section to IEP Template;
 - add a `public API changes` section to the IEP Template;
 - link each major release note with the corresponding IEP page (users
will have a
   better understanding of each feature).

 Igniters, please, share your thoughts.

[1] https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Enhancement+Proposal
[2] https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals
[3] https://cwiki.apache.org/confluence/display/SAMZA/Samza+Enhancement+Proposal

View raw message