[x265] [x265 Documentation] [WiKi Pages PATCH] x265 wiki page updates for release version 3.5

Srikanth Kurapati srikanth.kurapati at multicorewareinc.com
Mon Jan 18 05:53:36 UTC 2021 

>From 22613d8e014fd52b0b1114d29cef9a0673787fb0 Mon Sep 17 00:00:00 2001
From: Srikanth Kurapati <srikanth.kurapati at multicorewareinc.com>
Date: Wed, 14 Oct 2020 13:40:10 +0530
Subject: [PATCH] x265 wiki page updates for release version 3.5

includes archival procedure updates plus general edits in home and
contribute pages
---
 Contribute.md | 30 +++++++++++++--------------
 Home.md       | 56 ++++++++++++++++++++++++++++++++++++++++++---------
 2 files changed, 62 insertions(+), 24 deletions(-)

diff --git a/Contribute.md b/Contribute.md
index 5fd299c..543492e 100644
--- a/Contribute.md
+++ b/Contribute.md
@@ -13,7 +13,7 @@ We use a mailing list to communicate and review patches:

 ## Contributor License Agreement ##

-As is common for Open Source projects, we require a signed [contributor
agreement](
https://bitbucket.org/multicoreware/x265_git/downloads/x265ContributorAgreement.pdf
)
+As is common for Open Source Projects, we require a signed [contributor
agreement](
https://bitbucket.org/multicoreware/x265_git/downloads/x265ContributorAgreement.pdf
)
 before we can accept changes.  This protects the project from being sued
by former
 contributors (or their employers) for copyright or patent infringement.

