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
> simp
On Friday 25. January 2013 09.12.09 Knoll Lars wrote:
> On Jan 13, 2013, at 12:39 PM, Olivier Goffart 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
On Jan 13, 2013, at 12:39 PM, Olivier Goffart 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
>>> than
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 introduc
On Fri, Jan 11, 2013 at 04:53:25PM +0100, Giuseppe D'Angelo wrote:
> On 11 January 2013 15:21, Olivier Goffart 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 stab
On 11 January 2013 15:21, Olivier Goffart 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
___
De
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 most recent minor version.
> c. Critical fixes (P1/P0):
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,
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, the
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 vio
On Sunday December 9 2012, Sune Vuorela wrote:
> On 2012-12-09, Sune Vuorela wrote:
> > On 2012-12-09, Marc Mutz 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 submitt
evelopment] RFC: What constitutes a "non-destabilising" bug-
> fix?
>
> 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-crit
On 2012-12-09, Sune Vuorela wrote:
> On 2012-12-09, Marc Mutz 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
> Qt6.
I've asked to clarify the
On 2012-12-09, Marc Mutz 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
Qt6.
/Sune
___
Development mai
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 we
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 relea
On Sat, Dec 8, 2012 at 3:30 AM, Thorbjørn Martsum wrote:
>
>
> On Fri, Dec 7, 2012 at 4:53 PM, Thiago Macieira
> wrote:
>>
>> In the general sense, those are the bug fixes that have a high benefit /
>> risk
>> ratio. That is, the changes they introduce are of low risk to introduce
>> more
>> regr
On Fri, Dec 7, 2012 at 4:53 PM, Thiago Macieira
wrote:
> In the general sense, those are the bug fixes that have a high benefit /
> risk
> ratio. That is, the changes they introduce are of low risk to introduce
> more
> regressions and unexpected behaviour changes, while fixing some important
> is
On sexta-feira, 7 de dezembro de 2012 10.41.53, Marc Mutz wrote:
> The only indication for what is acceptable for submission to 'stable' is
> the text boxes in the graphics under point 2 of section Permanent
> Regime: "non-destabilising bugfixes".
>
> For me, by definition, any bug-fix targets to
Hi,
This is a Request For Clarification regarding
http://qt-project.org/wiki/Branch-Guidelines -> Permanent Regime/2
The definition of the branches at the top of the page only talks about the
quality of the code, not what kind of changes are acceptable.
The only indication for what is acceptab
20 matches
Mail list logo
