Sveto, On 2010-02-25, at 10:37 AM, Justin wrote: > 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.
We're going to unfreeze trunk very soon and move Engage 0.3b3 development work into a branch, so you shouldn't have to wait quite as long as Justin suggests. :) > 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. Sure, ideally patches will be standalone, but in reality that's probably not always going to happen. Sveto, I'm fine if you create patches that depend on each other, especially if it enables you to create patches that contain fewer major changes per patch. Again, the problem is the case where you've got a fix for one major issue mixed in with a change for a more minor issue. Also cases where one fix is more suitable than the other. By splitting up the patches, it's at least easier to see each fix in isolation. None of this is ideal, and I hope it will be all mitigated by an eventual move to Mercurial. I hope this helps, Colin --- Colin Clark Technical Lead, Fluid Project http://fluidproject.org _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
