Adopting the Linux/Firefox/Chrome release strategy

[Wolthera]

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.

On Wed, Jul 13, 2016 at 9:49 PM, Boudewijn Rempt <boud at valdyas.org> wrote:

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



-- 
Wolthera
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160713/5600cd0e/attachment-0001.html>