minutes of ESC call ...

[David Ostrovsky]

On Mon, 2016-07-04 at 09:34 -0500, Norbert Thiebaud wrote:
> On Sun, Jul 3, 2016 at 3:59 PM, David Ostrovsky <d.ostrovsky at gmx.de>
> wrote:
> > On Thu Jun 30 15:46:27 UTC 2016 Michael Meeks wrote:
[...]
> > I think you are confused.
> 
> No, although using 3 different back-end is indeed a confused design.
> and yes H2 is off-limit.. but NoteDB hopefully will not be hidden
> behind a wall of java crap

After picking Java based Gerrit and Jenkins, really, just don't pick
Java based tool next time.

> 
> 
> > 
> > I do not have a better explanation how you came to the idea to mess
> > around with backend details of the persistent layer for change meta
> > data in Gerrit Code Review.
> 
> Because stream does not contain the necessary information to get the
> data...
> when I get a stream message about an approval +2 I do not know if
> that
> change was +1 verified by gerrit

Nobody ever told you to use stream events, but GQL.

> 
> > 
> > In the end you probably don't use emacs, to access content.xml from
> > ODT
> > file, if you want to read it, don't you?
> 
> I do not want to but I may have to.
> for instance how exactly do you handle duplicate account using
> 'gerrit
> front end' ?

Don't mix accounts and groups entities with change meta data.
The only way to fix duplicate account mess is sql, indeed,
but this is only because the infra team procrastinating to switch
to LDAP.

[...]
> select change_id || ',' || patch_set_id from patch_set_approvals
> where
> change_id in (select c.change_id from changes c, patch_sets p,
> patch_set_approvals a where status = 'n' and c.change_id =
> p.change_id
> and c.change_id = a.change_id and p.patch_set_id =
> c.current_patch_set_id and a.patch_set_id = c.current_patch_set_id
> and
> p.uploader_account_id = a.account_id and a.category_id = 'Code
> -Review'
> and a.value = 2) and category_id = 'Verified' and value = 1 and
> account_id = 1000855

What is the value of having (non working, because of missing
is:mergeable predicate) SQL statement if you don't have a database (in
near future)? Or is your plan to never upgrade to newer Gerrit
versions?

> how do you suggest to write that in 'GQL' query ? (note: teh querry
> above is missing a filter on the 'master' branch but that is trivial
> to add )

Have you read my original mail? Here is the fixed SQL version as GQL:

+ missing is:mergeable predicate
+ missing branch:master filter
+ missing exclusion of changes with reject votes on Code-Review (-2)
+ missing exclusion of changes with reject votes on Verified (-1)

project:core
branch:master
is:open
is:mergeable
label:Code-Review+2
label:Verified+1,ci at libreoffice.org
NOT label:Code-Review-2
NOT label:Verified-1 

> > This would dump the commit ids to supply to the gerrit review
> > command.
> > Iterating over the result above and calling (untested):
> > 
> > $ ssh logerrit gerrit review --submit <commit>

Actually it can be simplified, you don't need to iterate, as gerrit
review command accepts list of commits, so just add this one liner to
crontab and move forward with the life (untested):

ssh logerrit gerrit review --submit $(ssh logerrit gerrit query -
-current-patch-set "'project:core branch:master is:open is:mergeable
label:Code-Review+2 label:Verified+1,ci at libreoffice.org NOT label:Code
-Review-2 NOT label:Verified-1'" | grep "  revision:" | awk '{print
$2}' | xargs)

> yeah except you need to find a way to analyze the result of this not
> not try over and over again to submit the same patch that won't go
> for
> some reason (merge conflict for instance).

Nope. Just rely on Gerrit design and is:mergeable predicate from the
query above. If you have two commits, c_1 and c_2 that are both
mergeable separately, but c_2 cannot be merged because of conflicts,
once c_1 was merged, all you need is to wait for the next run of the
cronjob: c_2 would not be picked up any more. Why? Because after c_1 is
merged, post ref-updated hook is run for each open change on the
project, and c_2 would be marked as not mergeable, and is:mergeable
predicate in GQL above for this change would return false in the next
run. (The same happens, if c_1 would be merged manually in Gerrit, by
clicking the Submit button, obviously).