On Tue, Dec 17, 2013 at 8:28 AM, Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx> wrote: > The testing part could be solved by a queue branch: A bot periodically builds > the queue branch and if that works, someone can cherry-pick the changes from > the queue branch after 48h. The diffs are cherry-picked so that the history > mess of that queue branch does not get into master. So a patch could go > instantly into the queue branch and if it is rejected, a simple git revert on > the queue branch would revoke that patch. The master branch can be merged > into the queue branch regularly so that patches in the queue branch are based > on a current master. This creates quite a patch + revert mess in the history, > but a.) this is useful history and b.) as patches are only cherry-picked, > this history mess does not get into master. Every patch that has not been > reverted after 48h can then be considered ready for master. Of course, if the > build bot fails, it should be bisected (which would only need 2 or 3 steps as > the queue should not get too big within one day ;)) and the culprit be > reverted. > > How does that idea sound? I don't think anyone was contemplating *how* it should work - it's the act of setting up such a system, complete with Trac integration, that has been preventing such a system from being implemented. - Urias