Since the original email in this thread came from the Chakra-Project, and we asked if the Arch Linux devs would co sign and send, seems it is needed we explain/respond one more time.<div><br></div><div>At Chakra-Project we do not feel there is any need to change the way the release is handled, 4-5 days in between tar tagging, and announced release is a very sensible work flow.</div>
<div>We just feel those 4-5 days should be better utilized for those distro's that have no issues getting the tars build in one or two days. </div><div><br></div><div>It seems now there are two objections regarding making these builds available to early testers:</div>
<div>1) There is no need for testing, early tars are only to be used to make sure they build correctly.</div><div>2) Early testers will create wrong bug reports for non-existing kde versions.</div><div><br></div><div>Regarding point 1, why not use this time for additional testing? For me personally, I've been building KDE for the Chakra-Project for almost 3 years, in that time, almost any early tar some issues were reported to the release-team, issues were gladly accepted by that team, but what was reported was maybe 50 % build issues, the other 50% was bugs found on running the early builds. Seems counter-intuitive to state, there is no need or use in this time period to test. </div>
<div><br></div><div>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.</div>
<div>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? </div>
<div><br></div><div>Anke Boersma</div><div>abveritas@chakra-project<br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 9:11 AM, Torgny Nyblom <span dir="ltr"><<a href="mailto:nyblom@kde.org" target="_blank">nyblom@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="HOEnZb"><div class="h5">On Monday 11 February <a href="tel:2013%2000.24.51" value="+12013002451">2013 00.24.51</a> Albert Astals Cid wrote:<br>
> El Diumenge, 10 de febrer de 2013, a les 08:15:40, Martin Gräßlin va<br>
escriure:<br>
> > On Saturday 09 February 2013 23:08:50 Albert Astals Cid wrote:<br>
> > > Of course another option is lifting the requirement for the pre-packages<br>
> > > not being publicly available, after all the packages will most likely be<br>
> > > the real thing, so if everyone agrees it is better lifting this<br>
> > > requirement, we can do it, the fact that *I* personally like it the way<br>
> > > it is doesn't mean it's the better way.<br>
> ><br>
> > With my bugzilla user hat on I'm afraid of that. It would mean we get bug<br>
> > reports for an unreleased version. That's bound to create confusion - we<br>
> > would not be able to trust the version field any more. In case of a<br>
> > re-spin<br>
> > it will get just worse - different tar balls with the same version<br>
> > information.<br>
><br>
> Another option is just release the tarballs once and don't do any respin at<br>
> all. After all we have <a href="http://build.kde.org" target="_blank">build.kde.org</a> that builds the stuff so we are kind of<br>
> "confident" it builds, if anything fails to build or something big is found<br>
> we can add it as a note (+ kde-packager mail) to the info page like we did<br>
> with the nepomuk thing for 4.10.0 <a href="http://kde.org/info/4.10.0.php" target="_blank">http://kde.org/info/4.10.0.php</a><br>
><br>
> That seems like a "sensible" compromise to me.<br>
><br>
> * We release only one tarball<br>
> * Distros still can pick up build or bugfixes (as they will do anyway<br>
> either we include them in a respin tarball or not)<br>
> * We can "silently" release the *only one* tarball a few days in advance to<br>
> get distros to package for the release day<br>
><br>
> Comments?<br>
<br>
</div></div>Sounds like a sensible alternative.<br>
<br>
Perhaps open the door for a patch level release (ex: 4.10.0.1) if something<br>
really important comes up.<br>
<br>
/Regards<br>
<span class="HOEnZb"><font color="#888888">Torgny<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div>