Merge or Cherry-Pick?

[Thiago Macieira]

On Wednesday, 2 de February de 2011 20:35:19 Andreas Hartmetz wrote:
> On Monday 31 January 2011 23:27:15 Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > > Hi,
> > > 
> > > something that hasn't been written down as far as I can see (if I
> > > overlooked it, please point me to it) is what the policy on kdelibs
> > > is
> > > to be now wrt. merging vs. cherry-picking of changes in branches and
> > > master?
> > 
> > Commit to 4.6, merge 4.6 into master.
> 
> That strategy fails for me.

Someone has to fix the conflicts first.

If we assume that everything that is in 4.6 is also in master right now, 
someone just needs to do:

	git checkout master
	git merge -s ours KDE/4.6

> I think you're all working on code that is not complicated enough :)

No, I'm working on more complicated code.

> I often test bugfixes in master for a week or two (the "many eyeballs"
> approach of free software) and then merge them to the stable branch when no
> regressions crop up.
> With bugfixes in stable that get merged to master I would have no place to
> put tentative bugfixes. That is very bad.

I still think the current procedure is wrong. You're not testing the stable 
release, there's no guarantee that you're solving the problem at all, or 
worse, that you're not making it worse.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358