-----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----- _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
