docs: Specify that OFP should adapt to ODP LTS releases.

ODP Long Term Support (LTS) releases are the ones that are actually
supported by ODP and vendors alike, so those are the ODP releases OFP
should adapt to.

Signed-off-by: Jere Leppänen <14957520de8d9815e0c353a07fe23c737f0171e9@nokia.com>
Reviewed-by: Sorin Vultureanu <8013ba55f8675034bc2ab0d6c3a1c9650437ca36@enea.com>

= OpenFastPath Release Policy
Jere Leppänen <jere.leppanen@nokia.com>
:max-width: 600px
:numbered:
:toc:

== Introduction

This document defines the policies concerning OpenFastPath (OFP)
software releases. Written rules are required to produce uniform
releases. Publicly documented release policy and release process also
brings some predictability to the project, which is beneficial to both
users and contributors.

This document is informational, not binding. The policy may be changed
at the decision of the OFP Technical Steering Committee (TSC).

The purpose of OFP releases is to provide supported software with a
stable API and ABI to users. The API is defined by C header files in
the include/api directory in the OFP repository <<repo>>.

== Versioning and Naming

* Semantic Versioning <<semver>> is used.

* Versioning is driven by API, ABI and CLI.

    ** Any compatible change of API, ABI or CLI increments the minor
       version.

    ** Any incompatible change of API, ABI or CLI increments the major
       version.

    ** An incompatible CLI change means that a CLI command doesn't
       work anymore or does something different than it did before.

* Every minor version is a release.

* Releases are named after small animals, with the first letters of
  the names progressing in alphabetical order.

* Bug fixes are gathered and tagged as a patch version, and published
  as a patch release.

* Libraries are versioned independently from release versioning, and
  independently of each other, using Semantic Versioning driven by the
  ABI provided by the library.

.Referring to a release or a version
****
. "OpenFastPath" or "OFP", without the quotes.
. Release name, starting with a capital letter.
. Version.

Some elements may be omitted, but the remaining elements always appear
in this order.

Examples:

* OpenFastPath Angelfish 2.0.0 - for maximum clarity.

* OFP Angelfish - when the exact version doesn't matter, because
  they're all compatible anyway.

* OFP 2.0.0 - when you don't care about the naming.

* Angelfish 2.0.0 - when referring to a release, but at the same time
  wanting to specify the exact version for those individuals in the
  audience for whom it means something.
****

== Compatibility

It follows from the versioning scheme that within a release, API, ABI
and CLI are backwards compatible. Beyond that, version numbers are
needed to determine whether two releases are compatible or not.

Each library is separately versioned, so it's possible for a
particular library to be ABI compatible across different releases or
even across different major versions.

== Requirements

Release Notes lists the requirements for each OFP release, including
the required version of OpenDataPlane (ODP).  Newer compatible
versions of ODP may be used. In ODP's four level versioning, as long
as the first two levels remain the same, the API is compatible. Please
see <<ODPRG>> for more information on ODP release versioning.

== Support

All serious bugs in the current General Availability release are fixed
on a best-effort basis. Bug fixes are integrated in a patch release.
The example applications in the examples directory may have a lower
support priority than the core implementation.

New features and improvements are usually added only in new releases,
although it's possible to add new features in a patch release as long
as compatibility is preserved.

== Release Contents

An OFP release consists of the following source code and documentation:

* Release Announcement on the OFP announcements page and on the
  mailing list, which states the name, version and date of the
  release, and contains a link to the Release Notes.

* Release Notes, which includes information about requirements, the
  release life cycle, changes since last release and known
  issues. Release Notes are archived on the OFP Release Archive page
  <<relarch>>.

* Release tag in the OFP repository <<repo>>, and all the content in
  the repository that the release tag points to.

== Release Life Cycle

