On Tue, Sep 6, 2016 at 12:56 PM, J-P Nurmi <jpnu...@qt.io> wrote: > On 06 Sep 2016, at 11:46, Konstantin Tokarev <annu...@yandex.ru> wrote: > > > > > > > > 06.09.2016, 12:44, "Oswald Buddenhagen" <oswald.buddenha...@qt.io>: > >>> On Mon, Sep 05, 2016 at 09:17:59PM +0000, J-P Nurmi wrote: > >>> On 05 Sep 2016, at 19:27, Marc Mutz <marc.m...@kdab.com> wrote: > >>> > It's not about restricting what a user can do. It's simply missing > >>> > implementation, and I believe that if it were easy to implement, > >>> > Ossi would have done it long ago instead of playing retarget-monkey > >>> > for the rest of us :) > >>> > >>> Doing it through the web UI would be a nice bonus, but having access > >>> to the same script that is already used by the admins would be good > >>> enough for starters. > >> > >> yep - because i'm totally going to give everyone full write access to > >> the database. ;) > >> > >> if you make a secure web frontend that authenticates against qt account > >> and verifies change ownership using the gerrit ssh interface, i'm > >> totally willing to deploy that. ;) > > > > Idea: IRC bot accepting retarget requests, with rate limit e.g. one > request per minute. Bot runs on host with db access and can do only this > one thing. > > Another idea: patch Gerrit to change the target branch (and create a new > patchset version to reset scores) when pushing to a different branch. >
I have another suggestion, which should be quite easy to implement. Either extend the sanity bot, or create a new bot, which listens on gerrit's event stream. If *the change's owner* (or an approver?) posts a comment reading "Please retarget <branch>", run your script on the server side. You need some sanity test that ensures this branch exists etc... What do you say? - Orgad
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development