asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Blow <>
Subject Re: BAD flag on code reviews
Date Sun, 04 Jun 2017 14:25:54 GMT

Testing coordinated changes between asterixdb & asterixdb-bad repos is now
a little easier:

Exact-match on topic is now used by the asterixdb bad & bad compat jobs to
include both an
*DB & Bad change as part of testing.  Instead of specifying a refspec as
the topic to indicate what
version of a patchset to pick up, simply set the topic on both the *DB and
BAD changes to be the
same string.  Tour local branch name or some other logical name might be
helpful when selecting a
topic name.  Note the topic must be unique for open changes in the project.


git gerrit submit -t mblow/make_it_go

Reminder: as the Jenkins plugin does not trigger on topic changes, you'll
need to query & re-trigger the Jenkins job
or publish a new patch after setting the topics.



On Thu, Dec 15, 2016 at 12:33 PM Steven Jacobs <> wrote:

> Hi all,
> Those of you with reviews going on may have noticed that there is a new
> column on gerrit, called bad. This flag is because we now have an apache
> codebase for the BAD extension (You can see it here if you are interested:
> which enables
> channels and soon stored procedures.
> The BAD extension is dependent on the core of Asterix itself. The new flag
> is to check whether new changes to Asterix will break the BAD extension. In
> general most changes should be getting a +1 here. The main thing we are
> trying to avoid is a change to Asterix intended as an enhancement or
> cleanup that inadvertently removes functionality needed for Asterix
> extensions.
> "What should I do if I see a -1?"
> If you do happen to get a -1 from BAD, the easy thing to do is to add me
> (or another extension expert such as Till or Abdullah) to the code review.
> That way I can look at the affecting part of the change and see how to
> handle it.
> Please let me know if you have any questions or concerns.
> Thanks,
> Steven

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message