* The stages of a release are:

    Development:: In this stage, new features are being developed and
        old features may be modified or even removed. The API, ABI and
        CLI may be unstable.

    Release Candidate:: Once all features have been implemented and
        API finalized, a feature freeze, which implies API, ABI and
        CLI freeze, may be initiated and the release moved to the
        release candidate stage. Release candidates are tagged. If
        issues are found, a correction is made and a new release
        candidate is tagged. Even though the API is frozen, bugs in
        the API may still be corrected in this stage. Once a release
        enters the Release Candidate stage, the next release enters
        Development stage.

    General Availability:: A release may enter this stage once the
        following criteria are met:

        *** All automated test cases pass.

        *** At least one week has passed since the last release
            candidate was tagged, and no issues requiring a correction
            have been found.

        *** All release content, listed in the
            <<_release_contents,Release Contents>> section, is
            available.

    End of Life:: A release enters End of Life stage once the next
        release enters General Availability stage. In the End of Life
        stage, no changes are made to the release and bug reports are
        not necessarily accepted anymore. Even if a bug report is
        accepted, the correction will only be done to the current
        release.

* Only one release at a time is maintained (in General Availability
  stage).

* General Availability stage lasts for at least five months.

* OFP aims to adapt to new ODP Long Term Support (LTS) releases within
  one month of the ODP release. This usually necessitates a new OFP
  release.

* Stage transitions are communicated on the announcements page and
  mailing list at least one week beforehand, End of Life at least one
  month beforehand.

* The decisions and approvals related to transitions between these
  stages are the responsibility of the TSC, based on the criteria
  above and inputs and comments from OFP members.

== References

[bibliography]

* [[[ODPRG]]] ODP Release Guide.
  http://docs.opendataplane.org/snapshots/odp-publish/generic/usr_html/latest/master/linux-generic/output/release-guide.html

* [[[relarch]]] OFP Release Archive.
  http://www.openfastpath.org/index.php/service/releasearchives/

* [[[repo]]] OFP Repository. https://github.com/OpenFastPath/ofp

* [[[semver]]] Semantic Versioning 2.0.0.
  http://semver.org/spec/v2.0.0.html

= OpenFastPath Release Policy
Jere Leppänen <jere.leppanen@nokia.com>
:max-width: 600px
:numbered:
:toc:

== Introduction

This document defines the policies concerning OpenFastPath (OFP)
software releases. Written rules are required to produce uniform
releases. Publicly documented release policy and release process also
brings some predictability to the project, which is beneficial to both
users and contributors.

This document is informational, not binding. The policy may be changed
at the decision of the OFP Technical Steering Committee (TSC).

The purpose of OFP releases is to provide supported software with a
stable API and ABI to users. The API is defined by C header files in
the include/api directory in the OFP repository <<repo>>.

== Versioning and Naming

* Semantic Versioning <<semver>> is used.

* Versioning is driven by API, ABI and CLI.

    ** Any compatible change of API, ABI or CLI increments the minor
       version.

    ** Any incompatible change of API, ABI or CLI increments the major
       version.

    ** An incompatible CLI change means that a CLI command doesn't
       work anymore or does something different than it did before.

* Every minor version is a release.

* Releases are named after small animals, with the first letters of
  the names progressing in alphabetical order.

* Bug fixes are gathered and tagged as a patch version, and published
  as a patch release.

* Libraries are versioned independently from release versioning, and
  independently of each other, using Semantic Versioning driven by the
  ABI provided by the library.

.Referring to a release or a version
****
. "OpenFastPath" or "OFP", without the quotes.
. Release name, starting with a capital letter.
. Version.

Some elements may be omitted, but the remaining elements always appear
in this order.

Examples:

* OpenFastPath Angelfish 2.0.0 - for maximum clarity.

* OFP Angelfish - when the exact version doesn't matter, because
  they're all compatible anyway.

* OFP 2.0.0 - when you don't care about the naming.

* Angelfish 2.0.0 - when referring to a release, but at the same time
  wanting to specify the exact version for those individuals in the
  audience for whom it means something.
****

== Compatibility

It follows from the versioning scheme that within a release, API, ABI
and CLI are backwards compatible. Beyond that, version numbers are
needed to determine whether two releases are compatible or not.

Each library is separately versioned, so it's possible for a
particular library to be ABI compatible across different releases or
even across different major versions.

