On Wed, Aug 9, 2017 at 8:42 PM, Dibyendu Majumdar <mobile@xxxxxxxxxxxxxxx> wrote: > > It will also help me if I can assume that a patch will not be re-done. > At the moment I cannot apply any patch - because I do not know if a > new version of the patch will be published soon. Instead if changes > always go forward - i.e. you apply fixes to existing patches - then I > can safely apply a patch, and when a fix is published, apply the fix. Well, I can promise any thing apply to master, which will be the new integration happening on, will not be rebase or revert. If there is improvement of already applied patches. It will be a delta change apply to master. Master will not roll back, ever. It actually haven't. However, if the patch is not yet apply to master, the developer can come up with new versions. That I will not able to stop, there is no reason to. > > I learnt from database technology that it is better for changes to > always go forward - trying to revert past changes by undoing them is > troublesome as it means you may need to undo all changes that follow Yes, master will be always forwarding. It will also solve another problem, patches takes too long from sparse-next to reach master. So master will be where integration happens. There is no safe period like sparse-next any more. The topic branches will still control by their original developer, I don't have direct control unless that is my topic branch. > the one you want to undo. Progress can become very difficult in this > approach. That is why in databases, often undo is just another forward > change - there is no going back to remove a past change. A really good > description of this approach is given in the ARIES approach to > database recovery. I hope that answer your questions. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
