This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 00/10] nptl: Fix Race conditions in pthread cancellation (BZ#12683)


On Fri, 18 Sep 2015, Adhemerval Zanella wrote:

> > To the extent that the 
> > patches will all go in one commit anyway, could you use a division into 
> > patches that more logically reflects the different parts of the change.  
> > (To the extent that patches can go in separate commits - Phil Blundell's 
> > new tests come to mind, unless there's some reason they depend on other 
> > changes - they should be posted and reviewed separately so they can go in 
> > before the rest of the patch series.)
> > 
> 
> Ok, I will create a patch to include Phil's new testscase.  For the rest of
> patchset since it require very internal changes I see the architecture
> approach of fixing each one with one patch a better approach than add
> platform neutral patches that let the tree broken for all architectures.

As the *commit* organization, yes, the bulk of the 
architecture-independent changes should go in the same commit as the fixes 
for as many architectures as possible.

As the *patch posting* organization, however, that means you can split the 
patches for posting in whatever way is most convenient for the reader 
without regard to whether the state of the tree after some subset of the 
patches is internally consistent or works on a particular architecture.  
Which means that the powerpc64 patch contains only powerpc64 changes, for 
example, not the architecture-specific changes, and the i386 changes go in 
the i386 patch, not the powerpc32 patch even if it depends on some of 
them.

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]