Zephyr Enhancement Proposals


Nashif, Anas
 

Hi,
We are looking for a better workflow and tools for making and maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to the mailing list with their enhancement proposal. The mailing list is perfect for discussion of any proposals or issues, however we are looking for a more formal location for submitting and tracking proposal changes. The idea is that we continue to discuss any proposals on the mailing list, however, any incremental changes up to adoption will need to be submitted and maintained in version control system and later made available on the web site or some other form.

A few notes:
- To get to the above, we will create a gerrit project dedicated for proposals
- Proposals will be submitted using the RST documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would be mandatory, some will be optional
- Every proposal will need to have a matching JIRA item submitted as a story with a brief description
- Proposals will be maintained in GIT and will be categorised based on state, i.e. adopted, rejected, deferred, pending…
- The link between the proposal in git, JIRA and later the submitted code implementing a proposal has to always be established and maintained.


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on the mailing list, Personally I prefer to call those *proposals* or *blueprints* or *enhancements* (and the git tree containing them would carry this name as well).


Anas


Iván Briano <ivan.briano at intel.com...>
 

On Thu, 05 May 2016 15:21:11 +0000, Nashif, Anas wrote:
Hi,
We are looking for a better workflow and tools for making and maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to the mailing list with their enhancement proposal. The mailing list is perfect for discussion of any proposals or issues, however we are looking for a more formal location for submitting and tracking proposal changes. The idea is that we continue to discuss any proposals on the mailing list, however, any incremental changes up to adoption will need to be submitted and maintained in version control system and later made available on the web site or some other form.

A few notes:
- To get to the above, we will create a gerrit project dedicated for proposals
- Proposals will be submitted using the RST documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would be mandatory, some will be optional
- Every proposal will need to have a matching JIRA item submitted as a story with a brief description
- Proposals will be maintained in GIT and will be categorised based on state, i.e. adopted, rejected, deferred, pending…
- The link between the proposal in git, JIRA and later the submitted code implementing a proposal has to always be established and maintained.


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on the mailing list, Personally I prefer to call those *proposals* or *blueprints* or *enhancements* (and the git tree containing them would carry this name as well).
Of those three, I prefer 'proposals'. Enhancement doesn't feel
appropriate when you add something entirely new, and blueprints could be
better used for something involving board diagrams and the such.
And for once I will refrain myself from suggesting some idiotic
alternative name.



Anas


Flavio Santes <flavio.santes@...>
 

I also second "proposals".


Vinicius Costa Gomes
 

Hi Anas,

"Nashif, Anas" <anas.nashif(a)intel.com> writes:

Hi,
We are looking for a better workflow and tools for making and maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to the mailing list with their enhancement proposal. The mailing list is perfect for discussion of any proposals or issues, however we are looking for a more formal location for submitting and tracking proposal changes. The idea is that we continue to discuss any proposals on the mailing list, however, any incremental changes up to adoption will need to be submitted and maintained in version control system and later made available on the web site or some other form.

A few notes:
- To get to the above, we will create a gerrit project dedicated for proposals
- Proposals will be submitted using the RST documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would be mandatory, some will be optional
- Every proposal will need to have a matching JIRA item submitted as a story with a brief description
- Proposals will be maintained in GIT and will be categorised based on state, i.e. adopted, rejected, deferred, pending…
- The link between the proposal in git, JIRA and later the submitted code implementing a proposal has to always be established and maintained.
+1

Just for reference the Rust[1] project has a similar concept, and it's
been working for some time, it may give a few ideas:

https://github.com/rust-lang/rfcs


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on the
mailing list, Personally I prefer to call those *proposals* or
*blueprints* or *enhancements* (and the git tree containing them would
carry this name as well).


Anas

Cheers,
--
Vinicius

[1] https://www.rust-lang.org/


Thomas, Ramesh
 

On Thu, 2016-05-05 at 15:21 +0000, Nashif, Anas wrote:
Hi,
We are looking for a better workflow and tools for making and maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to the mailing list with their enhancement proposal. The mailing list is perfect for discussion of any proposals or issues, however we are looking for a more formal location for submitting and tracking proposal changes. The idea is that we continue to discuss any proposals on the mailing list, however, any incremental changes up to adoption will need to be submitted and maintained in version control system and later made available on the web site or some other form.

A few notes:
- To get to the above, we will create a gerrit project dedicated for proposals
- Proposals will be submitted using the RST documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would be mandatory, some will be optional
- Every proposal will need to have a matching JIRA item submitted as a story with a brief description
- Proposals will be maintained in GIT and will be categorised based on state, i.e. adopted, rejected, deferred, pending…
- The link between the proposal in git, JIRA and later the submitted code implementing a proposal has to always be established and maintained.
That is good.