@@ -39,8 +39,8 @@ can explain how git concepts map to Mercurial.  This
[blog](http://stevelosh.com
 The first rule for contributing changes is to never develop from a
 downloaded source package.  Always clone the x265 main repository at
 https://bitbucket.org/multicoreware/x265_git and then develop within your
-cloned repository so your changes can be revisioned controlled from the
-beginning.
+cloned repository so your changes can be revisioned and version controlled
from the
+beginning itself.

 A primary principle of distributed revision control is that every
 developer with a clone has full and total access to the revision
@@ -61,10 +61,10 @@ then make more commits and repeat.  By the time your
changes are ready
 for public distribution, you might have dozens of commits and several
 merges with incoming changes.  Here is how you tidy up all your work for
 submission to our mailing list, the primary goal here is to rebase all
-of your changes on top of the current x265 tip so your patches will
+of your changes on top of the current x265 tip so that your patches will
 apply cleanly on the maintainer's repository:

-(these instructions are recommended to be done on terminal (either windows
commnand prompt/git bash terminal/ if windows OS or linux terminal in case
of Linux OS or ios terminal incase of iOs)
+(these instructions are recommended to be done on terminal (either windows
command prompt/git bash terminal/ if windows OS or linux terminal in case
of Linux OS or ios terminal incase of iOs)

 1. Before beginning , make sure all of your changes have been checked in,
or reverted if you did not want to keep them. You must start with a clean
working directory. Login to the terminal and go to the folder which
contains the repository.
 ***CLI: git status ; git commit or git reset --hard***
@@ -94,7 +94,7 @@ this point you can review all of the changes you have
made.  You can remove inad
 1. Separate white-space changes from logic changes.  Commits should never
do both

 Now build and test the last commit to ensure all tests pass, etc.
-If any performance improvements are intended, the amount gained should
+If any performance or video encoding quality improvements are intended,
the amount gained should
 be included in the email subject or body, or in the commit message
 itself.

@@ -107,8 +107,8 @@ Finally you can email your patches to the mailing list.
 * Eg : ***git format-patch master -1
cd9dda0793c5b874c711eafe5ffde15c0ac208cc -o patches***
 1. You should be able to see your new patches in the directory which was
mentioned . The patches will have the commit message of the specific commit

-Now build and test the last commit to ensure all tests pass, etc.
-If any performance improvements are intended, the amount gained should
+Now build and test the patches to ensure all tests pass, etc.
+If any performance or video encoding quality improvements are intended,
the amount gained should
 be included in the email subject or body, or in the commit message
 itself.

@@ -134,7 +134,7 @@ for continuing on:
 In any case, you want to discard your old line of development and start
 your new work from the current x265 tip.

-**Maintenance of Hg repository**
+**Maintenance of Git repository**

 Once your patch is approved and pushed to the x265 Git repository, we have
automated the process of getting all the new patches from the git
repository and importing & pushing it to the respective branch of x265 Hg
repository. By this way we ensure both the VCS are in sync and up to date.

@@ -142,12 +142,12 @@ Once your patch is approved and pushed to the x265
Git repository, we have autom

 If you introduce a new x265_param member, you must add documentation for
it and make it fully configurable.

-1. x265.h needs good documentation
+1. x265.h needs good documentation as comments in the param data
structures.
 2. x265_param_parse() must be updated
 3. x265_param2string() must be updated
-4. getopt() (and CLI help) support needs to be added to x265cli.h
-5. the param must be documented in doc/reST/cli.rst
-6. X265_BUILD must be incremented, the binary interface has changed
-7. test(s) have to be added to smoke-tests.txt and regression-tests.txt
+4. getopt() (and CLI help) support needs to be added to x265cli.h and cpp
files
+5. The param option usage and relevance must be documented in
doc/reST/cli.rst and corresponding rst documentation files.
+6. X265_BUILD must be incremented, as the binary interface has changed.
+7. TestCases have to be added to smoke-tests.txt and regression-tests.txt.

-Much of the above is also true if you change any public function
definitions or public structures.
\ No newline at end of file
+Much of the above is also true if you change any public function
definitions or public structures available as part of API to the library.
\ No newline at end of file
diff --git a/Home.md b/Home.md
index 8f36e14..b75c2fc 100644
--- a/Home.md
+++ b/Home.md
@@ -25,13 +25,53 @@ MD5 (x265_3.1.2.tar.gz) =
a528ab27660d6bcfc46188ae602b3c2e
 MD5 (x265_3.2.tar.gz) = 374e6359a00d17fd82195c02c341c861
 MD5 (x265_3.2.1.tar.gz) = 94808045a34d88a857e5eaf3f68f4bca
 ```
+# Preparing Git Release tar balls
+
+Release source archive tar balls can be created by the following procedure
in the below sections.
+
+## HOW TO POPULATE THE X265 VERSION TEXT FILE ##
+```
+The purpose of the x265 version file is to maintain and provide version
information for archived repositories.  This file
+is available in the repository folder as x265Version.txt.  Every line in
the file captures the version information in key value pairs format <Key:
Value>.
+The following set of mandatory key value pairs are required for correct
display of version string on the console.
+
+## VERSION INFORMATION FORMAT ##
+## Name: Values ##
+releasetag: [tag name] refers to the latest version tag for customers,
users, developers or contributors in the format [x.x] or x.x_RC[number]
+releasetagdistance: [commit count] the number of revisions done since the
release tagging has been done for bug fixes or feature enhancements due to
testing.
+repositorychangeset: [git changeset] is the git generated SHA-1 key
changeset string of the repository tip at which archival is performed.
+
+EXAMPLES:
+For tar ball generation of Release Tag.
+## Name: Values ##
+releasetag: Release_3.4
+repositorychangeset: a82c6c7
+releasetagdistance: 0
+
+When archives are generated after the Release for customers, users etc
+
+## Name: Values ##
+releasetag: Release_3.5
+releasetagdistance: 28
+repositorychangeset: a82c6c7
+
+For archival at a commit before the latest tag. same procedure as above
works considering the previous tag as the latest one.
+
+After filling the x265version file for git repositories and saving the
same.  The tarball can be generated using the git archive command.
+$git archive --format=tar.gz -o x265-3.5.tar.gz --prefix=x265-test/ HEAD
+
+In case of multiple entries for the release information attribute-value
pairs.  The latest set of required attribute-value pairs in file will be
considered.
+The same file can be appended at the end for every release.  In order to
prepare archives for various tags(prior releases), user can provide the
tagname as the changeset option for simplicity.
+Please refer to [documentation](https://x265.readthedocs.io/en/master/)
for version option details and git manual for more information about
archival. The procedure suffices for zip and other
+relevant compression formats typically supported git and decompression
tools available for various operating systems (OSs).
+```

 # Building x265

-To compile x265 you must first install Git and [CMake](
http://www.cmake.org/cmake/resources/software.html) 2.8.8 or later.
+To compile x265 you must first install Git (for live repositories) and
[CMake](http://www.cmake.org/cmake/resources/software.html) 2.8.8 or later.
 To ensure your build of x265 is capable of full performance, install
 [YASM](http://www.tortall.net/projects/yasm/releases) 1.2.0 or newer if
you are using x265 v2.6 or older, or
-[NASM](http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D) 2.13 or newer
if you are compiling from the default branch to compile
+[NASM](http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D) 2.13 or newer
if you are compiling from the master branch to compile
 assembly primitives.  Then follow these easy steps:

 For detailed instructions, consult our build [README](
https://bitbucket.org/multicoreware/x265_git/src/master/build/README.txt).
Basic instructions are outlined below.
@@ -46,11 +86,10 @@ $ sudo apt-get install git-all cmake cmake-curses-gui
build-essential yasm
 $ git clone https://bitbucket.org/multicoreware/x265_git.git
 $ cd x265/build/linux
 $ ./make-Makefiles.bash
-$ make
+$ make -j8
 ```
-
-The primary target that we support is x86. x265 can also be built on linux
platforms on ARM and POWERPC targets using the same build insructions above
-(exclude yasm from the list of packages on these targets). Our support for
these platforms is growing as our user base on these platforms increase.
+The primary target hardware architecture that we support is x86. x265 can
also be built on Linux platforms on ARM and POWERPC target machines using
the same build instructions above
+(exclude yasm from the list of packages on these target platforms). Our
support for these platforms is growing as our user base on these platforms
is increasing.

 We also support cross-compilation for ARM targets from linux platforms on
x86 targets by using the g++ arm cross-compiler. This has been tested on
Ubuntu linux
 14.04 running on an x86 CPU. On other distributions, package names and
names of cross compilation tools may differ. This is an experimental
feature, and has undergone very limited testing.
@@ -60,16 +99,15 @@ $ sudo apt-get install git-all cmake cmake-curses-gui
build-essential gcc-arm-li
 $ git clone https://bitbucket.org/multicoreware/x265_git.git
 $ cd x265/build/arm-linux
 $ ./make-Makefiles.bash
-$ make
+$ make -j8
 ```
 ## Windows (Visual Studio) Instructions ##
 ```
 $ git clone https://bitbucket.org/multicoreware/x265_git.git
 ```
-
 Then run make-solutions.bat in the build\ folder that corresponds to
 your favorite compiler, configure your build options, click 'configure',
-click 'generate', then close cmake-gui.  You will be rewarded with an
+click 'generate', then close cmake-GUI.  You will be rewarded with an
 x265.sln file.  Also see [cmake](
http://www.cmake.org/cmake/help/runningcmake.html)
 documentation.

--
2.20.1.windows.1

-- 
*With Regards,*
*Srikanth Kurapati.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20210118/330629cc/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.diff
Type: application/octet-stream
Size: 11779 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20210118/330629cc/attachment-0001.obj>

More information about the x265-devel mailing list