[Development] Commit policy (was: Qt Commercial 4.8.0 release delta to LGPL version)

[Oswald Buddenhagen]

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.