Better testing of tagged tars

[Ralf Jung]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

> Now let's assume we would have the packages out in the wild for
> 4.11 prior to release. The version information reported by DrKonqui
> is 4.11.0 - no matter which tarball is currently running. At the
> same time there's still an RC out (4.10.98). Which means we cannot
> yet enable the version field 4.11.0 as that could result in
> incorrect data from bug reporters (we all know our users, it would
> end up in you have to ask each time whether it's really, really
> 4.11.0). No 4.11.0 in the versions means that the DrKonqui version
> matching magic doesn't work and the bug ends up as unspecified, but
> says in the initial comment 4.11.0. That creates additional work as
> all bugs reported like that needs to be re-triaged once 4.11.0 is
> released.
As far as I understand you, the issue here is that there are several
"4.11.0" versions. If tarballs were handled like git tags, where
nothing can be changed after they are created, and a re-spin would get
a new version number, then it would again be clear against which state
of the application the bug was reported.

> Would a solution like introducing dedicated versions help here:
> maybe. It would require each developer working with such issues to
> track the release team mailing list to get the notification of a
> respin, the new version number and the matching git hash. Tricky
> and again with lots of work.
Just to be sure I understand this properly: Currently, there are no
bug reports *at all* against these pre-release tarballs - all bugs are
to be reported to the release team (i.e. this list)? And only after
the tarballs are official, bugreports may be created for this release,
so the developers know that bugzilla version numbers always refer to
the ultimately released tarballs?

A solution which would not require developers to follow the release
list or anything, while still permitting bugreports against
pre-releases, might be to
* always use new version numbers for re-spinned tarballs (after all,
  this should really not happen that often)
* add git tags and bugzilla versions at the same time as tarballs are
  created
A developer now just has to do "git fetch" after getting a bugreport
to find out the exact git hash the user used. git tags should be added
in any case, so that should not be any additional work. I do not know
how bugzilla versions are handled currently, do they have to be added
manually? Maybe a git hook to add bugzilla versions for tags called
"v\d+\.\d+\.\d+" would be appropriate (if possible). Finally, the
version number DrKonqui uses could also be derived from the git tag
(maybe by creating the tarball after tagging, so that the script which
does the tar-magic can get he version number from git?). This should
prevent mismatches between the Bugzilla and DrKonqui version numbers.

Disclaimer: I am neither a KDE developer nor a packager (though I do
create my own local Debian packages from the KDE upstream git
sources), just a user and occasional contributor who is interested in
KDE getting better :D (and trying to find a good place to contribute
which is compatible with university...)

Kind regards,
Ralf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRGomcAAoJEEAdTZ0mjB1W6GYH/2THazuw1y3HGD+CGcugdJYa
ViuC+MUjpe66oeMhBozJ2xsTrTdeBH9Ny8hvj9d1WAYqG5M61so57+Dp3OeAKD0f
a3sOjNZq9ZCb7ymO1OteOBvOVjFZVkm8d2lowjojF6ED3ZZwDOiSO/FoSRYvJDsa
PLp2kkv7uOP06zopwiFT2OVtz20F2K2hvJyS1kVxw7mBI+WpaEPeHGEC7ZOq4ql0
w7HWnzil3xxeba90FEWJX6zlvSP5HRRz4bfAkAgYTu890ER/zQCDYVoaX8gAtmFw
CjsCCpBw/qL4OqjuCRz1hgHa2cypotqFlbjucDaZF+iswbGilsaAMEJPwP5JfGA=
=PzJ4
-----END PGP SIGNATURE-----