Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-10-04 Thread Konstantin Tokarev 


04.10.2016, 14:04, "Edward Welbourne" :
> Marc Mutz said:
>>  I just came to realise another reason against cherry-picking:
>>
>>  Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will
>>  be developed against 5.7+ will very likely have C++11 constructs in
>>  them that won't work in Qt 5.6.
>
> Conversely, code developed in 5.6 shall avoid C++11 constructs; when we
> merge to 5.7, we need to review to find C++11 usage we can apply, which
> tends to get missed after merges.

This can be easily fixed by using tools like clang-tidy (modernize* checks)

>
>>  That means that in order to backport, the code needs to be
>>  de-C++11-ified, which in turn means the usual reasoning for
>>  cherry-picking as a stability feature (it's been integrated already
>>  once successfully) falls flat on its face, because the code submitted
>>  against 5.7+ must needs be changed (forgive my Victorian) in the
>>  process of cherry-picking to 5.6, invalidating any test coverage it
>>  may have had as part of the younger branch.
>
> Back-porting doesn't *entirely* invalidate the stability evidence gained
> in a later branch, any more than conflict resolutions in forward-merging
> invalidate stability evidence gained in an older branch. Of course, you
> need to test after back-porting, just as you do after forward-merging,
> but the existing test coverage is still valuable.
>
>>  To avoid the guaranteed merge conflicts from
>>  cherry-picked-and-changed, commits,
>
> Not sure what you're referring to here. Just to be clear, once we
> switch to cherry-picking back to 5.6, we shall stop merging forward from
> 5.6, so there shall be no merge conflicts from those changes being
> merged up into 5.7 again. That would be dumb.
>
>>  you'd need to ban any non-cherry-pick changes to 5.6, which
>>  effectively means that no developer does any work on 5.6 anymore.
>
> That did seem to be the intent of those who proposed this, yes. Of
> course, there shall be *some* work on 5.6, but it shall be limited to
> back-porting already-tested fixes and investigating bugs that are only
> evident in 5.6. That would be the point of LTS, IIUC.
>
>>  Everyone will rely on the CI, and the CI only.
>
> Again, not sure what you mean here; and those doing back-ports shall of
> course be doing local testing before they push, so not relying only on
> the CI - where, in contrast, after a merge we *are* relying on the CI
> and only the CI, except for the (relatively few) conflicts in each
> merge, which do get review.
>
>>  OTOH, with very few exceptions such a Q_FOREACH, code that
>>  successfully integrated into 5.6 will successfully integrate in 5.7+.
>
> ... but will, as noted above, contain pre-C++11 code in need of
> C++1-ifying, after we've done sweeps through the code-base catching such
> code and modernising most of what's in 5.7 and beyond; so we would need
> to pay attention to each change flowing up from 5.6, to see what needs
> such attention. The advantage of cherry-picking is precisely that each
> one shall need to be done attentively and reviewed, while merging only
> gets review of its conflicts and happens quietly in the background, with
> few paying attention to it.
>
>>  In light of this I continue to vote for keeping the "no-cherry-picks
>>  allowed" policy that has served us well over the Qt 5 years.
>
> I remain unconvinced, see above,
>
> Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-10-04 Thread Edward Welbourne 
Marc Mutz said:
> I just came to realise another reason against cherry-picking:
>
> Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will
> be developed against 5.7+ will very likely have C++11 constructs in
> them that won't work in Qt 5.6.

Conversely, code developed in 5.6 shall avoid C++11 constructs; when we
merge to 5.7, we need to review to find C++11 usage we can apply, which
tends to get missed after merges.

> That means that in order to backport, the code needs to be
> de-C++11-ified, which in turn means the usual reasoning for
> cherry-picking as a stability feature (it's been integrated already
> once successfully) falls flat on its face, because the code submitted
> against 5.7+ must needs be changed (forgive my Victorian) in the
> process of cherry-picking to 5.6, invalidating any test coverage it
> may have had as part of the younger branch.

Back-porting doesn't *entirely* invalidate the stability evidence gained
in a later branch, any more than conflict resolutions in forward-merging
invalidate stability evidence gained in an older branch.  Of course, you
need to test after back-porting, just as you do after forward-merging,
but the existing test coverage is still valuable.

> To avoid the guaranteed merge conflicts from
> cherry-picked-and-changed, commits,

Not sure what you're referring to here.  Just to be clear, once we
switch to cherry-picking back to 5.6, we shall stop merging forward from
5.6, so there shall be no merge conflicts from those changes being
merged up into 5.7 again.  That would be dumb.

