Latest revision as of 14:08, 3 November 2016

Purpose

The main goal to use templates instead of SPEC - flexibility and unification. Templates made in Jinja2 format.
It means that templates made in one way after processing by renderspec tool will fit all supported Linux vendors(SUSE, Fedora, CentOS).

Tool-set

openstack-macros - sub-project which allows to add or substitute required RPM macro used in SPEC template.
pymod2pkg - project used for translation of python source name aka pypi name into Linux package name.
renderspec - main tool used for transformation from SPEC template into SPEC file. documentaion

Workflow for branches

Current work

All work must be done in the master branch of the particular project.

Back-ports/Cherry-picks

In case of necessity changes proposed earlier to the master branch could be cherry-picked into stable branch.

Cases for back-port/cherry-picks:
- Introduction of a new package if its metadata is valid as for master as for stable
- There is no difference in amount of run-time and built-time dependencies
- There is no difference in Version: between master and stable
- There are changes which are fixing %install or %files sections for a particular package

In other cases updates should be proposed to a particular branch which requires an update!

Common rules

Head

Group:

Setting up proper group for package is a requirement.

Source0:

Source0 must points to existing tarball location, even if url constructed using macro.
Example:

Group:      Development/Libraries
Source0:    https://pypi.python.org/packages/source/o/%{sname}/%{sname}-%{version}.tar.gz

Documentation

For *-doc package should be specified additional section which describes all meta-data for doc package.
BuildRequires: - populated only with projects required for documentation build.
Please use %bcond_with docs in case of necessity!
Example:

%if %{with docs}
%package doc
....
%endif

%if %{with docs}
%files doc
...
%endif

Tests

Useful but not mandatory. All directives for unit tests must be set under %check section.
All required for tests projects should be specified as BuildRequires: in the top of template.
Please use %bcond_with test in case of necessity!
Example:

%if %{with test}
BuildRequires: required for test projects
....
%endif

%if %{with test}
%check
...
%endif

Version bumps

When updating the version of an existing package, please always add the following line in the commit message:

Depends-On: <change ID>

Where <change ID> is the change ID of the review for the openstack/requirements repository where the version for the package is updated. By doing this, we can ensure that no version will be updated before it is part of the upper-constraints.txt file.

See https://review.openstack.org/393121 for an example.

Misc but important!

Under %files section for each package in SPEC template:

Section %doc should not include: HACKING*, CONTRIBUTING* and AUTHORS
Section %license should be specified in case of LICENCE file availability in source code

@@ Line 8: / Line 8: @@
 [https://github.com/openstack/renderspec renderspec] - main tool used for transformation from SPEC template into SPEC file. [http://docs.openstack.org/developer/renderspec/ documentaion]<br />
+=Workflow for branches=
+* '''Current work'''
+All work must be done in the '''master''' branch of the particular project.
+* '''Back-ports/Cherry-picks'''
+In case of necessity changes proposed earlier to the '''master''' branch could be cherry-picked into ''stable'' branch.
+* '''Cases for back-port/cherry-picks:'''
+** Introduction of a new package if its metadata is valid as for master as for stable
+** There is no difference in amount of run-time and built-time dependencies
+** There is no difference in Version: between ''master'' and ''stable''
+** There are changes which are fixing %install or %files sections for a particular package
+In '''other cases''' updates should be proposed to a particular branch which requires an update!
 =Common rules=
@@ Line 23: / Line 34: @@
 '''BuildRequires:''' - populated only with projects required for documentation build.<br />
 Please use ''%bcond_with docs'' in case of necessity!<br />
-''Exmaple:''<br />
+''Example:''<br />
   %if %{with docs}
   %package doc
@@ Line 33: / Line 44: @@
   ...
   %endif
 ==Tests==
 Useful but not mandatory. All directives for unit tests must be set under '''%check''' section.<br />
 All required for tests projects should be specified as '''BuildRequires:''' in the top of template.<br />
 Please use ''%bcond_with test'' in case of necessity!<br />
-''Exmaple:''<br />
+''Example:''<br />
   %if %{with test}
   BuildRequires: required for test projects
@@ Line 47: / Line 59: @@
   ...
   %endif
+==Version bumps==
+When updating the version of an existing package, please always add the following line in the commit message:
+ Depends-On: '''<change ID>'''
+Where '''<change ID>''' is the change ID of the review for the openstack/requirements repository where the version for the package is updated. By doing this, we can ensure that no version will be updated before it is part of the upper-constraints.txt file.
+See https://review.openstack.org/393121 for an example.
 ==Misc but important!==
 Under %files section for each package in SPEC template:<br />
 * Section '''%doc''' should not include: ''HACKING*'', ''CONTRIBUTING*'' and ''AUTHORS''<br />
 * Section '''%license''' should be specified in case of ''LICENCE'' file availability in source code<br />

Difference between revisions of "Rpm-packaging/ReviewGuidelines"