16/11/2015 Meeting minutes

[Boudewijn Rempt]

Mostly from the excellent notes, filled in to follow the agenda:

= Minutes for Planning Meeting 16.11.2015 =

# Notes from the meeting [https://notes.kde.org/p/krita-meeting-2015-11-16 etherpad-link]

# Release process

Now that we're on our own, we need to improve our release process.

## Calendar/Checklist:

We need to develop a release checklist. An example is http://wiki.blender.org/index.php/Dev:Doc/Process/Release_Checklist,

Here is what we have until now:

Release Checklist:
     * Write release post.
     * Changing the git version number.
     * Add a git-tag
     * Ping all translators team in a week before the packages build
     * Create translations tarball (dmitryK)
     * OSX build
     * Windows build(does it crash?)
     * Testing packages on:
         *Ubuntu(launchpad)
         *Arch
         *OpenSuse
     * Naming sceme

Once we have defined a release schedule (task for Boudewijn), we will setup a shared calendar that can send out reminders:

[https://calendar.google.com/calendar/embed?src=pv232t7pu0acstl5c64357mlo4%40group.calendar.google.com&ctz=Europe/Moscow Krita Release Calendar]

We're going back to one big release a year, with bugfix/small feature releases every month:

Large releases VS Small Releases:
     Large releases are a change in the Y in X.Y.Z
     * These contain large features.
     * Are ideally released in March so that bugs can be fixed before May(the kickstarter month)
     * Feature freeze at the least two month before expected release?
     * String freeze at the least two weeks before final release?
     Small releases are a change in Z in X.Y.Z
     * These contain bugfixes that weren't wishbugs.
     * And they contain small features. So new actions, tweaked hotkeys, a small modification to a c-plugin. No big feature changed in the core.
     * Feature freeze at the least two weeks before expected release?
     * String freeze at the least one week before final release?
     * Write marketing material(feature demo video/manual item/etc) around feature freeze.
Features:
     Big features need to go into testing branches:
         * These are named testing-commiter or featurename-commiter
         * So do changes to the defaults. We have endusers use our master branch, let s wanr them before making big changes.
         * Branch merges into master need CCMAIL:kimageshop at kde.org
Testing-releases:
     Alpha: Main features kickstarter+as many stretchgoals as we can fit.
     Beta:Real freeze in january. Bugfixing time!
     Final: Ideally done in March.

## 3.0 Release schedule and contents

* 3.0.0 pre-alpha: December 1st --- work as usual. Fix tablet support
* 3.0.0 alpha: January 6th --- Feature Freeze, tablet support + 1-2 stretch goals.
     Priority features:
         * lazy brush (because it would add uniqueness)
         * Layer docker redesign.
         * multi-layer selection improvements
         * exporting to animated formats

* 3.0.0 beta: February 3rd
* 3.0.0 final: March 2nd

## 3.1 Release schedule and contents

* 3.1 --- 13th of April

## 2.9 How many releases are left? 2.9.10, 2.9.11...

* 2.9.10: December 2nd

## 2.9 Animation. 2.9-based test releases for Windows and Linux (without translations).

Will be released 26th of November. See the checklist in the meeting notes.

## Branching

Branches:
     3.0 has the main branch for the feature frozen code
     3.0.1 tag that points to the released version
     If the released version was cancelled due to a blocker but, we branch into 3.0.1.1 and cherry-pick neded commits there


# Coding Priorities

For 3.0, Dmitry will work on tablet support, missing features for animation, multilayer handling, layer docker improvements. Scott will work on a design for the improved layer docker.

Missing animation features:

     * exporting frames to APNG/GIF/Spritesheet(This is a stretchgoal too)
     * cross-layer D&D
     * merging and other whole-image actions

For 3.0, Boud is working on import/export of gimp brushes, general qt5 porting and now also on the OSX port...

Abrahams is creating new action system, therefore requests we take action related stretchgoals to him first for discussion. So when adding a feature and/or stretchgoal, please ask Abrahams about how to implement shortcuts

Abrahams has finished work on tablet support for Windows. We're back at a fork of the Qt code... But we'll try to keep the delta small so we can upstream patches to eCloud. For x11, that's hard since the tablet support is all over the xcb qpa (Qt platform abstraction for the new X11 api).

## Vc 1.0 port

Not much code needed, but let's push the change to a branch first so we can do a thorough regression test.

## 3.0 Tablet support


Abrahams has finished work on tablet support for Windows. We're back at a fork of the Qt code... But we'll try to keep the delta small so we can upstream patches to eCloud. For x11, that's hard since the tablet support is all over the xcb qpa (Qt platform abstraction for the new X11 api).

## A man from St. Petersburg wants to create a UIX design of tablet interface for Krita (no coding, just the design)

This is a uni project, there might be some funding involved. Dmitry will stay in contact, this person's English is not great.

## Documents on the wiki need a bit of love.

     * Dmitry make a mail about directory listing in wiki
     * Current manual writers will focus on userbase.
     * Scottyp is investigating mediawiki alternatives.

# Sprint
## Mini sprint in Q1, or a maxi sprint in Q2?

Both, we'll have a sprintlet in Deventer with at least Dmitry in February. Everyone else is welcome, but there might not be funding for a lot of travel!

Boud will contac the e.V. board about a KDE sponsored big sprint in Q2.

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