systemml-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niketan Pansare" <npan...@us.ibm.com>
Subject Re: Build passed/failed messages for pull requests
Date Mon, 01 May 2017 21:43:23 GMT

I am OK with variant of (2): The message giving the link when the PR is
created and/or if there are build failures. If this is not possible, then I
vote for option 3.

Thanks,

Niketan Pansare
IBM Almaden Research Center
E-mail: npansar At us.ibm.com
http://researcher.watson.ibm.com/researcher/view.php?person=us-npansar



From:	Deron Eriksson <deroneriksson@gmail.com>
To:	dev@systemml.incubator.apache.org
Date:	05/01/2017 02:40 PM
Subject:	Re: Build passed/failed messages for pull requests



Would anyone else in our SystemML community care to comment?

So far we have a tie:
  3 for option 2 - Dusenberry, Jindall, and Eriksson
  3 for option 3 - Boehm, Surve, and Weidner

Deron



On Fri, Apr 28, 2017 at 12:53 PM, <dusenberrymw@gmail.com> wrote:

> I would prefer option 2.
>
> --
>
> Mike Dusenberry
> GitHub: github.com/dusenberrymw
> LinkedIn: linkedin.com/in/mikedusenberry
>
> Sent from my iPhone.
>
>
> > On Apr 28, 2017, at 12:40 PM, Glenn Weidner <gweidner@us.ibm.com>
wrote:
> >
> > My preference is option 3.
> >
> > Thanks,
> > Glenn
> >
> >
> > Arvind Surve ---04/28/2017 11:09:48 AM---Agree, these messages are
> distractions.  Arvind Surve | Spark Technology Center  | http://www.spark
.
> >
> > From: Arvind Surve <acs_s@yahoo.com.INVALID>
> > To: "dev@systemml.incubator.apache.org" <dev@systemml.incubator.
> apache.org>
> > Date: 04/28/2017 11:09 AM
> > Subject: Re: Build passed/failed messages for pull requests
> >
> >
> >
> >
> > Agree, these messages are distractions.
> >  Arvind Surve | Spark Technology Center  | http://www.spark.tc/
> >
> >      From: Matthias Boehm <mboehm7@googlemail.com>
> > To: dev@systemml.incubator.apache.org
> > Sent: Friday, April 28, 2017 11:05 AM
> > Subject: Re: Build passed/failed messages for pull requests
> >
> > as I commented on one of these github comments, I'm strongly against
> > these kind of unnecessary messages because they distract from the
actual
> > discussions. I already had to change my notification settings
> > accordingly - essentially I'm not watching SystemML's PR activity any
> > more.
> >
> > Regards,
> > Matthias
> >
> > On 4/28/2017 10:42 AM, Deron Eriksson wrote:
> > > Hi,
> > >
> > > When a pull request is created or another commit is pushed to that
pull
> > > request, a build including running our test suite is performed
> (Jenkins at
> > > https://sparktc.ibmcloud.com/jenkins/job/SystemML-PullRequestBuilder/
> ).
> > > This is the same model that other projects such as Apache Spark use
> > > (Jenkins at
> > > https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/).
> > >
> > > A few days ago, automated build passed/failed pull request messages
> were
> > > introduced to our pull requests, following the same type of Spark
> model.
> > > A) SystemML example: https://github.com/apache/
> incubator-systemml/pull/442
> > > B) Spark example: https://github.com/apache/spark/pull/17765
> > >
> > > Personally I like these messages because for contributors that do
pull
> > > requests, it automatically tells them the status of the build for
their
> > > pull requests and gives them a direct link to the build/test results.
> An
> > > opposing viewpoint would be that these messages are somewhat like
spam.
> > >
> > > So we should make a public decision on the mailing list what to do
> about
> > > these automated build status messages.
> > >
> > > Some options:
> > > (1) keep the automated messages exactly as they are
> > > (2) keep the automated messages, but consolidate the two messages
into
> one
> > > (such as "Build successful" and "Refer to this link...").
> > > (3) get rid of the automated messages
> > >
> > > I like (2). Any other opinions or options?
> > >
> > > Thoughts?
> > >
> > > Deron
> > >
> > >
> >
> >
> >
> >
> >
>



--
Deron Eriksson
Spark Technology Center
http://www.spark.tc/



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