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