>From 22613d8e014fd52b0b1114d29cef9a0673787fb0 Mon Sep 17 00:00:00 2001 From: Srikanth Kurapati <srikanth.kurap...@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.*
patch.diff
Description: Binary data
_______________________________________________ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
