All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Tanska, Kinga" <kinga.tanska@intel.com>
To: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>
Cc: "jes@trained-monkey.org" <jes@trained-monkey.org>
Subject: Proposal of changing generating version of mdadm
Date: Wed, 20 Oct 2021 12:43:04 +0000	[thread overview]
Message-ID: <MN2PR11MB3776740E926BE3FE37C8B6E389BE9@MN2PR11MB3776.namprd11.prod.outlook.com> (raw)

Hi,

recently we diagnosed few issues with 'mdadm -version' output.
Main problem is that end output varies on few conditions. We come with
simplified proposal. First let's describe current schema:

mdadm - version - date - extraversion
(example: mdadm - v4.2-rc2 - 2021-08-02 - extraversion)

or

mdadm - version - date
(example: mdadm - v4.2-rc2 - 2021-08-02).

VERSION could be taken from code (see ReadMe.c:31), but when git is
installed and .git directory is available in mdadm workspace, version
is replaced with output from # git describe HEAD command. It is assumed
that git command should return last tag from repo, which should contain
information about last release. This might not be true, especially if user
uses tags to mark internal milestones or custom mdadm spins.

The second problem is DATE, which corresponds to date of last release.
When few patches are picked onto HEAD date is not reliable. In my opinion
DATE is not needed. Usually, packages do not contain this element, e.g.
-	# git --version
		git version 2.27.0
-	# gcc --version
		gcc (GCC) 8.3.1 20191121 (Red Hat 8.3.1-5)
-	# yum --version
		4.2.23

To make it const and reliable, I propose removing DATE and always
use VERSION from code. VERSION shall keep general release information.
I would like to move the changeable elements into EXTRAVERSION. This
field will respect following conditions:
-	user definition first
       	(by respecting EXTRAVERSION=xxx during compilation)
-	if not defined by user, result of # git describe HEAD
-	else empty.

Example output:
mdadm - version - extraversion (example: mdadm - v4.2-rc2 - extraversion).
Thanks for any opinion about this proposition.

Regards,
Kinga Tanska

             reply	other threads:[~2021-10-20 12:43 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20 12:43 Tanska, Kinga [this message]
2021-11-02 15:53 ` Proposal of changing generating version of mdadm Jes Sorensen
     [not found]   ` <MN2PR11MB3776D436514419C88FD67B61899F9@MN2PR11MB3776.namprd11.prod.outlook.com>
2021-11-22 13:04     ` Tanska, Kinga
2022-01-19 13:57     ` Tanska, Kinga

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MN2PR11MB3776740E926BE3FE37C8B6E389BE9@MN2PR11MB3776.namprd11.prod.outlook.com \
    --to=kinga.tanska@intel.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-raid@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.