Adopting the Linux/Firefox/Chrome release strategy

[Dmitry Kazakov]

I'm perfectly fine with this approach! :)

And I also think that we need some kind of calendar. The only problem is
that Google doesn't allow to share the calendar with a link. Only by adding
emals or creating a company account. We can also use Asana for that. It
also has calendar capabilities, but not publicly sharable as well :(

On Wed, Jul 13, 2016 at 4:24 PM, Wolthera <griffinvalley at gmail.com> wrote:

> 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 at 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 at kde.org
>> https://mail.kde.org/mailman/listinfo/kimageshop
>>
>
>
>
> --
> Wolthera
>
> _______________________________________________
> Krita mailing list
> kimageshop at kde.org
> https://mail.kde.org/mailman/listinfo/kimageshop
>
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160713/30926ff4/attachment.html>