Hi,
I updated https://qt-project.org/wiki/Branch-Guidelines
I added the Where to push a change section
I also added documentation fixes. to the list.
On Friday 25 January 2013 09:37:26 Jedrzej Nowacki wrote:
e. Autotests extensions and new tests should go to stable if possible. It
On Jan 13, 2013, at 12:39 PM, Olivier Goffart oliv...@woboq.com wrote:
On Friday 11 January 2013 07:40:39 Thiago Macieira wrote:
On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote:
Go to stable:
a. Fixes to regressions against a previous recent version of Qt. (less
On Friday 11 January 2013 07:40:39 Thiago Macieira wrote:
On sexta-feira, 11 de janeiro de 2013 15.21.43, Olivier Goffart wrote:
Go to stable:
a. Fixes to regressions against a previous recent version of Qt. (less
than 2 or 3 years old)
b. Fixes in new feature introduced in the
Hi,
We should finish this discussion and document the conclusion in
http://qt-project.org/wiki/Branch-Guidelines
...
Marc Mutz wrote:
Ok, trying to summarise, I understand it this way:
1. release-critical fixes are submitted and merged to 'stable' now,
'release' later, when it
On 11 January 2013 15:21, Olivier Goffart oliv...@woboq.com wrote:
c. Critical fixes (P1/P0): security, crashes or data corruption.
Aren't important fixes (such as security fixes) good candidates for
the release branch instead of stable?
--
Giuseppe D'Angelo
On Fri, Jan 11, 2013 at 04:53:25PM +0100, Giuseppe D'Angelo wrote:
On 11 January 2013 15:21, Olivier Goffart oliv...@woboq.com wrote:
c. Critical fixes (P1/P0): security, crashes or data corruption.
Aren't important fixes (such as security fixes) good candidates for
the release branch
-Original Message-
From: development-bounces+andy.shaw=digia@qt-project.org
[mailto:development-bounces+andy.shaw=digia@qt-project.org] On
Behalf Of Marc Mutz
Sent: 9. desember 2012 14:23
To: development@qt-project.org
Subject: Re: [Development] RFC: What constitutes a non
On Sunday December 9 2012, Sune Vuorela wrote:
On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote:
3. new features and bug-fixes that require new strings or BiC changes
should be submitted to 'dev' directly.
binary incompatible
Hi Andy,
On Monday December 10 2012, Shaw Andy wrote:
Ok, trying to summarise, I understand it this way:
1. release-critical fixes are submitted and merged to 'stable' now,
'release' later, when it exists.
No-brainer fixes are also welcome.
2. bug-fixes that don't violate string
On segunda-feira, 10 de dezembro de 2012 12.07.21, Marc Mutz wrote:
I was suggesting that bug-fixes initially be submitted for stable (blindly,
if you will) and that review decides whether to redirect them to dev
instead.
If you're a reviewer and you know you'd suggest moving it to dev, then
On Saturday December 8 2012, Thiago Macieira wrote:
[...]
We'll create the releases branch for the RC2 then.
Ok, trying to summarise, I understand it this way:
1. release-critical fixes are submitted and merged to 'stable' now,
'release' later, when it exists.
No-brainer fixes are also
On 2012-12-09, Sune Vuorela nos...@vuorela.dk wrote:
On 2012-12-09, Marc Mutz marc.m...@kdab.com wrote:
3. new features and bug-fixes that require new strings or BiC changes should
be submitted to 'dev' directly.
binary incompatible changes should not be submitted anywhere except for
On sábado, 8 de dezembro de 2012 09.53.44, Alan Alpert wrote:
This thing about the non-destabilizing bug fixes is just the release
team being cautious because we don't have a release branch yet.
Theoretically I'd have thought the release branch should have started
for RC1 and then the release
13 matches
Mail list logo