(Note - since RFC will be readily accessible now, question of how much
it should stay in sync with deviations during actual
implementation/review would be a question to answer later.)


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on the mailing list, Personally I prefer to call those *proposals* or *blueprints* or *enhancements* (and the git tree containing them would carry this name as well).
Why change "RFC"? Isn't this the commonly used term?

"Proposal" with more descriptive terms would be good. "ZEP" is already
taken by Jira, else that could have been used.

"Zephyr Change Proposal (ZCP)", "Code Change Proposal (CCP)", "Proposal
For Enhancement (PFE)", "Proposal For Change (PFC)"...



Anas


Benjamin Walsh <benjamin.walsh@...>
 

On Thu, May 05, 2016 at 07:50:39PM +0000, Thomas, Ramesh wrote:
On Thu, 2016-05-05 at 15:21 +0000, Nashif, Anas wrote:
Hi, We are looking for a better workflow and tools for making and
maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to
the mailing list with their enhancement proposal. The mailing list
is perfect for discussion of any proposals or issues, however we are
looking for a more formal location for submitting and tracking
proposal changes. The idea is that we continue to discuss any
proposals on the mailing list, however, any incremental changes up
to adoption will need to be submitted and maintained in version
control system and later made available on the web site or some
other form.

A few notes: - To get to the above, we will create a gerrit project
dedicated for proposals - Proposals will be submitted using the RST
documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would
be mandatory, some will be optional - Every proposal will need to
have a matching JIRA item submitted as a story with a brief
description - Proposals will be maintained in GIT and will be
categorised based on state, i.e. adopted, rejected, deferred,
pending… - The link between the proposal in git, JIRA and later the
submitted code implementing a proposal has to always be established
and maintained.
That is good.

(Note - since RFC will be readily accessible now, question of how much
it should stay in sync with deviations during actual
implementation/review would be a question to answer later.)


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on
the mailing list, Personally I prefer to call those *proposals* or
*blueprints* or *enhancements* (and the git tree containing them
would carry this name as well).
Why change "RFC"? Isn't this the commonly used term?
+1

I don't really mind any of these names, except I don't like
enhancements, which has the connotation of "a Jira issue we will never
fix" for me. And a new feature is not necessarily an "enhancement".

"proposal" sounds good too. "blueprint" is cute.

"Proposal" with more descriptive terms would be good. "ZEP" is
already taken by Jira, else that could have been used.

"Zephyr Change Proposal (ZCP)", "Code Change Proposal (CCP)",
"Proposal For Enhancement (PFE)", "Proposal For Change (PFC)"...


Thomas, Ramesh
 

On Thu, 2016-05-05 at 16:24 -0400, Benjamin Walsh wrote:
On Thu, May 05, 2016 at 07:50:39PM +0000, Thomas, Ramesh wrote:
On Thu, 2016-05-05 at 15:21 +0000, Nashif, Anas wrote:
Hi, We are looking for a better workflow and tools for making and
maintaining enhancement proposals for Zephyr.

Currently contributors and developers are asked to send an email to
the mailing list with their enhancement proposal. The mailing list
is perfect for discussion of any proposals or issues, however we are
looking for a more formal location for submitting and tracking
proposal changes. The idea is that we continue to discuss any
proposals on the mailing list, however, any incremental changes up
to adoption will need to be submitted and maintained in version
control system and later made available on the web site or some
other form.

A few notes: - To get to the above, we will create a gerrit project
dedicated for proposals - Proposals will be submitted using the RST
documentation syntax, the same format we also use for documentation
- Proposals will follow a template and sections some of which would
be mandatory, some will be optional - Every proposal will need to
have a matching JIRA item submitted as a story with a brief
description - Proposals will be maintained in GIT and will be
categorised based on state, i.e. adopted, rejected, deferred,
pending… - The link between the proposal in git, JIRA and later the
submitted code implementing a proposal has to always be established
and maintained.
That is good.

(Note - since RFC will be readily accessible now, question of how much
it should stay in sync with deviations during actual
implementation/review would be a question to answer later.)


Feedback and comments welcome.

P.S: We need to give the process a name. We have been using RFC on
the mailing list, Personally I prefer to call those *proposals* or
*blueprints* or *enhancements* (and the git tree containing them
would carry this name as well).
Why change "RFC"? Isn't this the commonly used term?
+1

I don't really mind any of these names, except I don't like
enhancements, which has the connotation of "a Jira issue we will never
fix" for me. And a new feature is not necessarily an "enhancement".

"proposal" sounds good too. "blueprint" is cute.

"Proposal" with more descriptive terms would be good. "ZEP" is
already taken by Jira, else that could have been used.

"Zephyr Change Proposal (ZCP)", "Code Change Proposal (CCP)",
"Proposal For Enhancement (PFE)", "Proposal For Change (PFC)"...
One useful feature would be a link to a pre-generated html or pdf so the
reviewer need not generate them - especially when one is reviewing
associated code.