On Sun, May 20, 2012 at 9:38 AM, Jeroen De Dauw <jeroended...@gmail.com> wrote: > Thinking about it, it would be nice to have a working post-commit review > workflow like we used to have, for those projects where gated trunk does > not work due to lack of quick review.
Would it help if we implemented a "unreviewed" branch that Jenkins automatically pushes to after verifying that the code works? We'd still want master to remain the way it is, but it seems like it might be cool to have a branch that works much the way the old post-commit review worked. It would mean more visibility for unreviewed code, since it'd be much easier for everyone to pull in all of the unreviewed code into their working repos. I have no idea how easy/feasible this is, but throwing this idea out there as something that might be helpful. For deployed extensions, it's pretty tough to go back to the post-commit model, since that would also mean going back to the far less predictable deployment schedule. On Sun, May 20, 2012 at 2:13 PM, Platonides <platoni...@gmail.com> wrote: > gerrit seems to be all for pre-review, yet I think we should use a tool > which supported post-review, too. (Note for the review-tool evaluation) > Currently, there's no way to mark as fixme a revision which already got > into the repository. It would be so nice to also have post-commit tagging system. Still an open feature request for Gerrit: http://code.google.com/p/gerrit/issues/detail?id=287 ...which we may need to pitch in a patch for if we ever want to see it implemented. Rob _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
