cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Brown <jasedbr...@gmail.com>
Subject Re: Testing and jira tickets
Date Thu, 09 Mar 2017 22:21:05 GMT
To Ariel's point, I don't think we can expect all contributors to run all
utesss/dtests, especially when the patch spans multiple branches. On that
front, I, like Ariel and many others, typically create our own branch of
the patch and have executed the tests. I think this is a reasonable system,
if slightly burdensome, given our project and our needs/demands on it.

Whoever runs the test, is it reasonable to expect the results to become
available on the ticket? As the CI is moving to the Apache infrastructure,
that will be the final arbiter of " patch works or breaks things", but I
suspect executing the tests anywhere else will still be a very good
indicator of the viability of the patch.

Thoughts?

On Thu, Mar 9, 2017 at 12:31 PM, Ariel Weisberg <ariel@weisberg.ws> wrote:

> Hi,
>
> Before this change I had already been queuing the jobs myself as a
> reviewer. It also happens to be that many reviewers are committers. I
> wouldn't ask contributors to run the dtests/utests for any purpose other
> then so that they know the submission is done.
>
> Even if they did and they pass it doesn't matter. It only matters if it
> passes in CI. If it fails in CI but passes on their desktop it's not
> good enough so we have to run in CI anyways.
>
> If a reviewer is not a committer. Well they can ask someone else to do
> it? I know we have issues with responsiveness, but I would make myself
> available for that. It shouldn't be a big problem because if someone is
> doing a lot of reviews they should be a committer right?
>
> Regards,
> Ariel
>
> On Thu, Mar 9, 2017, at 01:51 PM, Jason Brown wrote:
> > Hey all,
> >
> > A nice convention we've stumbled into wrt to patches submitted via Jira
> > is
> > to post the results of unit test and dtest runs to the ticket (to show
> > the
> > patch doesn't break things). Many contributors have used the
> > DataStax-provided cassci system, but that's not the best long term
> > solution. To that end, I'd like to start a conversation about what is the
> > best way to proceed going forward, and then add it to the "How to
> > contribute" docs.
> >
> > As an example, should contributors/committers run dtests and unit tests
> > on
> > *some* machine (publicly available or otherwise), and then post those
> > results to the ticket? This could be a link to a build system, like what
> > we
> > have with cassci, or just  upload the output of the test run(s).
> >
> > I don't have any fixed notions, and am looking forward to hearing other's
> > ideas.
> >
> > Thanks,
> >
> > -Jason
> >
> > p.s. a big thank you to DataStax for providing the cassci system
>

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