<div dir="ltr"><div><div>Nightly builds (or weekly snapshots for that matter) are very different from a publicized, pre-release preview build. With a prepared pre-release preview, users are at least expecting that basic functioning will work, that's something  the nightly builds simply can't guarantee by the nature of what those are. Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released.<br>
<br></div>It also helps channel what your describing as noise (i.e. users 
running into problems) into a better managed call for people to test and
 report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and "invalid" RTFM cases) _before_ you release your final version via a pre-release social media and news site "try this pre-release build" :)<br>
<br></div>It's really more a matter of presentation to the users than of actual work. As you point out Jef, you guys already have the infrastructure that produces weekly standalone builds, and daily packages.<br><div>
<br>Math<br><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E. <span dir="ltr"><<a href="mailto:jef@norbit.de" target="_blank">jef@norbit.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mathieu,<br>
<div class=""><br>
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:<br>
> That reminds me of someone mentioning in a ticket of a 2.0 issue resolved<br>
> against qgis 2.1 that he'd wait (angrily?) having fix backported into a<br>
> (mythical) 2.0.x update rather than him moving to 2.2 and having to deal<br>
> with possible regressions. I was thinking at the time that this sounds to<br>
> me like a flawed behavior by some QGIS users, an egg or chicken situation.<br>
> How are regressions fixed if users are not doing their parts in uncovering<br>
> and reporting them.<br>
><br>
> That led me to think there might be a very low-cost, high reward behavior<br>
> QGIS could adopt: 4, or 2, weeks before the release date, {beta,release<br>
> candidate,tech preview,etc.} builds (from master, no need to branch out<br>
> really) are pushed out to osgeo4w & linux and quite loudly advertised (blog<br>
> posts, social media, etc.) to get as many users as possible to test drive<br>
> it. The users' feedback would enrich the 4-weeks period when developers are<br>
> to be focused on bug-fixing only.<br>
><br>
> Thoughts? Was that already suggested and declined?<br>
<br>
</div>What's the difference to the nightly builds and the weekly standalone snapshot<br>
for Windows - except for the noise of course?<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jürgen<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31<br>
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50<br>
Software Engineer         D-26506 Norden               <a href="http://www.norbit.de" target="_blank">http://www.norbit.de</a><br>
QGIS PSC member (RM)      Germany                      IRC: jef on FreeNode<br>
<br>
--<br>
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH<br>
Rheinstrasse 13, 26506 Norden<br>
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div>