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