<div dir="ltr"><div>This is fine, but we really need a shared calender. I recall we started on a google calender? I'd be fine with taking up maintenance for it.<br><br></div>Phabricator also has a calender app, but it seems to be incomplete yet, and it looks like they are going to make it compatible with google calender in the future: <a href="https://secure.phabricator.com/project/board/542/">https://secure.phabricator.com/project/board/542/</a><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 2:30 PM, Boudewijn Rempt <span dir="ltr"><<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I've been thinking about this a lot over the past weeks, and I want to<br>
propose a new release strategy because I don't think the current one<br>
with a master branch and a stable branch is working.<br>
<br>
There are at least the following current problems that I see:<br>
<br>
* I need to make builds of both branches: stable builds and development<br>
builds. This is more work than I can handle.<br>
<br>
* People need to backport bug fixes to the stable branch. This is not<br>
happening, and I cannot handle the backporting of fixes myself anymore.<br>
<br>
* Backporting features that were based on master (like soft-proofing)<br>
is pretty hard now.<br>
<br>
* People are not building and testing the 3.0 branch -- everyone who<br>
builds themselves is doing so on master.<br>
<br>
<br>
What I want to propose is following other fast moving projects like<br>
Linux kernel, Chrome or Firefox and have:<br>
<br>
* All feature development done in dedicated feature branches. These<br>
branches should be named like Nishant's branch: NAME/feature-description.<br>
<br>
* A six week release schedule with:<br>
<br>
** a merge window of two weeks after each release: every feature that<br>
is ready can be merged in those two weeks. Outside those two weeks only<br>
bug fixes go into master.<br>
<br>
** A four week stabilization/translation window. This should be sufficient<br>
to allow the translators to keep up and to fix any stability issues that<br>
occur after a feature is merged.<br>
<br>
* Numbering like this: 3.0.x until we have all features promised for<br>
the 2015 kickstarter, then 3.1.x, until we have all features promised<br>
for the 2016 kickstarter, then 3.2.x.<br>
<br>
* A release procedure where we package the translations into the source<br>
tarball, as discussed before; I can then fix my build scripts to build<br>
from the source release instead of a git tag.<br>
<br>
<br>
If there is a desire for a stable branch, then I think we should see<br>
whether that desire is great enough for someone to step up and do what<br>
Greg Kroah-Hartman does for Linux: someone who backports fixes, tests<br>
them and publishes a krita-stable.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Boudewijn Rempt | <a href="http://www.krita.org" rel="noreferrer" target="_blank">http://www.krita.org</a>, <a href="http://www.valdyas.org" rel="noreferrer" target="_blank">http://www.valdyas.org</a><br>
_______________________________________________<br>
Krita mailing list<br>
<a href="mailto:kimageshop@kde.org">kimageshop@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kimageshop" rel="noreferrer" target="_blank">https://mail.kde.org/mailman/listinfo/kimageshop</a><br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Wolthera</div>
</div>