next release and release pace in general

Jaroslaw Staniek staniek at kde.org
Sun Jan 27 14:13:15 GMT 2013


On 25 January 2013 18:16, Yuƫ Liu <yue.liu at mail.com> wrote:
> We talked about having a testing branch before commit into master
> branch last year. We can restrict commit right to master, let the
> features committed to and tested in testing branch thoroughly. So
> master will always keep stable.

This is done already via reviews, as Pierre already has mentioned,
plus feature branches that are the ones referred by the review patches
(in ideal case). Our development just isn't linear. Another step would
just add 'administrative' work. Please look at number of branches we
already have: for fixes that go to 2.5, 2.6, master, plus feature
branches, plus sometimes private repos.
A bug that isn't catch on review time won't be catch by adding one
extra branch IMHO. The approach you propose would add not only one
branch before master but also before 2.{5-7} or so.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek



More information about the calligra-devel mailing list