El Dimarts, 12 de febrer de 2013, a les 18:32:32, Martin Gräßlin va escriure: > On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote: > > As to point 2, having a much clearer set policy, that any distro can > > convey > > to their testers must surely result in less badly placed bug reports. > > > > Testers who have to read documentation just to be able to use a certain > > > > repo, are far more likely to also read about reporting issues correctly. > > Any users that builds KDE from git, those don't result in often misplaced > > bug-reports? Or any user who really has no idea what version they are > > running, just choose one for a bug report, isn't that more likely to > > happen > > then an educated testers filing an incorrect bug report? > > The problem here is DrKonqui and the automatic version matching. For someone > running master it does not matter. Most products have a version field > called "git master" and while DrKonqui is not able to match it, the users > normally tell so. > > 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.
That sounds like we need better tools in the bugzilla side so users can screw it up less. Cheers, Albert > > Now the problem of re-spin tarballs. Let's assume we have a crash in KWin > (driver related) not present in the RC, but in the final tars. We fix it > (based on general assumptions on what might have caused the crash - yeah > driver bugs for which you don't have the hardware tend to end up like that) > and cause the release team to do a respin. But we still get the crash > reports. What does it mean now? Issue not fixed? User not yet updated the > package? Looking at backtrace doesn't help - if it is driver related they > look all different for each distribution. > > 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. Also > problematic once the final version is created because the version > information must be exactly the same otherwise Dr.Konqui magic doesn't > work. > > For me as the product maintainer at the point between last RC and final > release it's extremely important to get correct information as if there is a > crash introduced after last RC, I would have to run to the release team to > call stop. > > I can understand the need for distros to put out the packages for greater > usage early. But from my developer perspective I must say that I would not > want bugreports for this intermediate state. I also don't think that it in > general would help much to have bug reports for this special stage. It > should be only to find showstoppers and for that I doubt our bugzilla is > suited at the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went > unnoticed on this list). > > That said: it would be much more help if users would test the betas and RCs > more - I think from our perspective that's more help. > > -- > Martin Gräßlin _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
