<div dir="ltr"><br>BTW, I also give my +1 to what Aaron has stated in his mails.<br><br><br><div class="gmail_quote">On Wed, Sep 10, 2008 at 6:07 PM, Sebastian Kügler <span dir="ltr"><<a href="mailto:sebas@kde.org">sebas@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">For what it's worth, Aaron describes quite accurately what I have in mind (but<br>
which I wasn't really able to communicate effectively to everyone), so thanks<br>
for plugging into my brain and channeling the mess nicely into k-c-d :)<br>
<div class="Ih2E3d"><br>
On Tuesday 09 September 2008 19:47:30 Aaron J. Seigo wrote:<br>
</div><div><div></div><div class="Wj3C7c">> * Feature development happens in "hot" branches; let's call them Spring<br>
> branches (new growth =)<br>
><br>
> * Spring branches are merged when features are "ready" into a Summer<br>
> branch. devel that doesn't require its own branch (small scope changes)<br>
> happens in this merge branch as well. development may continue in Summer<br>
> regardless of what's going on. anyone can create a Spring branch at any<br>
> time, new development can happen in Summer at any time; this combination<br>
> replaces the need for playground/.<br>
><br>
> * Summer goes through rapid cycles of "1-2 weeks of devel and Spring<br>
> merges, pause, up to one week of stabilization or until we're happy with<br>
> it" at which point it merges into KDE's mainline, or "Autumn", branch. this<br>
> is actually pretty close to what we already do in the middle parts of the<br>
> feature devel part of a cycle.<br>
><br>
> * Autumn branch should be in a relatively good situation due to the Summer<br>
> cycle. it won't be perfect, but it'll be better than Spring or Summer<br>
> branches. all other KDE developers would likely be using the Autumn branch,<br>
> and would be at most 2-3 weeks behind Plasma developers, though usually<br>
> less; this means bugs they notice are likely to still be useful to the<br>
> Plasma team. as nearly all Plasma devel is done by people who contribute<br>
> regularly to Plasma and would therefore be following the Summer branch,<br>
> loss of patches due to small lag would be near-zero.<br>
><br>
> * When KDE branches for release (call this the Winter branch), we will put<br>
> an extra focus on bug fixing as we normally do but feature development can<br>
> continue in Spring and Summer. bug fixes in Summer will be merge into<br>
> Winter, just as we backport fixes now from trunk to 4.1 only a bit more<br>
> aggressively pre-release (betas and RCs).<br>
<br>
</div></div>[...]<br>
<div class="Ih2E3d"><br>
> any of the above could change in the future, and that may shift things yet<br>
> again for us. at least with the "always Summer" approach we could shift<br>
> back to how things are now really quite easily, while we are simply stuck<br>
> with the current system no matter what.<br>
--<br>
</div><div><div></div><div class="Wj3C7c">sebas<br>
<br>
 <a href="http://www.kde.org" target="_blank">http://www.kde.org</a> | <a href="http://vizZzion.org" target="_blank">http://vizZzion.org</a> |  GPG Key ID: 9119 0EF9<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br><br>
</div>