[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Adopting the Linux/Firefox/Chrome release strategy
From: Wolthera <griffinvalley () gmail ! com>
Date: 2016-07-13 13:24:06
Message-ID: CAN80MtF8XpXGU2K7QP3t2N5k+SU0KAfU34f9FFM4XqNakE6pZw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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.
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: https://secure.phabricator.com/project/board/542/
On Wed, Jul 13, 2016 at 2:30 PM, Boudewijn Rempt <boud@valdyas.org> wrote:
> Hi,
>
> I've been thinking about this a lot over the past weeks, and I want to
> propose a new release strategy because I don't think the current one
> with a master branch and a stable branch is working.
>
> There are at least the following current problems that I see:
>
> * I need to make builds of both branches: stable builds and development
> builds. This is more work than I can handle.
>
> * People need to backport bug fixes to the stable branch. This is not
> happening, and I cannot handle the backporting of fixes myself anymore.
>
> * Backporting features that were based on master (like soft-proofing)
> is pretty hard now.
>
> * People are not building and testing the 3.0 branch -- everyone who
> builds themselves is doing so on master.
>
>
> What I want to propose is following other fast moving projects like
> Linux kernel, Chrome or Firefox and have:
>
> * All feature development done in dedicated feature branches. These
> branches should be named like Nishant's branch: NAME/feature-description.
>
> * A six week release schedule with:
>
> ** a merge window of two weeks after each release: every feature that
> is ready can be merged in those two weeks. Outside those two weeks only
> bug fixes go into master.
>
> ** A four week stabilization/translation window. This should be sufficient
> to allow the translators to keep up and to fix any stability issues that
> occur after a feature is merged.
>
> * Numbering like this: 3.0.x until we have all features promised for
> the 2015 kickstarter, then 3.1.x, until we have all features promised
> for the 2016 kickstarter, then 3.2.x.
>
> * A release procedure where we package the translations into the source
> tarball, as discussed before; I can then fix my build scripts to build
> from the source release instead of a git tag.
>
>
> If there is a desire for a stable branch, then I think we should see
> whether that desire is great enough for someone to step up and do what
> Greg Kroah-Hartman does for Linux: someone who backports fixes, tests
> them and publishes a krita-stable.
>
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
> _______________________________________________
> Krita mailing list
> kimageshop@kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
--
Wolthera
[Attachment #5 (text/html)]
<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>
[Attachment #6 (text/plain)]
_______________________________________________
Krita mailing list
kimageshop@kde.org
https://mail.kde.org/mailman/listinfo/kimageshop
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic