Luciano: Yes, there was a bit of confusion and hence wanted to iron things out to foster collaboration and community feedback on GPU backend.
There are multiple issues: 1. Any work on smaller GPU PRs is dependent on the initial PR getting into the master (as the initial PR contains the buffer-pool integration logic). Or at least, everyone agreeing with the design of the initial PR. 2. There is an interest in collaborating on the initial PR itself and I would like to see collaboration from early on (See https://issues.apache.org/jira/browse/SYSTEMML-701 and https://issues.apache.org/jira/browse/SYSTEMML-702). 3. The policy of squashing the PR into one commit essentially means only one person's work will be acknowledged. I am little uneasy on asking people to collaborate and not acknowledging their work. For example: Mike's commit/references was lost when the https://github.com/apache/incubator-systemml/commit/c334c2c85bc9cbb343e63b5b28ff3a1c5098c7fa was delivered. 4. The initial PR is waiting for following items: - SystemML 0.10 released (as we agreed not to include GPU backend in 0.10 release). - The unknowns and concerns regarding GPU backend are discussed and addressed. - So as to resolve dev dependency issue pointed by Matthias, jcu*.jar needs to be hosted on local mvn repo. There are few alternative I have already explored in this direction: (a) Filed a PR against mavenized jcuda: https://github.com/MysterionRise/mavenized-jcuda/pull/15 (b) Hosted mvn repo using github mvn plugin. Here is how we can resolve system scope: <repositories> <repository> <id>central</id> <url>https://repo1.maven.org/maven2</url> <releases> <enabled>true</enabled> </releases> </repository> <repository> <id>mavenized-jcuda-mvn-repo</id> <url>https://raw.github.com/niketanpansare/mavenized-jcuda/mvn- repo/</url> <snapshots> <enabled>true</enabled> <updatePolicy>always</updatePolicy> </snapshots> </repository> </repositories> .... <dependencies> <dependency> <groupId>org.mystic</groupId> <artifactId>mavenized-jcuda</artifactId> <version>0.7.5b</version> <scope>provided</scope> </dependency> </dependencies> 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: Luciano Resende <luckbr1...@gmail.com> To: dev@systemml.incubator.apache.org Date: 05/25/2016 10:06 AM Subject: Re: Discussion on GPU backend But, from the original question, I was under the impression that creating and merging multiple small prs were not a possible direction. If that is ok, then it's regular development practice. On Wed, May 25, 2016 at 9:20 AM, <dusenberr...@gmail.com> wrote: > In my opinion, the problem with using a separate branch with longer-term > work, rather than smaller PRs into the master, is that after several > commits, say 10 or 20, it becomes much more difficult to rebase without > running into nasty merge conflicts, especially when those conflicts are on > an intermediate commit so one would have to remember what the code looked > like at that point in time to properly fix the conflicts. To me, this > invites issues such as duplicated code and slower progress. > > -- > > Mike Dusenberry > GitHub: github.com/dusenberrymw > LinkedIn: linkedin.com/in/mikedusenberry > > Sent from my iPhone. > > > > On May 25, 2016, at 9:01 AM, Luciano Resende <luckbr1...@gmail.com> > wrote: > > > > On Wed, May 25, 2016 at 6:03 AM, Berthold Reinwald <reinw...@us.ibm.com> > > wrote: > > > >> the discussion is less about (1), (2), or (3). As practiced so far, (3) > is > >> the way to go. > >> > >> The question is about (A) or (B). Curious was the Apache suggested > >> practice is. > > Apache is key on fostering open collaboration, so specifically about > > branching, having a SystemML branch that is used for > > collaboration/experimentation is probably preferable, as it gives > > visibility to others on the community, enables iterative development > trough > > review of small patches, while shield the trunk of issues these > experiments > > can cause. > > > > I would just recommend to avoid making the branch stale, and keep > rebasing > > it with latest master, which will make integration much easier in the > > future. > > > > > > > > -- > > Luciano Resende > > http://twitter.com/lresende1975 > > http://lresende.blogspot.com/ > -- Luciano Resende http://twitter.com/lresende1975 http://lresende.blogspot.com/