> you'd need to ban any non-cherry-pick changes to 5.6, which
> effectively means that no developer does any work on 5.6 anymore.

That did seem to be the intent of those who proposed this, yes.  Of
course, there shall be *some* work on 5.6, but it shall be limited to
back-porting already-tested fixes and investigating bugs that are only
evident in 5.6.  That would be the point of LTS, IIUC.

> Everyone will rely on the CI, and the CI only.

Again, not sure what you mean here; and those doing back-ports shall of
course be doing local testing before they push, so not relying only on
the CI - where, in contrast, after a merge we *are* relying on the CI
and only the CI, except for the (relatively few) conflicts in each
merge, which do get review.

> OTOH, with very few exceptions such a Q_FOREACH, code that
> successfully integrated into 5.6 will successfully integrate in 5.7+.

... but will, as noted above, contain pre-C++11 code in need of
C++1-ifying, after we've done sweeps through the code-base catching such
code and modernising most of what's in 5.7 and beyond; so we would need
to pay attention to each change flowing up from 5.6, to see what needs
such attention.  The advantage of cherry-picking is precisely that each
one shall need to be done attentively and reviewed, while merging only
gets review of its conflicts and happens quietly in the background, with
few paying attention to it.

> In light of this I continue to vote for keeping the "no-cherry-picks
> allowed" policy that has served us well over the Qt 5 years.

I remain unconvinced, see above,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-10-01 Thread Marc Mutz 
On Thursday 08 September 2016 09:12:32 Marc Mutz wrote:
> On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> > ** After 5.7 is closed and sanity bot is upgraded (to handle 
> > cherry-picking), go into cherrypicking mode for 5.6. Developer is 
> > responsible for doing the cherrypicking
> > ** Cherry-picking technicalities need to be figured out: Let sanity bot 
> > verify source ("cherrypicked from") the SHA1
>
> I'm sorry, but this is nonsense. The source control system works by
> committing  on the older branches and merging up. Cherry-picking from
> younger branches works against the source control system. We put up with
> cherry-picking for 4.8, because there we dealt with separate repositories,
> but that doesn't make is a good model.

I just came to realise another reason against cherry-picking:

Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will be 
developed against 5.7+ will very likely have C++11 constructs in them that 
won't work in Qt 5.6.

