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

[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...

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