Adopting the Linux/Firefox/Chrome release strategy

[Boudewijn Rempt]

On Wed, 13 Jul 2016, Wolthera wrote:

> This is fine, but we really need a shared calender. 

I agree, though the main thing is the mail to the list:

* Now you can propose your branch for merging
* Now the merge window is closed

And to the translations list

* Now you can translate stuff

Which it would be ideal if the calendar could send them automatically.


This does remind me of something not in my original mail: I think 
feature branches should be proposed for merging in phabricator -and-
on this mailing list. But what would be best? The week before the merge
window opens? Or in the first week of the merge window?

> 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
> >
> 
> 
> 
> 

-- 
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org