From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2 1/6] squashfs: bump version to e38956b92f738518c29734399629e7cdb33072d3
Date: Thu, 12 Apr 2018 21:01:37 +0200 [thread overview]
Message-ID: <20180412210137.0db909ac@windsurf> (raw)
In-Reply-To: <20180412205157.3cb10c44@gmx.net>
Hello,
On Thu, 12 Apr 2018 20:51:57 +0200, Peter Seiderer wrote:
> > However, I don't think it is interesting to have the new version
> > (especially as it is a sha1) in the commit title. Having the title
> > read just "squashfs: bump version" is IMHO enough. My rev-by still
> > stands, though.
>
> Matter of taste....and looking at a packet history of e.g.:
>
> squashfs: bump version
> squashfs: bump version
> squashfs: bump version
> [...]
>
> is a little boring and makes every patch search or patch reference
> more difficult....
We normally like to have the version number in the commit title indeed,
like "foo: bump to version 1.2.0". For Git SHA1s, it is a bit more
questionable whether it is really useful or not. Indeed, while with
"bump to version 1.2.0" you can easily say "ah, yes good, they bumped
to that one", with "bump to version
e38956b92f738518c29734399629e7cdb33072d3", you're unlikely to be able
to say "aah very good, they are up to this commit, so they must have
this great new feature". Or if you are, and now all the SHA1s of a
project Git repository, you really have a *very* good memory.
That being said, it doesn't hurt, and we could say that for the sake of
consistency, we should do it for all packages, regardless of whether
they have human-readable version numbers or random SHA1s.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-04-12 19:01 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-09 20:04 [Buildroot] [PATCH v2 1/6] squashfs: bump version to e38956b92f738518c29734399629e7cdb33072d3 Peter Seiderer
2018-04-09 20:04 ` [Buildroot] [PATCH v2 2/6] zstd: add host libzstd support Peter Seiderer
2018-04-11 21:19 ` Yann E. MORIN
2018-04-12 3:33 ` Baruch Siach
2018-04-12 18:30 ` Peter Seiderer
2018-04-12 18:47 ` Yann E. MORIN
2018-04-09 20:04 ` [Buildroot] [PATCH v2 3/6] squashfs: add host zstd support Peter Seiderer
2018-04-11 21:20 ` Yann E. MORIN
2018-04-09 20:04 ` [Buildroot] [PATCH v2 4/6] fs/squashfs: add " Peter Seiderer
2018-04-09 20:04 ` [Buildroot] [PATCH v2 5/6] zstd: add libzstd support Peter Seiderer
2018-04-11 21:24 ` Yann E. MORIN
2018-04-12 18:45 ` Peter Seiderer
2018-04-09 20:04 ` [Buildroot] [PATCH v2 6/6] squashfs: add zstd support Peter Seiderer
2018-04-11 21:27 ` Yann E. MORIN
2018-04-12 18:31 ` Peter Seiderer
2018-04-11 21:12 ` [Buildroot] [PATCH v2 1/6] squashfs: bump version to e38956b92f738518c29734399629e7cdb33072d3 Yann E. MORIN
2018-04-12 18:51 ` Peter Seiderer
2018-04-12 19:01 ` Thomas Petazzoni [this message]
2018-04-12 21:43 ` Thomas Petazzoni
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=20180412210137.0db909ac@windsurf \
--to=thomas.petazzoni@bootlin.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox