diff --git a/specs/graduation-template.rst b/specs/graduation-template.rst deleted file mode 100644 index a6c6a52..0000000 --- a/specs/graduation-template.rst +++ /dev/null @@ -1,178 +0,0 @@ -.. - This template should be in ReSTructured text. For help with syntax, - see http://sphinx-doc.org/rest.html - - To test out your formatting, build the docs using tox, or see: - http://rst.ninjs.org - - The filename in the git repository should match the launchpad URL, - for example a URL of - https://blueprints.launchpad.net/oslo?searchtext=awesome-thing should be - named awesome-thing.rst. - - Wrap text at 79 columns. - - Do not delete any of the sections in this template. If you have - nothing to say for a whole section, just write: None - - If you would like to provide a diagram with your spec, ascii diagrams are - required. http://asciiflow.com/ is a very nice tool to assist with making - ascii diagrams. The reason for this is that the tool used to review specs is - based purely on plain text. Plain text will allow review to proceed without - having to look at additional files which can not be viewed in gerrit. It - will also allow inline feedback on the diagram itself. - -============================= - Graduating X -============================= - -Include the URL of your launchpad blueprint: - -https://blueprints.launchpad.net/oslo?searchtext=graduate-example - -Provide a brief description of the focus of the new library. - -Library Name -============ - -What is the name of the new library?: - -Refer to -https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary#Choosing_a_Name -for the policies related to Oslo library names. - -Contents -======== - -List the files to be included in the new library, using their existing -incubator names. - -Early Adopters -============== - -List the projects that have agreed to participate as early adopters of -the new library. - -Public API -========== - -Describe the public API of the new library (modules and -functions). Include details about any functions in the modules now -that will be considered private, and that may need to move into a -private module to stay hidden. - -Implementation -============== - -Assignee(s) ------------ - -Who is handling the graduation work? - -If more than one person is working on the implementation, please -designate the primary author and contact. - -Primary assignee: - - -Other contributors: - - -Primary Maintainer ------------------- - -Each graduated library needs a primary maintainer. That may be the -same person who started the code, the person who graduated it, or it -may be someone who is taking over maintenance duties. - -If more than one person *who is not already on the oslo-core team* -intends to participate as a core reviewer for the new library, list -them under "Other Contributors". - -Primary Maintainer: - - -Other Contributors: - - -Security Contact ----------------- - -Each graduated library needs a contact for the OpenStack Vulnerability -Management team. It may be the same as the primary maintainer, an -existing Oslo team member who helps with security issues, or it may be -someone else on the development team for the new library. - -Talk with the Oslo and Vulnerability management teams about who the -person is, and make sure they agree to their participation before -proceeding. - -Security Contact: - - -Milestones ----------- - -Target Milestone for completion: - -Work Items ----------- - -Start with -https://wiki.openstack.org/wiki/Oslo/CreatingANewLibrary#Checklist and -add any additional steps necessary at the appropriate place in the -sequence. If no extra work is needed, referencing the checklist -without reproducing it is sufficient. - -Link to any blueprints that need to be completed in the incubator -before the library can be graduated. - -Describe any organizational or API changes to the code that need to be -made after the code is moved to its new repository but before the -library can be considered ready for use. Complex changes should be -separate blueprints. - -Adoption Notes -============== - -In this section, provide any advice possible to make adopting the new -library easier. Will the library will behave differently than the -incubated code in some significant way? Will it need specific -integration work across all projects (e.g., creating an integration -module to hold globals)? - -Dependencies -============ - -- Include specific references to specs and/or blueprints in oslo, or in other - projects, that this one either depends on or is related to. - -- Does this feature require any new library dependencies or code otherwise not - included in OpenStack? Or does it depend on a specific version of library? - -References -========== - -Please add any useful references here. You are not required to have any -reference. Moreover, this specification should still make sense when your -references are unavailable. Examples of what you could include are: - -* Links to mailing list or IRC discussions - -* Links to notes from a summit session - -* Links to relevant research, if appropriate - -* Related specifications as appropriate (e.g. if it's an EC2 thing, link the - EC2 docs) - -* Anything else you feel it is worthwhile to refer to - - - -.. note:: - - This work is licensed under a Creative Commons Attribution 3.0 - Unported License. - http://creativecommons.org/licenses/by/3.0/legalcode -