Again, used the wrong e-mail adddress... Please see the forwarded message below.

Begin forwarded message:

> Resent-From: Justin <[email protected]>
> From: [email protected]
> Date: February 25, 2010 11:11:03 AM EST
> Resent-To: Justin Obara <[email protected]>
> To: [email protected]
> Subject: Re: Patch for testing My Collection send email parameters
> 
> Thank you for posting to the fluid-work mailing list. Unfortunately,
> we are unable to post your message because you are not a member of the
> list. Please join the fluid-work mailing list
> (http://fluidproject.org/mailman/listinfo/fluid-work) and repost your
> message, or contact the list administrators
> [email protected] for help. 
> 
> 
> 
> From: Justin <[email protected]>
> Date: February 25, 2010 10:37:08 AM EST
> To: Svetoslav Nedkov <[email protected]>
> Cc: Colin Clark <[email protected]>, Fluid Work 
> <[email protected]>
> Subject: Re: Patch for testing My Collection send email parameters
> 
> 
> Hi Sveto, 
> 
> Thanks for the patch. Right now we are only making commits that affect what 
> we need to get done for performance. So don't be surprised or worried if it 
> takes a couple of weeks to get reviewed and committed.
> 
> On 2010-02-25, at 7:02 AM, Svetoslav Nedkov wrote:
> 
>> Also I have a question about the best approach for creating patches 
>> modifying the same code - this seems to limit the possibility to work on two 
>> issues before the first one is resolved. So the only solution I could think 
>> of was to create two patches for patch B created after patch A over the same 
>> code base - one that is supposed to be applied after patch A and one that 
>> could be applied separately without the changes from A. This will involve 
>> implementing the changes twice. Can you advise on that issue?
> 
> I'm not exactly sure what you mean by same code. Do you mean in the same file 
> or for example the same function?
> 
> I defer to Colin on this one. He's reviewed and submitted far more patches 
> than I have. However, I think in general though it would be better if patches 
> were self contained, non-conflicting and no dependencies between them. So 
> neither A nor B should contain the same changes. I understand that this may 
> not always be possible, so in those circumstances creating two patches for 
> the same issue may be the appropriate solution. But again, Colin may have 
> some more insight into this. 
> 
> Hope I've helped somewhat.
> JustinHi Sveto, 
> 
> Thanks for the patch. Right now we are only making commits that affect what 
> we need to get done for performance. So don't be surprised or worried if it 
> takes a couple of weeks to get reviewed and committed.
> 
> On 2010-02-25, at 7:02 AM, Svetoslav Nedkov wrote:
> 
>> Also I have a question about the best approach for creating patches 
>> modifying the same code - this seems to limit the possibility to work on two 
>> issues before the first one is resolved. So the only solution I could think 
>> of was to create two patches for patch B created after patch A over the same 
>> code base - one that is supposed to be applied after patch A and one that 
>> could be applied separately without the changes from A. This will involve 
>> implementing the changes twice. Can you advise on that issue?
> 
> I'm not exactly sure what you mean by same code. Do you mean in the same file 
> or for example the same function?
> 
> I defer to Colin on this one. He's reviewed and submitted far more patches 
> than I have. However, I think in general though it would be better if patches 
> were self contained, non-conflicting and no dependencies between them. So 
> neither A nor B should contain the same changes. I understand that this may 
> not always be possible, so in those circumstances creating two patches for 
> the same issue may be the appropriate solution. But again, Colin may have 
> some more insight into this. 
> 
> Hope I've helped somewhat.
> Justin
> 

_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://fluidproject.org/mailman/listinfo/fluid-work

Reply via email to