[Releasing] [Development] HEADS UP: merge stable into release and dev into stable

Frederik Gladhorn frederik.gladhorn at digia.com
Tue Feb 18 09:39:02 CET 2014 

Tirsdag 18. februar 2014 08.19.04 skrev Heikkinen Jani:
> Hi Frederik & others!
> 
> > -----Original Message-----
> > From: Gladhorn Frederik
> > Sent: 17. helmikuuta 2014 14:24
> > To: releasing at qt-project.org
> > Cc: Heikkinen Jani; Paaso Matti
> > Subject: Re: [Development] HEADS UP: merge stable into release and dev
> > into stable
> > I have some questions about our merging process here.
> > To me it all seems a bit chaotic, but maybe I just don't see the big
> > picture.
> > 
> > The branches are listed here:
> > http://qt-project.org/wiki/Branch-Guidelines
> > 
> > But there is no word of how they are merged when the day comes.
> > My understanding is that we silently agree that it's best to do fast
> > forward merges when merging dev->stable and stable->release which leaves
> > any conflicts
> > to be resolved by the opposite direction.
> > 
> > Currently we don't have a clearly agreed set of git sha1s that should be
> > merged from dev->stable or stable->release which I find problematic.
> > We wait for some patches to make it in, allowing some random patches to
> > be
> > part of the next merge. To me this seems like we are chasing a moving
> > target.
> 
> I totally agree with you. This is somehow chaotic for example now: we had
> feature freeze on Friday but what it really means? There has been lots of
> changes in dev branch after that and all will be merged to the stable when
> we do the merge. I am not sure how to solve this, should it be tight time
> (midnight?) and that is the point from where we do the merge? Or should
> maintainers define the sha1s before feature freeze which must be used as a
> baseline for merge & coming release or what? Or then just do like now & do
> merge when we see we can do it & that way has as much flexibility as
> possible but accept that unclearness?
> > I think it makes more sense to just set a cut off date and time, e.g.
> > tonight and look at the patches that were in at that time.
> > Instead of trying to merge the tip of the respective branch, I would
> > suggest merging the sha1 of the last patch that was in the branch in
> > time.
> > 
> > For patches that should be in but that didn't make it through the
> > integration
> > in time, we should imho just re-target the branch that they are then
> > intended
> > for.
> 
> That is totally fine with me if we just define the process working like
> this. Any comments from someone else?
> > I was also a bit surprised to learn that the release team depended on
> > merges
> > done by me (without me being asked to do these). I generally merge
> > release-
> > 
> > >stable and stable->dev as often as I can without dropping everything else
> > 
> > that is on my plate. Relying on that for releases doesn't seem like a good
> > idea to me.
> 
> Well, I agree this shouldn't be your responsibility. I think it should be us
> in the release team who takes the responsibility to start the merges when
> needed but in case of conflicts we definitely needs help from
> maintainers/developers. Actually that was in our task list when Sergio left
> from team but then we notice you have done those merges before we even
> started to try it :) That's why it has somehow started to be your
> responsibility even it shouldn't... We can agree already now that we will
> take care of that in the future and ask help from you/other developers or
> maintainers when we face some problems. That way we are already doing with
> merges from dev -> stable & stable -> release...

I have been doing these for over a year, even with Sergio around, so the 
merges as such are no big deal. Running the script from qtrepotools doesn't 
cost any time. The only time where it gets interesting is when there are 
conflicts.

The problem is just not knowing what needs to be done when and how. My 
interest is of course to help getting Qt releases out as easily as possible.
I'd just like to know how to make this work and know before that a merge is 
needed (which is only the case when there are conflicts anyway, every clean 
merge is not interesting and can be done in any direction anyway).

Greetings,
Frederik


