(Deadline) Looking to Learn about Tmux For University Project

30 views
Skip to first unread message

Shrey Patel

unread,
Feb 13, 2024, 2:39:31 AM2/13/24
to tmux-users
Hello, 

My name is Shrey Patel and i'm a University of Waterloo student. As one of our final year projects we are required to create a group of 5 and select a Open Source Project and write a report on it's release pipeline specifically focusing on Integration, Build, Deployment and Monitoring, and then finding limitations on it and creating a plan for improvement. We have decided to do it on Tmux!

Our report is due next Monday and we would love to get some more information on how each of these phases work and perhaps even have our document reviewed before submitting it for marking. Would someone who has knowledge on these topics be able give us an overview of the release pipeline, we tried reading over the documentation and are a bit confused. We have a bit of knowledge in this space but not a lot and could use someone's help from the community! 

Here are some questions that my group members have: 
1) The documentations says git is synced with CVS every 15 minutes using "git cvsimport". Where can I find the script that handles the sync logic?
2) The Travis CI was last run 3 years ago. Is the pipeline still used? What's the main purpose of it for this project?

  1. The Travis CI was last run 3 years ago. Is the pipeline still used? What's the main purpose of it for this project?
    2. The Travis CI was last run 3 years ago. Is the pipeline still used? What's the main purpose of it for this project?
  1. The Travis CI was last run 3 years ago. Is the pipeline still used? What's the main purpose of it for this project?
Also here are just some rough notes that I copied from our groups ideation page.... (please note that these are super rough and probably no where near close to how it actually works) but we could use a mentor to help us understand where we are right and where we are wrong and also what we are missing. 


2.3 Integration Phase

  • Detailed description of the Integration phase

  • How code changes are integrated into the main branch

  • Example artifacts or URLs to demonstrate this phase

  • Specific tools and practices used by the OSS team in this phase


  • tmux is part of the OpenBSD base system and OpenBSD CVS is the primary source repository. It is fine to develop and submit code changes with a GitHub PR, but the final form will be a patch file which is applied to OpenBSD CVS.

    • All pull requests are reviewed and committed by tmux creator, Nicholas Marriott, and maintainer, Thomas Adam (tmux versioning and development (google.com)).

    • The "tmux-openbsd" repository is actually handled by "git cvsimport" running at 15 minute intervals, so a commit made to OpenBSD's tmux CVS repository will take at least that long to appear in this git repository (see tmux/SYNCING at 3.3a · tmux/tmux (github.com)).

    • section/diagram to describe what cvs is and what is does

  • github workflow: has only 1 workflow .github/workflows/lock.yml. This workflow automatically locks issues after 30 days of inactivity and locks PRs after 60 days of inactivity.

2.4 Build Phase

  • Detailed description of the Build phase

  • Process of turning code changes into executable artifacts

  • Example artifacts or URLs to illustrate the build process

  • Tools and techniques used in the build phase


  • Works on Unix-like Systems (Linux/macOS)

  • tools

    • GNU Autotools (draw a diagram probably, according to project detail)

      • The build phase in the project utilizes the GNU Autotools build system, with configure.ac defining configurations for the configure script. Conditional checks in configure.ac adapt the build to different environments. 

      • What is it

        • Autoconf

          • generate configure script

            • The configure script examines the target environment to determine the presence of necessary compilers, libraries, and system features.

            • It then creates a Makefile and possibly other configuration files, tailored to the system, which are used to compile and install the software

          • file: configure.ac -> confiure

        • Automake

          • generate Makefile.in from Makefile.am

            • These .am files are written by the developer and include instructions on how to build the program (e.g., what source files and executables are involved). Automake takes care of creating portable Makefile templates that follow the GNU Coding Standards.

            • Makefile.in are used by configure to generate Makefile

          • file: Makefile.am -> Makefile.in

        • Libtool (not used by tmux)

          • Purpose: To manage the creation and use of static and shared libraries

    • Travis CI

  • Build from source:

    • sh autogen.sh

      • Prepares the build system by generating necessary configuration files. (configure)

      • steps

        • aclocal

          • generate macos (used by autoconf to generate the configure script)

        • automake

          • processes Makefile.am files to generate Makefile.in templates. 

            • These templates are then used by the configure script (generated by autoconf) to produce the final Makefiles tailored for the building environment.

        • autoreconf

          • autoreconf is a tool that runs autoconf, automake, aclocal, and other Autoconf-generated scripts in the correct order to update the configuration scripts and files in a project.

    • ./configure

      • for mac have to run ./configure --enable-utf8proc instead (undocumented)

      • Configures the project based on the system environment and user options

    • make

      • Compiles the source code and builds the project according to the configured settings

  • special builds:

    • The project supports building with different configurations, such as static builds, builds with musl instead of glibc, and more. These are specified by setting the BUILD environment variable before running the build scripts. For example, to build with musl, you would set BUILD=musl.

      • note: musl and glibc are different implementations of c

    • The Travis CI configuration file .travis.yml and the build scripts .github/travis/build.sh and .github/travis/build-all.sh detail automated build processes for various configurations and platforms.

  • dependencies:

    • tmux depends on libevent and ncurses. The build process checks for these dependencies and attempts to link against them.

  • env:

    • The build process adapts to different operating systems and environments, as seen in the Travis CI configurations and the conditional checks in configure.ac and Makefile.am

  • some links:

2.5 Deployment Phase

  • Detailed description of the Deployment phase

  • How the built software is deployed to production or staging environments

  • Example artifacts or URLs showcasing deployment steps

  • Deployment strategies and tools used by the OSS team


  • tmux currently sees a new release approximately every six months - the same schedule as OpenBSD, around May and October. This means that the GitHub releases contain roughly the same code as OpenBSD releases (but not necessarily exactly the same).

  • The release process consists of a branch from which one or more release candidates are produced for testing, until the final release is published and the branch removed.

  • tmux/SYNCING at 3.3a · tmux/tmux (github.com)

    • Update and commit README and CHANGES.

    • Make sure configure.ac has the new version number

    • Tag with:

   % git tag -a 2.X    where "2.X" is the next version.

   Push the tag out with:

   % git push --tags

Click the "Add release notes", upload the tarball and add a link in the description field to the CHANGES file.

  • Clone the tmux.github.io repository, and change the RELEASE version in the  Makefile.  Commit it, and run 'make' to replace %%RELEASE%%. Push the result out.

  • Change version back to master in configure.ac.

2.6 Monitoring Phase

  • Detailed description of the Monitoring phase

  • Methods for tracking the performance and health of the software post-deployment

  • Example artifacts or URLs that represent monitoring activities

  • Monitoring tools and practices in place

  • logging

    • After building, you can run tmux with -v or -vv for verbose logging, which is useful for debugging.

    • Use a log.c file

  • User report manually

    • github issue

    • email them


Thanks,
Shrey Patel
Reply all
Reply to author
Forward
0 new messages