Update CONTRIBUTING.md

.github/CONTRIBUTING.md

@@ -27,3 +27,74 @@ __Some things that will increase the chance that your pull request is accepted__
 
 * Follow our [coding style guide](../docs/CODE_OF_CONDUCT.md).
 * Write a good commit message.
+
+# Branch Naming Conventions
+The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.
+
+## Purpose
+1.	Purpose-driven Branch Names: Each branch name clearly indicates its purpose, making it easy for all developers to understand what the branch is for.
+2.	Integration with CI/CD: By using consistent branch names, it can help automated systems (like Continuous Integration/Continuous Deployment pipelines) to trigger specific actions based on the branch type.
+3.	Better type and version control: Branches are related to a specific type of change in the code and the version that is being worked on, allowing for a much better backtracking.
+
+## Basic Rules
+- Naming structure: 
+`<type>/<description>`
+- Naming prefixes (Types):
+  - feature/: For new features (e.g., feature/add-login-page).
+  - fix/: For general fixes or code correcting.
+  - update/: For code upgrade or non-breaking code refactoring.
+  - chore/: For non-code tasks like dependency, docs updates (e.g., chore/update-dependencies).
+  - release/: For branches preparing a release (e.g., release/v1.2.0).
+- Use Lowercase Alphanumeric and Hyphens: Always use lowercase letters (a-z), numbers (0-9), and hyphens to separate words. Avoid special characters, underscores, or spaces.
+- No Consecutive or Trailing Hyphens: Ensure that hyphens are used singly, with no consecutive hyphens (feature/new--login) or at the end (feature/new-login-).
+- Keep It Clear and Concise: The branch name should be descriptive yet concise, clearly indicating the purpose of the work.
+- Include Ticket Numbers: If applicable, include the ticket number from your project management tool to make tracking easier. For example, for a ticket issue-123, the branch name could be feature/issue-123-new-login.
+
+## General Project Structure
+```
+main
+├── release/v1.x.x
+│   ├── feature/lorem-ipsum
+│   └── fix/ipsum-dolor
+├── release/v2.x.x
+│   └── chore/dolor-sit
+└── release/v3.x.x
+    ├── update/sit-amet
+    ├── feature/amet-consectetur
+    └── chore/consectetur-adipiscing
+```
+- main: This branch should only contain working versions completely tested and only receive pull requests from finalized release branches. All new release/ branches must come from this one.
+- release: The creation of these branches should be done from the last version of main when created. Only this branches can make pull requests to main.
+- Other branches: All working branches should come from a release branch. These are the only ones that should receive direct commits from changes made by development staff. These branches should only do PR to the active release branch.
+
+# Commits Naming Conventions
+The structure and design conventions are based mainly on the “Conventional Branch” concept and the team’s current work process.
+
+## Purpose
+1.	Automatically generating CHANGELOGs: When the commits are concise, and precise changelogs can be automated or semi-automated from the commit history.
+2.	Communicating the nature of changes to everyone: Being able to understand the type of changing by just looking at a name and understanding the basics of a commit just by the title is useful in analysis and backtrack situations.
+3.	Building code habits and good practices: Maintaining structured commits also leads to more precise coding practices and coherent code changes.
+
+## Basic Rules
+- Naming structure: 
+```
+<type>: <description>
+
+[optional body]
+```
+- Naming prefixes (Types):
+  - fix: A commit of the type fix patches a bug in your codebase.
+  - feat: A commit of the type feat introduces a new feature to the codebase
+  - <type>!: A commit that appends a ! after the type introduces a breaking change. A breaking change can be part of commits of any type.
+  - update: A commit of type update changes existing code or refactors functions without changing functionality of adding features in your codebase.
+  - build: A commit of type build changes build process in your codebase.
+  - docs: A commit of type docs is for creation or updating documentation in your codebase.
+  - chore: A commit of type chore is for every other minor task in your codebase.
+- Commits must be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the optional !, and required terminal colon and space.
+- A description must immediately follow the colon and space after the type prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
+- A longer commit body may be provided after the short description, providing additional contextual information about the code changes. The body must begin one blank line after the description.
+- A commit body is free-form and may consist of any number of newline separated paragraphs.
+
+# Bibliography
+[1]	“Conventional Branch,” Conventional Branch, 2025. https://conventional-branch.github.io/ (accessed 2025).</br>
+[2]	“Conventional Commits,” Conventional Commits. https://www.conventionalcommits.org/en/v1.0.0/ (accessed 2025).

