Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On 12/16/11 8:48 PM, "ext Thiago Macieira" wrote: >On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: >> One idea is to have an automated process that propose the changes to >> be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes >> of what has been done to update the Qt5 sha1, e.g. >> http://codereview.qt-project.org/11239), but at this stage is just an >>idea. > >I still prefer merges, the Qt 4 way. This is something we'll need to >figure out >by the time we branch 5.0 from 5.1. Me as well. We can do merges in gerrit, but we should probably not try to automate them. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Friday 16 December 2011 12:54:40 Shaw Andy wrote: > On 12/16/11 1:18 PM, "Olivier Goffart" wrote: > >On Friday 16 December 2011 12:48:32 Thiago Macieira wrote: > >> On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: > >> > One idea is to have an automated process that propose the changes > >> > to > >> > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the > >> > likes > >> > of what has been done to update the Qt5 sha1, e.g. > >> > http://codereview.qt-project.org/11239), but at this stage is just > >> > an > >> > idea. > >> > >> I still prefer merges, the Qt 4 way. This is something we'll need to > >> > >>figure > >> > >> out by the time we branch 5.0 from 5.1. > > > >The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the > >way > >it worked in Qt 4 in order to work with gerrit. (the merge need to go > >through > >the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1 > >meaning > >they need followup commit.) In Qt 4 it worked because the CI system was > >merging branches, and there was the qt-4.8-from-4.7 branch that as merged > >by > >CI. But gerrit do not play well with branches (yet?). > > > > > >But the more imediate problem is the problem to ensure that bugfixes in > >4.8 > >also get submited in Qt 5. > >There, merging is not possible as the repository are different, one must > >cherry pick. > >There are cases were a commit make no sens in Qt5 (symbian code for > >example) > >But in most case, changes should go in Qt5 > >The commit should first be submitted to gerrit and get proper review > >there. > >Then, once they passed the CI system in Qt5, they can be cherry-picked in > >Qt > >4.8. > >The rationale was that gerrit is the appropriate tool for the review, so > >the > >commit can grow there. Then, once ready, be integrated. > > While I agree that gerrit is the proper system to get a review now. I > disagree with the process being that it goes into Qt 5 and then > backported, the fact it passed in Qt 5 is not a guarantee that the fix is > going to be the right one in Qt 4.8 anyway as it may need to be redone and > thus a fresh review etc needs to happen. True. But in most cases only small changes will be require for the backport. And in any case, that work need to be done anyway, as the commit must eventualy end in Qt 5, hence in gerrit. > So wouldn't it be better to do > it the other way around which to me makes more logical sense. Do it in Qt > 4.8 and then move it to Qt 5. The change will eventually need to be put in Qt5's gerrit, so better sooner than later. Morever, currently, you have a good infrastructure to get review in Qt5. And having a patch included in Qt5 is already a great step towards having it included in Qt 4.8 since the actual review is already done. (The only remaining reviews is the on the conflicts, if any. And "Is this change a candidate for a patch release?" kind of questions) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On 12/16/11 1:18 PM, "Olivier Goffart" wrote: >On Friday 16 December 2011 12:48:32 Thiago Macieira wrote: >> On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: >> > One idea is to have an automated process that propose the changes to >> > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes >> > of what has been done to update the Qt5 sha1, e.g. >> > http://codereview.qt-project.org/11239), but at this stage is just an >> > idea. >> I still prefer merges, the Qt 4 way. This is something we'll need to >>figure >> out by the time we branch 5.0 from 5.1. > >The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the >way >it worked in Qt 4 in order to work with gerrit. (the merge need to go >through >the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1 >meaning >they need followup commit.) In Qt 4 it worked because the CI system was >merging branches, and there was the qt-4.8-from-4.7 branch that as merged >by >CI. But gerrit do not play well with branches (yet?). > > >But the more imediate problem is the problem to ensure that bugfixes in >4.8 >also get submited in Qt 5. >There, merging is not possible as the repository are different, one must >cherry pick. >There are cases were a commit make no sens in Qt5 (symbian code for >example) >But in most case, changes should go in Qt5 >The commit should first be submitted to gerrit and get proper review >there. >Then, once they passed the CI system in Qt5, they can be cherry-picked in >Qt >4.8. >The rationale was that gerrit is the appropriate tool for the review, so >the >commit can grow there. Then, once ready, be integrated. While I agree that gerrit is the proper system to get a review now. I disagree with the process being that it goes into Qt 5 and then backported, the fact it passed in Qt 5 is not a guarantee that the fix is going to be the right one in Qt 4.8 anyway as it may need to be redone and thus a fresh review etc needs to happen. So wouldn't it be better to do it the other way around which to me makes more logical sense. Do it in Qt 4.8 and then move it to Qt 5. Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Friday, 16 de December de 2011 13.18.35, Olivier Goffart wrote: > On Friday 16 December 2011 12:48:32 Thiago Macieira wrote: > > On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: > > > One idea is to have an automated process that propose the changes to > > > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes > > > of what has been done to update the Qt5 sha1, e.g. > > > http://codereview.qt-project.org/11239), but at this stage is just an > > > idea. > > > > I still prefer merges, the Qt 4 way. This is something we'll need to > > figure > > out by the time we branch 5.0 from 5.1. > > The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the way > it worked in Qt 4 in order to work with gerrit. (the merge need to go > through the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1 > meaning they need followup commit.) In Qt 4 it worked because the CI > system was merging branches, and there was the qt-4.8-from-4.7 branch that > as merged by CI. But gerrit do not play well with branches (yet?). Sounds like we need a thread on the post-feature-freeze branches... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Friday 16 December 2011 12:48:32 Thiago Macieira wrote: > On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: > > One idea is to have an automated process that propose the changes to > > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes > > of what has been done to update the Qt5 sha1, e.g. > > http://codereview.qt-project.org/11239), but at this stage is just an > > idea. > I still prefer merges, the Qt 4 way. This is something we'll need to figure > out by the time we branch 5.0 from 5.1. The Qt 5.0 to Qt 5.1 merging system will need adaptation compared to the way it worked in Qt 4 in order to work with gerrit. (the merge need to go through the CI, and sometimes, commit in Qt 5.0 would break tests in Qt 5.1 meaning they need followup commit.) In Qt 4 it worked because the CI system was merging branches, and there was the qt-4.8-from-4.7 branch that as merged by CI. But gerrit do not play well with branches (yet?). But the more imediate problem is the problem to ensure that bugfixes in 4.8 also get submited in Qt 5. There, merging is not possible as the repository are different, one must cherry pick. There are cases were a commit make no sens in Qt5 (symbian code for example) But in most case, changes should go in Qt5 The commit should first be submitted to gerrit and get proper review there. Then, once they passed the CI system in Qt5, they can be cherry-picked in Qt 4.8. The rationale was that gerrit is the appropriate tool for the review, so the commit can grow there. Then, once ready, be integrated. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Fri, Dec 16, 2011 at 11:07:03AM +0100, ext Sergio Ahumada wrote:
> On 12/15/2011 10:31 PM, ext Robin Burchell wrote:
> > Actually, when I read this a second time looking for something
> > relevant, I see the complete opposite:
> >
> > "11. Make sure you submit against the lowest applicable branch from
> > which a release is still planned. Cherry-picks ("backports") are
> > frowned upon, while forward-merging to more recent branches happens on
> > a regular basis."
>
right. exception added.
> Actually, if we move Qt 4.x to Gerrit, the automatic integration between
> Qt 4.(x-1) and Qt 4.x should be handled differently.
>
> One idea is to have an automated process that *propose* the changes to
> be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes
> of what has been done to update the Qt5 sha1, e.g.
> http://codereview.qt-project.org/11239), but at this stage is just an idea.
>
i think just proposing is "too weak" - that's nothing more than a cron
job which submits merge changes to gerrit. i would make it auto-approve
the merges. merge conflicts would shoot off a mail to QA/RM right away,
and failed integrations would appear on gerrit anyway.
what i'm not sure about is whether this should be actually a cron job at
all or rather a manual process. in creator we're trying to keep a "once
weekly, unless somebody does important bug fixes" regimen to keep the
number of merge commits low.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Friday, 16 de December de 2011 11.07.03, Sergio Ahumada wrote: > One idea is to have an automated process that propose the changes to > be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes > of what has been done to update the Qt5 sha1, e.g. > http://codereview.qt-project.org/11239), but at this stage is just an idea. I still prefer merges, the Qt 4 way. This is something we'll need to figure out by the time we branch 5.0 from 5.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
Hi,
On 12/15/2011 10:31 PM, ext Robin Burchell wrote:
> Hi,
>
> On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell
> wrote:
>>> Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?
>>
>> I'd agree that would make sense to be a policy. But for it to be a
>> policy, it needs to be documented and communicated somewhere. You
>> can't expect this information to just filter out by itself, or expect
>> that it's common sense for everyone.
>>
>> I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
>> Should it be?
>
> Actually, when I read this a second time looking for something
> relevant, I see the complete opposite:
>
> "11. Make sure you submit against the lowest applicable branch from
> which a release is still planned. Cherry-picks ("backports") are
> frowned upon, while forward-merging to more recent branches happens on
> a regular basis."
I think that was true for Qt 4.6 -> Qt 4.7 -> Qt 4.8
There was an automated process that used to merge changes from 4.6 into
4.7 and from 4.7 into 4.8. After the modularization, there is no
automated process from Qt 4.8 to Qt 5.
Actually, if we move Qt 4.x to Gerrit, the automatic integration between
Qt 4.(x-1) and Qt 4.x should be handled differently.
One idea is to have an automated process that *propose* the changes to
be merged from Qt 4.(x-1) to Qt 4.x in Gerrit as a patch (in the likes
of what has been done to update the Qt5 sha1, e.g.
http://codereview.qt-project.org/11239), but at this stage is just an idea.
Cheers,
--
Sergio Ahumada
Mobile Phones Middleware - Quality Engineering
http://wikis.in.nokia.com/QtQualityEngineering
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
On Thursday 15 December 2011 22:31:32 Robin Burchell wrote:
> Hi,
>
> On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell
wrote:
> >> Wasn't the policy to first push the code in Qt5, then backport in Qt
> >> 4.8?>
> > I'd agree that would make sense to be a policy. But for it to be a
> > policy, it needs to be documented and communicated somewhere. You
> > can't expect this information to just filter out by itself, or expect
> > that it's common sense for everyone.
> >
> > I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
> > Should it be?
>
> Actually, when I read this a second time looking for something
> relevant, I see the complete opposite:
>
> "11. Make sure you submit against the lowest applicable branch from
> which a release is still planned. Cherry-picks ("backports") are
> frowned upon, while forward-merging to more recent branches happens on
> a regular basis."
Well, that is when the branches lies in the same repository.
With Qt 4 cannot be merged in Qt 5 because of the modularisation.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)
Hi,
On Thu, Dec 15, 2011 at 10:26 PM, Robin Burchell wrote:
>> Wasn't the policy to first push the code in Qt5, then backport in Qt 4.8?
>
> I'd agree that would make sense to be a policy. But for it to be a
> policy, it needs to be documented and communicated somewhere. You
> can't expect this information to just filter out by itself, or expect
> that it's common sense for everyone.
>
> I don't see this listed on http://wiki.qt-project.org/Commit_Policy.
> Should it be?
Actually, when I read this a second time looking for something
relevant, I see the complete opposite:
"11. Make sure you submit against the lowest applicable branch from
which a release is still planned. Cherry-picks ("backports") are
frowned upon, while forward-merging to more recent branches happens on
a regular basis."
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
