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:+1
Hi, We are looking for a better workflow and tools for making andThat is good.
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
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
(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.)
Why change "RFC"? Isn't this the commonly used term?
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).
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