== Requirements

Release Notes lists the requirements for each OFP release, including
the required version of OpenDataPlane (ODP).  Newer compatible
versions of ODP may be used. In ODP's four level versioning, as long
as the first two levels remain the same, the API is compatible. Please
see <<ODPRG>> for more information on ODP release versioning.

== Support

All serious bugs in the current General Availability release are fixed
on a best-effort basis. Bug fixes are integrated in a patch release.
The example applications in the examples directory may have a lower
support priority than the core implementation.

New features and improvements are usually added only in new releases,
although it's possible to add new features in a patch release as long
as compatibility is preserved.

== Release Contents

An OFP release consists of the following source code and documentation:

* Release Announcement on the OFP announcements page and on the
  mailing list, which states the name, version and date of the
  release, and contains a link to the Release Notes.

* Release Notes, which includes information about requirements, the
  release life cycle, changes since last release and known
  issues. Release Notes are archived on the OFP Release Archive page
  <<relarch>>.

* Release tag in the OFP repository <<repo>>, and all the content in
  the repository that the release tag points to.

== Release Life Cycle

* The stages of a release are:

    Development:: In this stage, new features are being developed and
        old features may be modified or even removed. The API, ABI and
        CLI may be unstable.

    Release Candidate:: Once all features have been implemented and
        API finalized, a feature freeze, which implies API, ABI and
        CLI freeze, may be initiated and the release moved to the
        release candidate stage. Release candidates are tagged. If
        issues are found, a correction is made and a new release
        candidate is tagged. Even though the API is frozen, bugs in
        the API may still be corrected in this stage. Once a release
        enters the Release Candidate stage, the next release enters
        Development stage.

    General Availability:: A release may enter this stage once the
        following criteria are met:

        *** All automated test cases pass.

        *** At least one week has passed since the last release
            candidate was tagged, and no issues requiring a correction
            have been found.

        *** All release content, listed in the
            <<_release_contents,Release Contents>> section, is
            available.

    End of Life:: A release enters End of Life stage once the next
        release enters General Availability stage. In the End of Life
        stage, no changes are made to the release and bug reports are
        not necessarily accepted anymore. Even if a bug report is
        accepted, the correction will only be done to the current
        release.

* Only one release at a time is maintained (in General Availability
  stage).

* General Availability stage lasts for at least five months.

* OFP aims to adapt to new ODP releases within one month of the ODP
  release. This usually necessitates a new OFP release.

* Stage transitions are communicated on the announcements page and
  mailing list at least one week beforehand, End of Life at least one
  month beforehand.

* The decisions and approvals related to transitions between these
  stages are the responsibility of the TSC, based on the criteria
  above and inputs and comments from OFP members.

== References

[bibliography]

* [[[ODPRG]]] ODP Release Guide.
  http://docs.opendataplane.org/snapshots/odp-publish/generic/usr_html/latest/master/linux-generic/output/release-guide.html

* [[[relarch]]] OFP Release Archive.
  http://www.openfastpath.org/index.php/service/releasearchives/

* [[[repo]]] OFP Repository. https://github.com/OpenFastPath/ofp

* [[[semver]]] Semantic Versioning 2.0.0.
  http://semver.org/spec/v2.0.0.html


update the reference implementations section

Signed-off-by: Scott Stark <44b2f47f410f4bf6655e3ec1c92f766044282b1f@gmail.com>

//
// Copyright (c) 2016-2017 Eclipse Microprofile Contributors:
// Red Hat
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//

## Reference Implementations

This sections references known reference implementations of the Eclise MicroProfile JWT RBAC authorization specification.

### General Java EE/SE based Implementations

A baseline reference implementation that is available under the ASLv2 license
can be found at https://github.com/starksm64/microprofile-jwt-auth-ri. The purpose
of this RI is to offer reusable code for integration of the JWT RBAC authenticaiton
and authorization spec in various container environments. This particular implementation contains:

* a default implementation of the JWTPrincipal interface
* a JAX-RS ContainerRequestFilter prototype
* JSR-375 IdentityStore and Credential prototypes
* TODO: a JSR-196 ServerAuthModule

