[Development] Cherry picking to replace a change set

Stephen Kelly stephen.kelly at kdab.com
Tue Sep 3 11:49:03 CEST 2013


On Tuesday, September 03, 2013 11:42:04 Oswald Buddenhagen wrote:
> On Mon, Sep 02, 2013 at 11:37:03AM -0700, Thiago Macieira wrote:
> > On segunda-feira, 2 de setembro de 2013 18:46:37, Oswald Buddenhagen 
wrote:
> > > in fact, point 4 of the commit policy is pretty clear on that matter. it
> > > is absurd to remove function (specific to the scope of the commit) from
> > > the definition of atomicity.
> > > also, the policy does not know a "topic" concept, for good reasons. you
> > > cannot use topics (or branches which you intend to merge, for that
> > > matter) as an excuse for violating the policy.
> > 
> > We established that I disagree with those definitions in a previous
> > discussion on this topic.
> 
> you did, however, make no effort to substantiate your position.
> an argument against your interpretation is for example bisectability.
> also, it's just plain illogical to tear apart an allegedly "too complex"
> change, because then assessing the pieces requires adding "external"
> context. which is just a less handy way to review one big change.

I agree with ossi here. 

Thanks,

-- 
Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com

Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130903/607387ee/attachment.sig>


More information about the Development mailing list