Merge or Cherry-Pick?

[Thiago Macieira]

On Monday, 31 de January de 2011 23:50:49 Oswald Buddenhagen wrote:
> On Mon, Jan 31, 2011 at 11:27:15PM +0100, Thiago Macieira wrote:
> > On Monday, 31 de January de 2011 22:58:52 Andreas Pakulat wrote:
> > > 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's hard enough in qt, and there is totally no way that kde's
> discipline would be sufficient to make forward-merging feasible (as in
> "actually helpful and producing an even remotely readable history").

Only because in Qt we do it in batches, so we get lots of changes. And the Qt 
repository is way bigger than anything KDE has.

If people merge after they've applied a change to the previous version, only 
their change needs merging. If it conflicts, it's your change.

> therefore i'm for cherry-picking, preferably with a mandated -x flag.
> of course that means no merge tracking whatsover, which is about as much
> as we used from svn when it comes to bugfix backports.

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110201/266aeebb/attachment.sig>