<div dir="ltr"><div>Hey Jurgen,</div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">
> 6 month dev (including ~1 month freeze) -> release -> 1 month post release<br>> freeze -> release a bug fix release if needed -> move on.<br><br></div>7 months is not good as that would move the schedule into undesireable areas<br>
(like holidays) over time.</blockquote><div><br></div><div>I understand.  We could go with 4 (1 month freeze) 1 month post release freeze.  There only adds the extra month on the end to fix anything that might come up after that is bad. </div>
<div>Â <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><br>> Packaging for each platform is up to that maintainer but that should be<br>
> automated as much as possible really otherwise making releases is too hard.<br><br></div>Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows<br>maintainers and they all agree with me - I think they already have don't a good<br>
job to automated it a good deal, but it's still not fully automated and<br>therefore they are not comfortable with doing it again and again. Â ;)<br><div class=""><div class="h5"><br></div></div></blockquote><div><br>
</div>
<div>Of course I don't want to create heaps of work for people but if cutting a release is a hard process then it really creates a sticky point in all this. Â We need to be able to release as easy as possible when ever we need, be that be weekly, monthly, yearly. Â It really should just be 1) point at branch 2) package. Â Even if the website lags behind.</div>
<div><br></div><div>What are the main problems/stoppers with having it fully automated? Â Do we need resources, VMs for each platform, etc?</div><div><br></div><div>- Nathan</div><div>Â <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5"><br><br>Jürgen<br><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><br></div></div></blockquote></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 19, 2014 at 8:11 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 Nathan,<br>
<div class=""><br>
On Thu, 19. Jun 2014 at 19:32:17 +1000, Nathan Woodrow wrote:<br>
> I'm not sure I really like the "just make new releases and avoid bug fixe<br>
> releases" kind of thinking. Â There are some places that can't roll out a<br>
> whole new release due to possible bugs from major new features, and given how<br>
> fast we move this can cause some real issues.<br>
<br>
</div>I said "compromise". Â I'm sure that I don't like it. Â It implies that it's not<br>
optimal. But I didn't have a better idea - and apparently I also miss all the<br>
new stuff in this discussion - feels like a dejavu.<br>
<div class=""><br>
> We don't even have to bug fix until next release just do it for a short (1<br>
> month) period after the release, so you're dev cycle is like this:<br>
<br>
</div>That means packaging again and again - and that's what I want to avoid.<br>
<br>
But I thought about an automated release build when there are new commits in<br>
the release branch and a automated bugfix release after a some given period of<br>
time without any new commits.<br>
<br>
That period should be long enough to make it likely that potentially newly<br>
introduced issues by the bugfix are spotted and fixed (thereby restarting the<br>
period) before its over.<br>
<br>
And that without further doing except for the backported commit. Â But I didn't<br>
find time to do that yet.<br>
<div class=""><br>
> 6 month dev (including ~1 month freeze) -> release -> 1 month post release<br>
> freeze -> release a bug fix release if needed -> move on.<br>
<br>
</div>7 months is not good as that would move the schedule into undesireable areas<br>
(like holidays) over time.<br>
<div class=""><br>
<br>
> Packaging for each platform is up to that maintainer but that should be<br>
> automated as much as possible really otherwise making releases is too hard.<br>
<br>
</div>Um, but I've spoken to most of the debian, ubuntu, ubuntugis, windows<br>
maintainers and they all agree with me - I think they already have don't a good<br>
job to automated it a good deal, but it's still not fully automated and<br>
therefore they are not comfortable with doing it again and again. Â ;)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
Jürgen<br>
<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>