.github/ISSUE_TEMPLATE/hba_report.md

@@ -0,0 +1,15 @@
+---
+name: HBA report
+about: Report a HBA that is working on the specific enviroment
+assignees: piste-jp-ibm
+lebels: HBA Report
+title: HBA list request
+
+---
+
+**Fill in the informatio of HBA and OS**
+
+| HBA type | Vendor | I/F type (FC, SAS etc) | OS  | LTFS version or commit hash | Note | 
+| -------- | ------ | ---------------------- | --- | --------------------------- | ---- | 
+|          |        |                        |     |                             |      | 
+

README.md

@@ -2,9 +2,13 @@
 ![GH Action status](https://github.com/LinearTapeFileSystem/ltfs/workflows/CentOS7%20Build%20Job/badge.svg?branch=master)
 [![BSD License](http://img.shields.io/badge/license-BSD-blue.svg?style=flat)](LICENSE)
 
-# Linear Tape File System (LTFS)
+# About this branch
 
-Linear Tape File System (LTFS) is a filesystem to mount a LTFS formatted tape in a tape drive. Once LTFS mounts a LTFS formatted tape as filesystem, user can access to the tape via filesystem API.
+This is the `master` branch of the LTFS project. At this time, this branch is used for version 2.5 development. So it wouldn't be stable a little. Please consider to follow the tree on `v2.4-stable` branch if you want to use stable codes.
+
+# What is the Linear Tape File System (LTFS)
+
+The Linear Tape File System (LTFS) is a filesystem to mount a LTFS formatted tape in a tape drive. Once LTFS mounts a LTFS formatted tape as filesystem, user can access to the tape via filesystem API.
 
 Objective of this project is being the reference implementation of the LTFS format Specifications in [SNIA](https://www.snia.org/tech_activities/standards/curr_standards/ltfs).
 
@@ -103,9 +107,91 @@ These instructions will get you a copy of the project up and running on your loc
   | Quantum | LTO8 (Only Half Height) | T.B.D.            |
   | Quantum | LTO9 (Only Half Height) | T.B.D.            |
 
-## Installing
+## LTFS Format Specifications
+
+LTFS Format Specification is specified data placement, shape of index and names of extended attributes for LTFS. This specification is defined in [SNIA](https://www.snia.org/tech_activities/standards/curr_standards/ltfs) first and then it is forwarded to [ISO](https://www.iso.org/home.html) as ISO/IEC 20919 from version 2.2.
+
+The table below show status of the LTFS format Specification
+
+  | Version | Status of SNIA                                                                                                        | Status of ISO                                                        |
+  |:-------:|:---------------------------------------------------------------------------------------------------------------------:|:--------------------------------------------------------------------:|
+  | 2.2     | [Published](http://snia.org/sites/default/files/LTFS_Format_2.2.0_Technical_Position.pdf)                             | [Published as `20919:2016`](https://www.iso.org/standard/69458.html) |
+  | 2.3.1   | [Published](https://www.snia.org/sites/default/files/technical_work/LTFS/LTFS_Format_2.3.1_TechPosition.PDF)          | -                                                                    |
+  | 2.4     | [Published](https://www.snia.org/sites/default/files/technical_work/LTFS/LTFS_Format_2.4.0_TechPosition.pdf)          | -                                                                    |
+  | 2.5.1   | [Published](https://www.snia.org/sites/default/files/technical-work/ltfs/release/SNIA-LTFS-Format-2-5-1-Standard.pdf) | [Published as `20919:2021`](https://www.iso.org/standard/80598.html) |
+
+# How to use the LTFS (Quick start)
+
+This section is for a person who already has a machine with the LTFS installed. Instructions on how to use the LTFS is also available on [Wiki](https://github.com/LinearTapeFileSystem/ltfs/wiki).
+
+## Step1: List tape drives
+
+`# ltfs -o device_list`
+
+The output is as follows. You have 3 drives in this example and you can use "Device Name" field, like `/dev/sg43` in this case, as the argument of ltfs command to mount the tape drive.
+
+```
+50c4 LTFS14000I LTFS starting, LTFS version 2.4.0.0 (10022), log level 2.
+50c4 LTFS14058I LTFS Format Specification version 2.4.0.
+50c4 LTFS14104I Launched by "/home/piste/ltfsoss/bin/ltfs -o device_list".
+50c4 LTFS14105I This binary is built for Linux (x86_64).
+50c4 LTFS14106I GCC version is 4.8.5 20150623 (Red Hat 4.8.5-11).
+50c4 LTFS17087I Kernel version: Linux version 3.10.0-514.10.2.el7.x86_64 (mockbuild@x86-039.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Mon Feb 20 02:37:52 EST 2017 i386.
+50c4 LTFS17089I Distribution: NAME="Red Hat Enterprise Linux Server".
+50c4 LTFS17089I Distribution: Red Hat Enterprise Linux Server release 7.3 (Maipo).
+50c4 LTFS17089I Distribution: Red Hat Enterprise Linux Server release 7.3 (Maipo).
+50c4 LTFS17085I Plugin: Loading "sg" tape backend.
+Tape Device list:.
+Device Name = /dev/sg43, Vender ID = IBM    , Product ID = ULTRIUM-TD5    , Serial Number = 9A700L0077, Product Name = [ULTRIUM-TD5] .
+Device Name = /dev/sg38, Vender ID = IBM    , Product ID = ULT3580-TD6    , Serial Number = 00013B0119, Product Name = [ULT3580-TD6] .
+Device Name = /dev/sg37, Vender ID = IBM    , Product ID = ULT3580-TD7    , Serial Number = 00078D00C2, Product Name = [ULT3580-TD7] .
+```
+
+## Step2: Format a tape
+
+As described in the LTFS format specifications, LTFS uses the partition feature of the tape drive. This means you can't use a tape just after you purchase a tape. You need format the tape before using it on LTFS.
+
+To format a tape, you can use `mkltfs` command like
+
+`# mkltfs -d 9A700L0077`
+
+In this case, `mkltfs` tries to format a tape in the tape drive `9A700L0077`. You can use the device name `/dev/sg43` instead.
+
+## Step3: Mount a tape through a tape drive
+
+After you prepared a formatted tape, you can mount it through a tape drive like
+
+`# ltfs -o devname=9A700L0077 /ltfs`
+
+In this command, the ltfs command will try to mount the tape in the tape drive `9A700L0077` to `/ltfs` directory. Of course, you can use a device name `/dev/sg43` instead.
+
+If the mount process is successfully done, you can access to the LTFS tape through `/ltfs` directory.
+
+You must not touch any `st` devices while ltfs is mounting a tape.
+
+## Step4: Unmount the tape drive
+
+You can use following command when you want to unmount the tape. The ltfs command try to write the current meta-data to the tape and close the tape cleanly.
+
+`# umount /ltfs`
+
+One thing you need to pay attention to here is, that the unmount command continues to work in the background after it returns. It just initiates a trigger to notify the the ltfs command of the unmount request. Actual unmount is completed when the ltfs command is finished.
+
+## The `ltfsee_ordered_copy` utility
+
+The [`ltfsee_ordered_copy`](https://github.com/LinearTapeFileSystem/ltfs/wiki/ltfs_ordered_copy) is a program to copy files from source to destination with LTFS  order  optimization.
+
+It is written in python and it can work with both python2 and python3 (Python 2.7 or later is strongly recommended). You need to install the `pyxattr` module for both python2 and python3.
+
+# Building the LTFS from this GitHub project
+
+These instructions will get a copy of the project up and running on your local machine for development and testing purposes.
+
+## Prerequisites for build
+
+Please refer [this page](https://github.com/LinearTapeFileSystem/ltfs/wiki/Build-Environments).
 
-### Build and install on Linux
+## Build and install on Linux
 
 ```
 ./autogen.sh
@@ -120,7 +206,7 @@ In some systems, you might need `sudo ldconfig -v` after `make install` to load
 
 #### Parameter settings of the sg driver
 
-LTFS uses the sg driver by default. You can improve reliability to change parameters of the sg driver below.
+### Buildable Linux distributions
 
 ```
 def_reserved_size=1048576
@@ -217,9 +303,9 @@ Currently, automatic build checking is working on GitHub Actions and Travis CI.
 
 For Ubuntu20.04 and Debian10, dummy `icu-config` is needed in the build machine. See Issue [#153](https://github.com/LinearTapeFileSystem/ltfs/issues/153).
 
-### Build and install on OSX (macOS)
+## Build and install on OSX (macOS)
 
-#### Recent Homedrew system setup
+### Recent Homebrew system setup
 
 Before build on macOS, you need to configure the environment like below.
 
@@ -230,15 +316,15 @@ export PKG_CONFIG_PATH="/usr/local/opt/icu4c/lib/pkgconfig:/usr/local/opt/libxml
 export PATH="$PATH:$ICU_PATH:$LIBXML2_PATH"
 ```
 
-#### Old Homedrew system setup
+### Old Homebrew system setup
 Before build on OSX (macOS), some include path adjustment is required.
 
 ```
 brew link --force icu4c
 brew link --force libxml2
 ```
 
-#### Building LTFS
+### Building LTFS
 On OSX (macOS), snmp cannot be supported, you need to disable it on configure script. And may be, you need to specify LDFLAGS while running configure script to link some required frameworks, CoreFundation and IOKit.
 
 ```
@@ -250,13 +336,13 @@ make install
 
 `./configure --help` shows various options for build and install.
 
-#### Buildable systems
+#### Buildable macOS systems
 
   | OS            | Xcode  | Package system | Status      |
   |:-:            |:-:     |:-:             |:-:          |
   | macOS 10.14.6 | 11.3   | Homebrew       | Probably OK |
 
-### Build and install on FreeBSD
+## Build and install on FreeBSD
 
 Note that on FreeBSD, the usual 3rd party man directory is /usr/local/man. Configure defaults to using /usr/local/share/man.  So, override it on the command line to avoid having man pages put in the wrong place.
 
@@ -269,9 +355,10 @@ make install
 
 #### Buildable versions
 
-  | Version | Arch    | Status      |
-  |:-:      |:-:      |:-:          |
-  | 11      | x86_64  | OK          |
+  | Version | Arch    | Status                         |
+  |:-------:|:-------:|:------------------------------:|
+  | 11      | x86\_64 | OK - Not checked automatically |
+  | 12      | x86\_64 | OK - Not checked automatically |
 
 ### Build and install on NetBSD
 
@@ -284,11 +371,11 @@ make install
 
 #### Buildable versions
 
-  | Version | Arch    | Status      |
-  |:-:      |:-:      |:-:          |
-  | 8.1     | amd64   | OK          |
-  | 8.0     | i386    | OK          |
-  | 7.2     | amd64   | OK          |
+  | Version | Arch  | Status                         |
+  |:-------:|:-----:|:------------------------------:|
+  | 8.1     | amd64 | OK - Not checked automatically |
+  | 8.0     | i386  | OK - Not checked automatically |
+  | 7.2     | amd64 | OK - Not checked automatically |
 
 ## Contributing
 

autogen.sh

@@ -46,6 +46,6 @@ else
 	libtoolize
 fi
 
-autoconf
-autoheader
-automake --add-missing --copy
+autoconf 			|| echo "Ignore warning"
+autoheader			|| echo "Ignore warning"
+automake --add-missing --copy	|| echo "Ignore warning"