### Wildfly Swarm Implementations

A reference implementation for a custom auth-method of MP-JWT with the Wildfly/Wildfly-Swarm Undertow web container
available under the ASLv2 license can be found at https://github.com/starksm64/microprofile-jwt-auth-wfswarm.

//
// Copyright (c) 2016-2017 Eclipse Microprofile Contributors:
// Red Hat
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
//     http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
//

## Reference Implementation
A baseline reference implementation that is available under the ASLv2 license
can be found at https://github.com/starksm64/microprofile-jwt-auth-ri. The purpose
of this RI is to offering reusable code for integration of the JWT RBAC authenticaiton
and authorization in various container environments.


Update 2015-02-10-Por-que-amo-lo-que-hago.adoc

= Por que amo lo que hago!
Javier León (@jelitox) <jel1284@gmail.com>
v1.0, 2015-02-13
:toc:
:imagesdir: assets/images
:homepage: http://blog.javierleon.com.ve
:hp-tags: Blog,Personal
// Web page meta data.
:keywords: Blog, Javier León, IT, Devops, Desarrollo, Sysadmin, Social, Networks, emprendimiento, Pagina Oficial,
:description: Blog personal y Profesional, +
Ingeniero en Informatica, desarrollador y Administrador de Sistemas e infraestructura, +
Redes Sociales, facebook, instagram, twitter, pinterest +
proyectos de emprendimiento Freenlance, +
Pagina principal.

.{revdate}:  {revnumber}
*******************************************************************
[quote, Steve jobs]
Tu trabajo va a llenar gran parte de tu vida, y la única forma de estar realmente satisfecho con él es hacer lo que creas que es un gran trabajo. Y la única manera de hacer un trabajo genial es amar lo que haces. Si no lo has encontrado, sigue buscando. No te detengas. Al igual que con todos los asuntos del corazón, lo sabrás cuando lo encuentres. Y, como cualquier gran relación, sólo se pondrá mejor y mejor, conforme los años pasen. Así que sigue buscando hasta que lo encuentres. No te detengas.
____

*******************************************************************
Introduction
------------
{description}

AsciiDoc is highly configurable: both the AsciiDoc source file syntax
and the backend output markups (which can be almost any type of
SGML/XML markup) can be customized and extended by the user.

AsciiDoc is free software and is licenced under the terms of the 'GNU
General Public License version 2' (GPLv2).

TIP: The pages you are reading were written using AsciiDoc, to view
the corresponding AsciiDoc source click on the *Page Source* menu item
in the left hand margin.

Overview and Examples
---------------------
You write an AsciiDoc document the same way you would write a
normal text document, there are no markup tags or weird format
notations. AsciiDoc files are designed to be viewed, edited and
printed directly or translated to other presentation formats using
the asciidoc(1) command.

The asciidoc(1) command translates AsciiDoc files to HTML, XHTML and
DocBook markups. DocBook can be post-processed to presentation
formats such as HTML, PDF, EPUB, DVI, LaTeX, roff, and Postscript
using readily available Open Source tools.

Example Articles
~~~~~~~~~~~~~~~~
- This XHTML version of the
link:asciidoc.css-embedded.html[AsciiDoc User Guide]
was generated by AsciiDoc from
link:asciidoc.txt[this AsciiDoc file].

- Here's the link:asciidoc.html[same document] created by first
generating DocBook markup using AsciiDoc and then converting the
DocBook markup to HTML using 'DocBook XSL Stylesheets'.

- The User Guide again, this time a
link:chunked/index.html[chunked version].

- AsciiDoc generated this link:article-standalone.html[stand-alone
HTML file] containing embedded CSS, JavaScript and images from this
link:article.txt[AsciiDoc article template] with this command:

asciidoc -a data-uri -a icons -a toc -a max-width=55em article.txt

- The same link:article.txt[AsciiDoc article template] generated
link:article-html5-toc2.html[this HTML 5] (the 'toc2' attribute puts
a table of contents in the left margin) from this command:

asciidoc -b html5 -a icons -a toc2 -a theme=flask article.txt

- The same link:article.txt[AsciiDoc article template] produced
this link:article.html[HTML file] and this
link:article.pdf[PDF file] via DocBook markup generated by AsciiDoc.

[[X7]]
Example Books
~~~~~~~~~~~~~
AsciiDoc markup supports all the standard DocBook frontmatter and
backmatter sections (dedication, preface, bibliography, glossary,
index, colophon) plus footnotes and index entries.

- This link:book.txt[AsciiDoc book] produced link:book.html[this HTML
file] using the 'DocBook XSL Stylesheets'.
- The link:asciidoc.pdf[PDF formatted AsciiDoc User Guide] was
generated from asciidoc(1) DocBook output.
- The link:asciidoc.epub[EPUB formatted AsciiDoc User Guide] was
generated using link:a2x.1.html[a2x].
- This link:book.epub[EPUB formatted book skeleton] was generated
using link:a2x.1.html[a2x].
- This link:book-multi.txt[multi-part AsciiDoc book] produced
link:book-multi.html[this HTML file] using the 'DocBook XSL
Stylesheets'.

Example UNIX Man Pages
~~~~~~~~~~~~~~~~~~~~~~
HTML formatted AsciiDoc man pages
link:asciidoc.1.css-embedded.html[with stylesheets] and
link:asciidoc.1.html[without stylesheets] were generated by AsciiDoc
from link:asciidoc.1.txt[this file].

This link:asciidoc.1[roff formatted man page] was generated from
asciidoc(1) DocBook output using `xsltproc(1)` and DocBook XSL
Stylesheets.

[[X8]]
Example Slideshows
~~~~~~~~~~~~~~~~~~
The http://www.w3.org/Talks/Tools/Slidy2/[Slidy] backend generates
HTML slideshows that can be viewed in any web browser. What's nice is
that you can create completely self contained slideshows including
embedded images.

- Here is the link:slidy.html[slidy backend documentation] slideshow
and here is it's link:slidy.txt[AsciiDoc source].
- An link:slidy-example.html[example slidy slideshow] and the
link:slidy-example.txt[AsciiDoc source].

Example Web Site
~~~~~~~~~~~~~~~~
The link:README-website.html[AsciiDoc website] is included in the
AsciiDoc distribution (in `./examples/website/`) as an example website
built using AsciiDoc. See `./examples/website/README-website.txt`.

= Por que amo lo que hago!
Javier León (@jelitox) <jel1284@gmail.com>
v1.0, 2015-02-13
:toc:
:imagesdir: assets/images
:homepage: http://blog.javierleon.com.ve
:hp-tags: Blog,Personal
// Web page meta data.
:keywords: Blog, Javier León, IT, Devops, Desarrollo, Sysadmin, Social, Networks, emprendimiento, Pagina Oficial,
:description: Blog personal y Profesional, +
Ingeniero en Informatica, desarrollador y Administrador de Sistemas e infraestructura, +
Redes Sociales, facebook, instagram, twitter, pinterest +
proyectos de emprendimiento Freenlance, +
Pagina principal.

.{revdate}:  {revnumber}
[quote, Steve jobs]
Tu trabajo va a llenar gran parte de tu vida, y la única forma de estar realmente satisfecho con él es hacer lo que creas que es un gran trabajo. Y la única manera de hacer un trabajo genial es amar lo que haces. Si no lo has encontrado, sigue buscando. No te detengas. Al igual que con todos los asuntos del corazón, lo sabrás cuando lo encuentres. Y, como cualquier gran relación, sólo se pondrá mejor y mejor, conforme los años pasen. Así que sigue buscando hasta que lo encuentres. No te detengas.
____

*******************************************************************
Introduction
------------
{description}

AsciiDoc is highly configurable: both the AsciiDoc source file syntax
and the backend output markups (which can be almost any type of
SGML/XML markup) can be customized and extended by the user.

AsciiDoc is free software and is licenced under the terms of the 'GNU
General Public License version 2' (GPLv2).