> 
> Br,
> Jani
> 
> > Greetings,
> > Frederik
> > 
> > Mandag 17. februar 2014 07.16.12 skrev Heikkinen Jani:
> > > Hi all,
> > > 
> > > It seems we cannot start merge from dev branch to stable at the moment
> > > because there is still some issues to be solved before that:
> > > 
> > > 1.      There seems to be compilation break in dev branch, see
> > > https://codereview.qt-project.org/#change,78283. That needs to be
> > 
> > solved
> > 
> > > first
> > > 
> > > 2.      There is still some merges ongoing from stable to dev branch
> > > 
> > > *        https://codereview.qt-project.org/#change,77965
> > > 
> > > *        https://codereview.qt-project.org/#change,77972
> > > 
> > > *        https://codereview.qt-project.org/#change,77977
> > > 
> > > *        https://codereview.qt-project.org/#change,77258
> > > 
> > > 3.      Adding qtwebsockets as a submodule is still ongoing, see
> > > https://codereview.qt-project.org/#change,76844
> > > 
> > > 4.      Merge from stable to release needs to be done before merge from
> > 
> > dev
> > 
> > > to stable. According to my understanding there isn't any blockers to do
> > > merge from stable to release. That will be started soon...
> > > 
> > > 
> > > There seems to be also lots of not integrated changes in dev branch at
> > > the
> > > moment but feature freeze date is gone and so on features for 5.3 should
> > 
> > be
> > 
> > > "locked". Finalizing new features & 5.3 release continues in stable
> > > branch
> > > after the merge so let's put all effort to fix those remaining merge
> > > blockers to be able to do the merge as soon as possible.
> > > 
> > > Br,
> > > Jani
> > > 
> > > 
> > > 
> > > From: development-bounces+jani.heikkinen=digia.com at qt-project.org
> > > [mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org]
> > 
> > On
> > 
> > > Behalf Of Paaso Matti Sent: 11. helmikuuta 2014 11:52
> > > To: development at qt-project.org
> > > Cc: releasing at qt-project.org
> > > Subject: [Development] HEADS UP: merge stable into release and dev into
> > > stable
> > > 
> > > Hi,
> > > 
> > > 
> > > We plan to merge 'dev' branch (5.3) into stable branch on February 17th.
> > > And at the same time stable branch (5.2.2) is planned to be merged into
> > > release branch. This means that:
> > > 
> > > 
> > > 
> > > -If there is a need for 5.2.2 release, content will be ready in release
> > > branch.
> > > 
> > > -5.3.0 release content will be in stable branch.
> > > 
> > > 
> > > 
> > > After merge any changes that are required for 5.2.2 need to be pushed to
> > 
> > the
> > 
> > > 'release' branch and changes that are required for 5.3 need to be pushed
> > 
> > to
> > 
> > > the 'stable' branch.
> > > 
> > > So if your changes are not in by that day, please wait until the merge
> > > is
> > > done and re-target it to the correct branch.
> > > 
> > > 
> > > 
> > > The repositories that will be part of the  merges are:
> > > 
> > > - qt5
> > > - qtactiveqt
> > > - qtandroidextras
> > > - qtbase
> > > - qtconnectivity
> > > - qtdeclarative
> > > - qtdoc
> > > - qtgraphicaleffects
> > > - qtimageformats
> > > - qtlocation
> > > - qtmacextras
> > > - qtmultimedia
> > > - qtquick1
> > > - qtquickcontrols
> > > - qtscript
> > > - qtsensors
> > > - qtserialport
> > > - qtsvg
> > > - qttools
> > > - qttranslations
> > > - qtwebkit
> > > - qtwebkit-examples
> > > - qtwinextras
> > > - qtxmlpatterns
> > > - qtx11extras
> > > 
> > > Is there a new repositories planned to be included into 5.3.0? If so,
> > > stable branch for those has to be created if not exist yet.
> > > 
> > > [1]
> > > http://lists.qt-project.org/pipermail/releasing/2014-> > 
> > February/001595.html
> > 
> > > Cheers,
> > > --
> > > Matti Paaso
> > > SW Engineer - Digia, Qt
> > 
> > --
> > Best regards,
> > Frederik Gladhorn
> > Senior Software Engineer - Digia, Qt
> > Visit us on: http://qt.digia.com

-- 
Best regards,
Frederik Gladhorn
Senior Software Engineer - Digia, Qt
Visit us on: http://qt.digia.com

More information about the Releasing mailing list