commits to master

[Jaroslaw Staniek]

On 6 April 2012 00:44, C. Boemann <cbo at boemann.dk> wrote:

> In Berlin last year we agreed that we would move to a 4 month release cycle
> and in order to do that we promised ourselves we would keep master in a
> releasable state only merging things when it was ready to be released.
>
> I don't think we have taken that to heart yet. Master is currently broken
> (hello Dag), and we commit stuff without review just like we always have (hello
> myself, and several others).

(wasn't able to reply earlier)

I only wanted to say I am fully supporting the 4 months cycles and to
me these look like 3-months-of-development and 1 month of time for
integration/release activities. One grand reason for this is that we
eventually could better compete with the web-based software
development where releases are more agile, more distributed and not
splitted to source-vendor/binary-vendor duet.

There are implications of such short release cycle however. I'd like
to focus on just one today. Work on two or more versions can happen
concurrently so it's important to have features easily moveable
between releases since we're going to change plans (for many reasons).

There are not automated bits in our workflow. For example using git
messages for assigning features to releases (what's seen as changelogs
in the very end)  is proposed at [1] but it makes hard to move
features between (planned) releases because editing history is on
server isn't supported (and probably the above need is a poor reason
for breaking git workflow anyway). So this is open question and while
I have one idea for helping with more verbose git messages, it only
would help a bit.

[1] http://blog.martin-graesslin.com/blog/2012/04/changelog-and-feature-plan-generator/

-- 
regards / pozdrawiam, Jaroslaw Staniek
 http://www.linkedin.com/in/jstaniek
 Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org)
 KDE Software Development Platform on MS Windows (windows.kde.org)