That means that in order to backport, the code needs to be de-C++11-ified, 
which in turn means the usual reasoning for cherry-picking as a stability 
feature (it's been integrated already once successfully) falls flat on its 
face, because the code submitted against 5.7+ must needs be changed (forgive 
my Victorian) in the process of cherry-picking to 5.6, invalidating any test 
coverage it may have had as part of the younger branch.

To avoid the guaranteed merge conflicts from cherry-picked-and-changed, 
commits, you'd need to ban any non-cherry-pick changes to 5.6, which 
effectively means that no developer does any work on 5.6 anymore. Everyone 
will rely on the CI, and the CI only.


OTOH, with very few exceptions such a Q_FOREACH, code that successfully 
integrated into 5.6 will successfully integrate in 5.7+.


In light of this I continue to vote for keeping the "no-cherry-picks allowed" 
policy that has served us well over the Qt 5 years.


If merging is a bottleneck, I think we as contributors just need to unlearn 
that 5.6 changes magically show up in dev a few days later. Before Liang 
became the designated merge-monkey (that's not derogative, that's the 
technical term! :), we had to wait up to a month for a change to percolate up, 
and that was with fewer active branches in-flight. We survived, and Qt wasn't 
1/6th merges (uneducated guesstimate based on equating Liang with merges and 
applying that to http://www.macieira.org/~thiago/qt-stats/current/qt-
all.author.absolute.png (2016W38)).

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-23 Thread Oswald Buddenhagen 
On Thu, Sep 22, 2016 at 09:41:29AM +0200, Marc Mutz wrote:
> On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
> > Give the merge permission to everyone is obiviously not a solution.
> 
> Not everyone, but approvers, maybe? Merges need to be reviewed like any other 
> commit, so why are they special, anyway?
> 
because a botched merge push may result in hundreds of bogus reviews
(when somebody does pull --rebase before pushing the merge; no, that's
not a hypothetical situation). not having the right to push merges
trains the users to not even attempt it.

another reason is that some people tend to over-merge, needlessly
cluttering the history. having to ask another person (who will hopefully
critically examine the request) is a natural check for this.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Edward Welbourne 
On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
>> Give the merge permission to everyone is obiviously not a solution.
Marc Mutz replied:
> Not everyone, but approvers, maybe? Merges need to be reviewed like
> any other commit, so why are they special, anyway?

Do we at least give all maintainers merge powers in their modules ?

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Marc Mutz 
On Thursday 22 September 2016 08:55:13 Liang Qi wrote:
> Give the merge permission to everyone is obiviously not a solution.

Not everyone, but approvers, maybe? Merges need to be reviewed like any other 
commit, so why are they special, anyway?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-22 Thread Liang Qi 
On 12 September 2016 at 11:20, Edward Welbourne 
 wrote:

> Marc Mutz said:
> > The obvious question is, then, why is only "the one person" doing merges?
> > Allow more people to upload merges, and you will get the spreading you
> desire.
>
> Several people can upload merges.
> One person looks after integration in qt5 and all its sub-modules.
> We can spread the load (indeed, I carried it for a few weeks while
> Liang was on holiday), and I believe module owners can do their own
> merges (which saves the integration team work), but the integration team
> takes responsibility for ensuring merges are happening.
> So it ends up being that Liang, as integrator, does most merges.
>

We have some/many modules are in not active mode, so the merges for them
are normally based on the release schedules. That's one of the reason to
have a merger.

A heavy load for mergers and integrators is that the new CI, COIN, doesn't
have reverse dependency check like old CI. Then if sth changed in qtbase or
qtdeclarative, the merge and integration will trigger the issue. Then very
often it's a bit difficult for us to analysis the root cause and find right
persons to fix it.

Perhaps we should set up a rule for deprecated sth, for example,
1. notify merger/integrator/others, or just add them into a list in a
wiki/web page
2. the dev of the deprecated change should do a "git grep" in all qt
project, and at least provide a fix for one of them, better to do all

For merges, the maintainers of modules should take care. At least,
qtquickcontrols2/qtwebengine are very well, it's also because developers
there are working on different features in different branches, they care
the merge themselves.

For some other modules, like qt3d/qtmultimedia/qtwayland, the help from the
maintainers and developers are also very good.

But for qtbase, it's a totally different story, too many areas, so normally
we(or I) can't say there is an active maintainer for the whole of qtbase. A
regular merge for qtbase is needed, for example, weekly. And if we can't
get response from devs very soon, who can help?

Give the merge permission to everyone is obiviously not a solution. But it
will help a lot if we have an active merger/integrator group, at least for
review.

Regards,
Liang
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-12 Thread Edward Welbourne 
Marc Mutz said:
> The obvious question is, then, why is only "the one person" doing merges?
> Allow more people to upload merges, and you will get the spreading you desire.

Several people can upload merges.
One person looks after integration in qt5 and all its sub-modules.
We can spread the load (indeed, I carried it for a few weeks while
Liang was on holiday), and I believe module owners can do their own
merges (which saves the integration team work), but the integration team
takes responsibility for ensuring merges are happening.
So it ends up being that Liang, as integrator, does most merges.

> In fact, one could also be led to think that the perceived security of "it has
> passed CI in dev, so it's safe for LTS" will cause more and less appropriate
> commits to be backported to LTS.

I shall amend sanity-bot to object to cherry-picks to LTS unless they
come from gerrit/stable.
So "it has passed  CI in dev" won't get it into LTS.
It has to have passed review and CI in stable to be a candidate for
cherry-picking to LTS.
Then the second review can haggle about whether it belongs in LTS.
That can take a long time without delaying the change's merge-journey up
to dev.

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-10 Thread Thiago Macieira 
On sábado, 10 de setembro de 2016 09:21:58 PDT Marc Mutz wrote:
> (and the less obvious one: why are changes to the config system done in 5.8,
> and not LTS? They don't touch code, after all).

You mean the complete rewrite of configure and configure.exe, with a huge chunk 
of new qmake code that was started several months after the v5.6.0 release? 
The one we're still finding issues with? The one that can potentially disable a 
lot of previously-supported build configurations because we didn't know people 
used that?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-10 Thread Konstantin Tokarev 


10.09.2016, 15:32, "Marc Mutz" :
> Hi Lars,
>
> On Friday 09 September 2016 15:21:04 Lars Knoll wrote:
>>  A cherry-picking approach for the LTS branch can make sense, as it
>>  distributes the burden of bringing the bug fix to both the stable and LTS
>>  branch over all developers and doesn’t put it on the one person having to
>>  do the merges.
>
> The obvious question is, then, why is only "the one person" doing merges?
> Allow more people to upload merges, and you will get the spreading you desire.
>
> (and the less obvious one: why are changes to the config system done in 5.8,
> and not LTS? They don't touch code, after all).
>
>>  It will also help limiting changes in the LTS branch to the
>>  things that should really go there.
>
> Which is in itself a controversial topic (see other thread). To stay on-topic:
> I don't see how cherry-picking would help here, as both cherry-picks and
> original commits to LTS will be reviewed, possibly by the same people.

Resolution of merge conflicts also requires review, and, in addition, may lack
necessary context in place.

>
> In fact, one could also be led to think that the perceived security of "it has
> passed CI in dev, so it's safe for LTS" will cause more and less appropriate
> commits to be backported to LTS.
>
> Or are you going to impose release branch rules (restricted staging) on 5.6,
> eventually?
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - Qt, C++ and OpenGL Experts
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-10 Thread Marc Mutz 
Hi Lars,

On Friday 09 September 2016 15:21:04 Lars Knoll wrote:
> A cherry-picking approach for the LTS branch can make sense, as it
> distributes the burden of bringing the bug fix to both the stable and LTS
> branch over all developers and doesn’t put it on the one person having to
> do the merges.

The obvious question is, then, why is only "the one person" doing merges? 
Allow more people to upload merges, and you will get the spreading you desire.

(and the less obvious one: why are changes to the config system done in 5.8, 
and not LTS? They don't touch code, after all).

> It will also help limiting changes in the LTS branch to the
> things that should really go there.

Which is in itself a controversial topic (see other thread). To stay on-topic: 
I don't see how cherry-picking would help here, as both cherry-picks and 
original commits to LTS will be reviewed, possibly by the same people.

In fact, one could also be led to think that the perceived security of "it has 
passed CI in dev, so it's safe for LTS" will cause more and less appropriate 
commits to be backported to LTS.

Or are you going to impose release branch rules (restricted staging) on 5.6, 
eventually?

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-09 Thread Lars Knoll 

On 08/09/16 17:13, "Development on behalf of Thiago Macieira" 
 wrote:

>On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote:
>> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
>> that? 5.7.1 is very soon in a few weeks. There will be a few months gap
>> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
>> sometimes it's not tested enough in user(or application developers) side,
>> so some regressions or a bit critical issues will be found between 5.8.0
>> and 5.8.1. It's good for users to have a more stable release of 5.7.2.
>> 
>> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
>> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
>> 
>> And I would like to see it becomes a convention for future releases.
>
>It wouldn't be bad, if the release team and merging team can make it work. Our 
>concern was that you and Eddy are spending far too much time on doing merges.

It’s basically a question about how we can deal most efficiently with the 
branches we have. And both merging and cherry-picking are valid ways to work 
with those branches.

If the branches are closely related, merging is obviously the better choice, as 
conflicts will be rare. But once branches start diverging more, merging will at 
some point start to create more overhead (and risk) than cherry-picking back 
into the older branch.

There are several reasons, why I think we at some point should stop merging 
from 5.6 to newer branches. 

We are doing significant changes all through our code base currently. C++11 and 
configuration system related changes are just one example. This will lead to 
more and more merge conflicts as time goes by. I’ve already reviewed a few 
merges where it took significant effort to verify that the merge was correct. 
Merges are done by one person, and that person often doesn’t know all the 
details of what the patch causing a conflict is trying to achieve. This 
actually increases our risk of introducing regressions into our newer branches.

Having a lot of branches also increases the complexity for all of us into 
figuring out where a change should go. In many cases it also does significantly 
increase turn-around time if a patch is needed in a newer branch. Having a long 
merge patch from 5.6 to dev can cause delays for all of us. If those delays get 
too long, this is costly for all of us and will slow us down when developing 
new features.

A cherry-picking approach for the LTS branch can make sense, as it distributes 
the burden of bringing the bug fix to both the stable and LTS branch over all 
developers and doesn’t put it on the one person having to do the merges. It 
will also help limiting changes in the LTS branch to the things that should 
really go there.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Thiago Macieira 
On quinta-feira, 8 de setembro de 2016 07:37:28 PDT Liang Qi wrote:
> Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
> that? 5.7.1 is very soon in a few weeks. There will be a few months gap
> between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
> sometimes it's not tested enough in user(or application developers) side,
> so some regressions or a bit critical issues will be found between 5.8.0
> and 5.8.1. It's good for users to have a more stable release of 5.7.2.
> 
> If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
> Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.
> 
> And I would like to see it becomes a convention for future releases.

It wouldn't be bad, if the release team and merging team can make it work. Our 
concern was that you and Eddy are spending far too much time on doing merges.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Oswald Buddenhagen 
On Thu, Sep 08, 2016 at 12:25:02PM +0200, Liang Qi wrote:
> This is mainly because we did heavy refactoring in upstream branches,
>
"upstream" makes no sense whatsoever. merge-wise, it's exactly the wrong
way around. "younger" as used elsewhere in this thread is better.

> for example, rewriting configure system, then any small fix in 5.6
> will trigger a huge conflicts.
> 
yes, it's annoying for the one(s) doing the work, but the fact that it
*has* to be done ensures that it *gets* done. doing cherry-picking is a
virtual guarantee that the LTS becomes a scam.

you should also see things in perspective: how many files merge without
you even noticing it, because the merges are clean?

> Other cases are sth like directories reorganization, class renaming
> and etc, it's very annoying when developers have changes in similar
> places in 5.6 and upper branches.
> 
which is why i'm actually in favor of doing low-risk cleanups and
refactorings on stable branches, or at least shortly before branching
off.

> Best Regards,
> Liang
> 
> 
> 
> > --
> > Alex
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Liang Qi 
On 8 September 2016 at 09:36, Alexander Blasche 
wrote:

> 
> From: Marc Mutz 
>
> >On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> >> ** After 5.7 is closed and sanity bot is upgraded (to handle
> >> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> >> responsible for doing the cherrypicking
> >> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> >> verify source ("cherrypicked from") the SHA1
>
> >I'm sorry, but this is nonsense.
>
> I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is
> closed? Since the 5.6 branch will get fewer and fewer patches as the
> strictness of its commits increases I see no reason why 5.6->5.8 could pose
> a problem.
>
> Maybe you sb can elaborate why we have to go to cherry-picking? The notes
> don't say and I wasn't in this QtCon meeting.
>

This is mainly because we did heavy refactoring in upstream branches, for
example, rewriting configure system, then any small fix in 5.6 will trigger
a huge conflicts.

https://codereview.qt-project.org/#/c/163938/

Other cases are sth like directories reorganization, class renaming and
etc, it's very annoying when developers have changes in similar places in
5.6 and upper branches.

Best Regards,
Liang



> --
> Alex
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Alexander Blasche 



From: Marc Mutz 

>On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
>> ** After 5.7 is closed and sanity bot is upgraded (to handle
>> cherry-picking), go into cherrypicking mode for 5.6. Developer is
>> responsible for doing the cherrypicking
>> ** Cherry-picking technicalities need to be figured out: Let sanity bot
>> verify source ("cherrypicked from") the SHA1

>I'm sorry, but this is nonsense.

I agree with Marc. Why cant we do 5.6->5.8 merges once the 5.7 branch is 
closed? Since the 5.6 branch will get fewer and fewer patches as the strictness 
of its commits increases I see no reason why 5.6->5.8 could pose a problem.

Maybe you sb can elaborate why we have to go to cherry-picking? The notes don't 
say and I wasn't in this QtCon meeting.
--
Alex
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Marc Mutz 
On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote:
> ** After 5.7 is closed and sanity bot is upgraded (to handle 
> cherry-picking), go into cherrypicking mode for 5.6. Developer is 
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot 
> verify source ("cherrypicked from") the SHA1

I'm sorry, but this is nonsense. The source control system works by committing 
on the older branches and merging up. Cherry-picking from younger branches 
works against the source control system. We put up with cherry-picking for 
4.8, because there we dealt with separate repositories, but that doesn't make 
is a good model.

There's another aspect to this: I develop part of my patches on gt5.git/5.6 
and the rest on qtbase.git/dev. I guess for most people with non-unlimited 
processing power it will be similar. For sure this is the only way if your 
development focus is on qtbase (and you can't just submit your changes to COIN 
manually).

If I submit from the qt5.git/5.6 built, the changes have gone through testing 
in the stable branch. If I submit from there to younger branches, test 
coverage is not as good, but the point is that the stable branch receives the 
changes tested locally in-situ. If I change this to qt5.git/5.8 and cherry-
pick changes back to 5.6, all local testing will have been done in-situ for 
5.8, and when submitting to 5.6, no in-situ testing has happened locally.

IOW: cherry-picking causes *more* risk to the stable branch than submitting 
there and merging up. I am not convinced that the perceived security of having 
a patch integrated into a younger branch and then submitting it to the older 
branch outweights the loss of test coverage.

If the merging strain is too much, only merge 5.6 up once a fortnight/month.

Currently, it feels like there's

   5.6 -> 5.7
   5.7 -> 5.8
   5.8 -> dev
   5.6 -> 5.7

with maximum speed. That's nice for developers who are splitting changes into 
a bugfix part for 5.6 and a feature part for 5.8/dev, but it hasn't been like 
that in the past and we survived, too. And the git history looked cleaner, too 
:)

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-08 Thread Liang Qi 
On 7 September 2016 at 08:37, Friedemann Kleint 
wrote:

> Hi,
>
> the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches
>
> * Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of
> problems
>
> ** Strain on COIN which also has release branches
> ** Merging becomes increasingly difficult
> ** Hard to manage for individual developers
>
> * Branches
>
> ** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
>

Is it better to have 5.7.2 around 5.8.0 final release and close 5.7 after
that? 5.7.1 is very soon in a few weeks. There will be a few months gap
between 5.7.1 and 5.8.0/5.8.1. The first release of new branch, like 5.8.0,
sometimes it's not tested enough in user(or application developers) side,
so some regressions or a bit critical issues will be found between 5.8.0
and 5.8.1. It's good for users to have a more stable release of 5.7.2.

If we stick to do release like this kind of order, 5.6.2->5.7.1->5.8.0
Beta, it's not very difficult to have a 5.6.3->5.7.2->5.8.0 or similar.

And I would like to see it becomes a convention for future releases.

Best Regards,
Liang


> ** After 5.7 is closed and sanity bot is upgraded (to handle
> cherry-picking), go into cherrypicking mode for 5.6. Developer is
> responsible for doing the cherrypicking
> ** Cherry-picking technicalities need to be figured out: Let sanity bot
> verify source ("cherrypicked from") the SHA1
> ** In the future, exact time for closing stable branches will be discussed
> for each one individually
>
> * Submit Policy
>
> ** Target which branch?
>
> ** Long Term Support (5.6) Branch
> *** Initially equal to stable, increasingly strict over time: Fix only
> severe issues, avoid regressions.
>
> *** Bugs: For example, P2 for the first year, P1 for year 2, rest
> Security. Try to further objectify that: Jedrzei + Friedemann
> *** Tests: Fix/stabilize tests itself, add tests
> *** No performance improvements unless really significant
> (relevant/reduces O(n))
> *** Upgrading 3rd party (including WebEngine)
> *** Support new OS versions unless introducing new platforms, no rewrite
> of QPA
> *** No cleanups, positively: -> dev
> *** To aid customers with issues, patches for issues in LTS to be locally
> applied can be provided, but the fixes will be pushed to higher versions of
> Qt.
>
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> The Qt Company GmbH
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Notes on "Managing Qt's branches" session @ QCS 2016

2016-09-07 Thread Friedemann Kleint 

Hi,

the notes are at: https://wiki.qt.io/QtCS2016_Managing_Qt_Branches

* Number of existing branches (5.6LTS, 5.7.,5.8 dev) causes a number of 
problems


** Strain on COIN which also has release branches
** Merging becomes increasingly difficult
** Hard to manage for individual developers

* Branches

** Close 5.7 after 5.7.1. We then have LTS, stable, dev.
** After 5.7 is closed and sanity bot is upgraded (to handle 
cherry-picking), go into cherrypicking mode for 5.6. Developer is 
responsible for doing the cherrypicking
** Cherry-picking technicalities need to be figured out: Let sanity bot 
verify source ("cherrypicked from") the SHA1
** In the future, exact time for closing stable branches will be 
discussed for each one individually


* Submit Policy

** Target which branch?

** Long Term Support (5.6) Branch
*** Initially equal to stable, increasingly strict over time: Fix only 
severe issues, avoid regressions.


*** Bugs: For example, P2 for the first year, P1 for year 2, rest 
Security. Try to further objectify that: Jedrzei + Friedemann

*** Tests: Fix/stabilize tests itself, add tests
*** No performance improvements unless really significant 
(relevant/reduces O(n))

*** Upgrading 3rd party (including WebEngine)
*** Support new OS versions unless introducing new platforms, no rewrite 
of QPA

*** No cleanups, positively: -> dev
*** To aid customers with issues, patches for issues in LTS to be 
locally applied can be provided, but the fixes will be pushed to higher 
versions of Qt.



Regards,
Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development