Patch was also attached to GCI site. It worked from there. Not sure what happened. But it is pushed now and GCI task closed.
Thanks --joel On Sat, Dec 1, 2018 at 10:34 AM Joel Sherrill <j...@rtems.org> wrote: > I think you need to submit this using "git format-patch". > > Do your work on a branch and submit the patches on that branch. > Something like: > > git checkout master > git checkout -b am > git add FILES > git commit # pops up an editor to write message > > git format-patch -o am master > # puts patch in direcctory am, send that. > > Email the patch. git has a lot of features. The above it a very minimal > subset and not a complete workflow. > > --joel > > On Sat, Dec 1, 2018 at 10:30 AM Marçal Comajoan Cara < > mcomajoanc...@gmail.com> wrote: > >> Convert text to a table, TBDs into comments and add missing >> formatting. >> >> This work was part of GCI 2018. >> --- >> eng/appendix-a.rst | 152 +++++++++++++++++++++++++++++++-------------- >> 1 file changed, 104 insertions(+), 48 deletions(-) >> >> diff --git a/eng/appendix-a.rst b/eng/appendix-a.rst >> index 633996b..cfad927 100644 >> --- a/eng/appendix-a.rst >> +++ b/eng/appendix-a.rst >> @@ -8,7 +8,7 @@ Appendix: Core Qualification Artifacts/Documents >> ************************************************ >> >> An effort at NASA has been performed to suggest a core set of artifacts >> -(as defined by BOTH NASA NPR 7150.2B and DO-178B) that can be utilized >> +(as defined by **BOTH** NASA NPR 7150.2B and DO-178B) that can be >> utilized >> by a mission as a baselined starting point for “pre-qualification” >> for (open-source) software that is intended to be utilized for flight >> purposes. This effort analyzed the overlap between NPR 7150.2B >> @@ -20,60 +20,116 @@ Along with the specific artifact, the intent of the >> artifact was also >> captured; in some cases open-source projects, such as RTEMS, are already >> meeting the intent of the artifacts with information simply needing >> organized and formalized. The table below lists the general category, >> -artifact name, and its intent. Please note that this table does NOT >> +artifact name, and its intent. Please note that this table does **NOT** >> represent all the required artifacts for qualification per the standards; >> instead, this table represents a subset of the most basic/core artifacts >> that form a strong foundation for a software engineering qualification >> effort. >> >> -TBD convert to a table; see original PDF for guidance on desired look >> -TBD The PDF is in https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/ >> +.. COMMENT: TBD convert to a table; see original PDF for guidance on >> desired look >> +.. COMMENT: TBD The PDF is in >> https://ftp.rtems.org/pub/rtems/people/joel/sw_eng_hb/ >> >> -.. COMMENT: ====================================== BEGIN >> -Table 1. Core Qualification Artifacts >> +.. table:: Table 1. Core Qualification Artifacts >> + :class: rtems-table >> >> -Category Artifact Intent >> -Requirements Software Requirements Specification (SRS) >> - >> -Requirements Management The project shall document the software >> requirements. >> - >> -The project shall collect and manage changes to the software >> requirements. >> - >> -The project shall identify, initiate corrective actions, and track until >> closure inconsistencies among requirements, project plans, and software >> products. >> - Requirements Test and Traceability Matrix The project shall >> perform, document, and maintain bidirectional traceability between the >> software requirement and the higher-level requirement. >> - Validation The project shall perform requirements validation >> to ensure that the software will perform as intended in the customer >> environment. >> - >> - >> -Design and Implementation Software Development or Management Plan A >> plan for how you will develop the software that you are intent upon >> developing and delivering. >> - >> -The Software Development Plan includes the objectives, standards and >> life cycle(s) to be used in the software development process. This plan >> should include: Standards: Identification of the Software Requirements >> Standards, Software Design Standards, and Software Code Standards for the >> project. >> - >> - Software Configuration Management Plan To identify and control >> major software changes, ensure that change is being properly implemented, >> and report changes to any other personnel or clients who may have an >> interest. >> - >> - Implementation The project shall implement the software design >> into software code. >> - >> -Executable Code to applicable tested software. >> - >> - Coding Standards Report The project shall ensure that software >> coding methods, standards, and/or criteria are adhered to and verified. >> - Version Description Document (VDD) The project shall provide >> a Software Version Description document for each software release. >> - >> -Testing and Software Assurance Activities Software Test Plan >> Document describing the testing scope and activities. >> - Software Assurance/Testing Procedures >> - To define the techniques, procedures, and methodologies that will >> be used. >> - >> - Software Change Report / Problem Report The project shall >> regularly hold reviews of software activities, status, and results with the >> project stakeholders and track issues to resolution. >> - >> - Software Schedule Milestones have schedule and schedule is >> updated accordingly. >> - >> - Software Test Report / Verification Results The project shall >> record, address, and track to closure the results of software verification >> activities. >> - >> -Problem report - Describes the process non-compliance with plans, output >> deficiency, or software anomalous behavior, and the corrective action taken. >> - >> -The project shall ensure that the software code is unit tested per the >> plans for software testing. >> - >> - >> -Usability Software User’s Manual The Software User Manual defines >> user instructions for the software. >> -.. COMMENT: ====================================== END >> + >> +----------------+-----------------------+---------------------------------+ >> + | Category | Artifact | Intent >> | >> + >> +================+=======================+=================================+ >> + | Requirements | Software Requirements | The project shall document >> the | >> + | | Specification (SRS) | software requirements. >> | >> + | | | >> | >> + | | | The project shall collect >> and | >> + | | | manage changes to the >> software | >> + | | | requirements. >> | >> + | | Requirements | >> | >> + | | Management | The project shall >> identify, | >> + | | | initiate corrective >> actions, | >> + | | | and track until closure >> | >> + | | | inconsistencies among >> | >> + | | | requirements, project >> plans, | >> + | | | and software products. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Requirements Test and | The project shall >> perform, | >> + | | Traceability Matrix | document, and maintain >> | >> + | | | bidirectional >> traceability | >> + | | | between the software >> | >> + | | | requirement and the >> | >> + | | | higher-level requirement. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Validation | The project shall perform >> | >> + | | | validation to ensure that >> the | >> + | | | software will perform as >> | >> + | | | intended in the customer >> | >> + | | | environment. >> | >> + >> +----------------+-----------------------+---------------------------------+ >> + | Design and | Software Development | A plan for how you will >> develop | >> + | Implementation | or Management Plan | the software that you are >> | >> + | | | intent upon developing >> and | >> + | | | delivering. >> | >> + | | | >> | >> + | | | The Software Development >> Plan | >> + | | | includes the objectives, >> | >> + | | | standards and life >> cycle(s) to | >> + | | | be used in the software >> | >> + | | | development process. This >> plan | >> + | | | should include: >> Standards: | >> + | | | Identification of the >> Software | >> + | | | Requirements Standards, >> | >> + | | | Software Design >> Standards, | >> + | | | and Software Code >> Standards for | >> + | | | the project. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Software | To identify and control >> major | >> + | | Configuration | software changes, ensure >> that | >> + | | Management Plan | change is being properly >> | >> + | | | implemented, and report >> changes | >> + | | | to any other personnel or >> | >> + | | | clients who may have an >> | >> + | | | interest. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Implementation | The project shall >> implement the | >> + | | | software design into >> software | >> + | | | code. >> | >> + | | | >> | >> + | | | Executable Code to >> applicable | >> + | | | tested software. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Coding Standards | The project shall ensure >> that | >> + | | Report | software coding methods, >> | >> + | | | standards, and/or criteria >> are | >> + | | | adhered to and verified. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Version Description | The project shall provide >> a | >> + | | Document (VDD) | Software Version >> Description | >> + | | | document for each >> software | >> + | | | release. >> | >> + >> +----------------+-----------------------+---------------------------------+ >> + | Testing and | Software Test Plan | Document describing the >> testing | >> + | Software | | scope and activities. >> | >> + | Assurance >> +-----------------------+---------------------------------+ >> + | Activities | Software | To define the techniques, >> | >> + | | Assurance/Testing | procedures, and >> methodologies | >> + | | Procedures | that will be used. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Software Change | The project shall >> regularly | >> + | | Report / Problem | hold reviews of software >> | >> + | | Report | activities, status, and >> results | >> + | | | with the project >> stakeholders | >> + | | | and track issues to >> resolution. | >> + | >> +-----------------------+---------------------------------+ >> + | | Software Schedule | Milestones have schedule >> and | >> + | | | schedule is updated >> | >> + | | | accordingly. >> | >> + | >> +-----------------------+---------------------------------+ >> + | | Software Test | The project shall record, >> | >> + | | Report / Verification | address, and track to >> closure | >> + | | Results | the results of software >> | >> + | | | verification activities. >> | >> + >> +----------------+-----------------------+---------------------------------+ >> + | Usability | Software User’s | The Software User Manual >> | >> + | | Manual | defines user instructions >> for | >> + | | | the software. >> | >> + >> +----------------+-----------------------+---------------------------------+ >> >> In an effort to remain lightweight and sustainable for open-source >> projects, Table 1 above was condensed into a single artifact outline >> -- >> 2.17.1 >> >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
