But this is the exact point I'm trying to make. Educate early testers to report any issues they find within the distro. We have done that for 3 years, and is well known and accepted by our testers (this includes testing all beta and rc builds for Chakra). <div>
It is just a 3-4 day period, many early test runs pick up issues that can be distro specific build errors. True bugs can be relayed to the release team. Once a version is final, then official bug reports can be filed again.</div>
<div>But if any KDE dev here feels the negatives far outweigh any issue fixes before a new release is final, then there will be no other way for us but to stop building early tars, since there is just no way to hide our early builds on the server.<br>
<br><div class="gmail_quote">On Tue, Feb 12, 2013 at 12:32 PM, Martin Gräßlin <span dir="ltr"><<a href="mailto:mgraesslin@kde.org" target="_blank">mgraesslin@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tuesday 12 February 2013 11:57:21 Anke Boersma wrote:<br>
> As to point 2, having a much clearer set policy, that any distro can convey<br>
> to their testers must surely result in less badly placed bug reports.<br>
> Testers who have to read documentation just to be able to use a certain<br>
> repo, are far more likely to also read about reporting issues correctly.<br>
> Any users that builds KDE from git, those don't result in often misplaced<br>
> bug-reports? Or any user who really has no idea what version they are<br>
> running, just choose one for a bug report, isn't that more likely to happen<br>
> then an educated testers filing an incorrect bug report?<br>
</div>The problem here is DrKonqui and the automatic version matching. For someone<br>
running master it does not matter. Most products have a version field called<br>
"git master" and while DrKonqui is not able to match it, the users normally<br>
tell so.<br>
<br>
Now let's assume we would have the packages out in the wild for 4.11 prior to<br>
release. The version information reported by DrKonqui is 4.11.0 - no matter<br>
which tarball is currently running. At the same time there's still an RC out<br>
(4.10.98). Which means we cannot yet enable the version field 4.11.0 as that<br>
could result in incorrect data from bug reporters (we all know our users, it<br>
would end up in you have to ask each time whether it's really, really 4.11.0).<br>
No 4.11.0 in the versions means that the DrKonqui version matching magic<br>
doesn't work and the bug ends up as unspecified, but says in the initial<br>
comment 4.11.0. That creates additional work as all bugs reported like that<br>
needs to be re-triaged once 4.11.0 is released.<br>
<br>
Now the problem of re-spin tarballs. Let's assume we have a crash in KWin<br>
(driver related) not present in the RC, but in the final tars. We fix it<br>
(based on general assumptions on what might have caused the crash - yeah<br>
driver bugs for which you don't have the hardware tend to end up like that)<br>
and cause the release team to do a respin. But we still get the crash reports.<br>
What does it mean now? Issue not fixed? User not yet updated the package?<br>
Looking at backtrace doesn't help - if it is driver related they look all<br>
different for each distribution.<br>
<br>
Would a solution like introducing dedicated versions help here: maybe. It<br>
would require each developer working with such issues to track the release<br>
team mailing list to get the notification of a respin, the new version number<br>
and the matching git hash. Tricky and again with lots of work. Also<br>
problematic once the final version is created because the version information<br>
must be exactly the same otherwise Dr.Konqui magic doesn't work.<br>
<br>
For me as the product maintainer at the point between last RC and final<br>
release it's extremely important to get correct information as if there is a<br>
crash introduced after last RC, I would have to run to the release team to<br>
call stop.<br>
<br>
I can understand the need for distros to put out the packages for greater<br>
usage early. But from my developer perspective I must say that I would not<br>
want bugreports for this intermediate state. I also don't think that it in<br>
general would help much to have bug reports for this special stage. It should<br>
be only to find showstoppers and for that I doubt our bugzilla is suited at<br>
the moment anyway (c.f. the Plasma/Qt/Gentoo issue which went unnoticed on<br>
this list).<br>
<br>
That said: it would be much more help if users would test the betas and RCs<br>
more - I think from our perspective that's more help.<br>
<br>
--<br>
Martin Gräßlin<br>_______________________________________________<br>
release-team mailing list<br>
<a href="mailto:release-team@kde.org">release-team@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/release-team" target="_blank">https://mail.kde.org/mailman/listinfo/release-team</a><br>
<br></blockquote></div><br></div>