<div dir="ltr">I've set up something to automate an event occurring on the release calender to be sent to the mailing list, with the first event being on friday as a tester, and after that we can set up periods and they should be automatically sent to this mailing list.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 13, 2016 at 9:49 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"><span class="">On Wed, 13 Jul 2016, Wolthera wrote:<br>
<br>
> This is fine, but we really need a shared calender.<br>
<br>
</span>I agree, though the main thing is the mail to the list:<br>
<br>
* Now you can propose your branch for merging<br>
* Now the merge window is closed<br>
<br>
And to the translations list<br>
<br>
* Now you can translate stuff<br>
<br>
Which it would be ideal if the calendar could send them automatically.<br>
<br>
<br>
This does remind me of something not in my original mail: I think<br>
feature branches should be proposed for merging in phabricator -and-<br>
on this mailing list. But what would be best? The week before the merge<br>
window opens? Or in the first week of the merge window?<br>
<div class="HOEnZb"><div class="h5"><br>
> I recall we started on<br>
> a google calender? I'd be fine with taking up maintenance for it.<br>
><br>
> Phabricator also has a calender app, but it seems to be incomplete yet, and<br>
> it looks like they are going to make it compatible with google calender in<br>
> the future: <a href="https://secure.phabricator.com/project/board/542/" rel="noreferrer" target="_blank">https://secure.phabricator.com/project/board/542/</a><br>
><br>
> On Wed, Jul 13, 2016 at 2:30 PM, Boudewijn Rempt <<a href="mailto:boud@valdyas.org">boud@valdyas.org</a>> wrote:<br>
><br>
> > 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>
> ><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>
> ><br>
><br>
><br>
><br>
><br>
<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Wolthera</div>
</div>