TIP: The pages you are reading were written using AsciiDoc, to view
the corresponding AsciiDoc source click on the *Page Source* menu item
in the left hand margin.

Overview and Examples
---------------------
You write an AsciiDoc document the same way you would write a
normal text document, there are no markup tags or weird format
notations. AsciiDoc files are designed to be viewed, edited and
printed directly or translated to other presentation formats using
the asciidoc(1) command.

The asciidoc(1) command translates AsciiDoc files to HTML, XHTML and
DocBook markups. DocBook can be post-processed to presentation
formats such as HTML, PDF, EPUB, DVI, LaTeX, roff, and Postscript
using readily available Open Source tools.

Example Articles
~~~~~~~~~~~~~~~~
- This XHTML version of the
link:asciidoc.css-embedded.html[AsciiDoc User Guide]
was generated by AsciiDoc from
link:asciidoc.txt[this AsciiDoc file].

- Here's the link:asciidoc.html[same document] created by first
generating DocBook markup using AsciiDoc and then converting the
DocBook markup to HTML using 'DocBook XSL Stylesheets'.

- The User Guide again, this time a
link:chunked/index.html[chunked version].

- AsciiDoc generated this link:article-standalone.html[stand-alone
HTML file] containing embedded CSS, JavaScript and images from this
link:article.txt[AsciiDoc article template] with this command:

asciidoc -a data-uri -a icons -a toc -a max-width=55em article.txt

- The same link:article.txt[AsciiDoc article template] generated
link:article-html5-toc2.html[this HTML 5] (the 'toc2' attribute puts
a table of contents in the left margin) from this command:

asciidoc -b html5 -a icons -a toc2 -a theme=flask article.txt

- The same link:article.txt[AsciiDoc article template] produced
this link:article.html[HTML file] and this
link:article.pdf[PDF file] via DocBook markup generated by AsciiDoc.

[[X7]]
Example Books
~~~~~~~~~~~~~
AsciiDoc markup supports all the standard DocBook frontmatter and
backmatter sections (dedication, preface, bibliography, glossary,
index, colophon) plus footnotes and index entries.

- This link:book.txt[AsciiDoc book] produced link:book.html[this HTML
file] using the 'DocBook XSL Stylesheets'.
- The link:asciidoc.pdf[PDF formatted AsciiDoc User Guide] was
generated from asciidoc(1) DocBook output.
- The link:asciidoc.epub[EPUB formatted AsciiDoc User Guide] was
generated using link:a2x.1.html[a2x].
- This link:book.epub[EPUB formatted book skeleton] was generated
using link:a2x.1.html[a2x].
- This link:book-multi.txt[multi-part AsciiDoc book] produced
link:book-multi.html[this HTML file] using the 'DocBook XSL
Stylesheets'.

Example UNIX Man Pages
~~~~~~~~~~~~~~~~~~~~~~
HTML formatted AsciiDoc man pages
link:asciidoc.1.css-embedded.html[with stylesheets] and
link:asciidoc.1.html[without stylesheets] were generated by AsciiDoc
from link:asciidoc.1.txt[this file].

This link:asciidoc.1[roff formatted man page] was generated from
asciidoc(1) DocBook output using `xsltproc(1)` and DocBook XSL
Stylesheets.

[[X8]]
Example Slideshows
~~~~~~~~~~~~~~~~~~
The http://www.w3.org/Talks/Tools/Slidy2/[Slidy] backend generates
HTML slideshows that can be viewed in any web browser. What's nice is
that you can create completely self contained slideshows including
embedded images.

- Here is the link:slidy.html[slidy backend documentation] slideshow
and here is it's link:slidy.txt[AsciiDoc source].
- An link:slidy-example.html[example slidy slideshow] and the
link:slidy-example.txt[AsciiDoc source].

Example Web Site
~~~~~~~~~~~~~~~~
The link:README-website.html[AsciiDoc website] is included in the
AsciiDoc distribution (in `./examples/website/`) as an example website
built using AsciiDoc. See `./examples/website/README-website.txt`.