Better testing of tagged tars

[Albert Astals Cid]

El Dimarts, 12 de febrer de 2013, a les 19:27:49, Ralf Jung va escriure:
> -----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.

That is *mostly* true, we never change released tarballs.

> > 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)

That would mean using versions with 4 numbers, which i would like to totally 
avoid.

Cheers,
  Albert

> * 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-----
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team