That sounds good. Thanks for clarifying !
Regards, Mridul On Tue, Jul 21, 2015 at 11:09 AM, Shivaram Venkataraman <shiva...@eecs.berkeley.edu> wrote: > Thats part of the confusion we are trying to fix here -- the repository used > to live in the mesos github account but was never a part of the Apache Mesos > project. It was a remnant part of Spark from when Spark used to live at > github.com/mesos/spark. > > Shivaram > > On Tue, Jul 21, 2015 at 11:03 AM, Mridul Muralidharan <mri...@gmail.com> > wrote: >> >> If I am not wrong, since the code was hosted within mesos project >> repo, I assume (atleast part of it) is owned by mesos project and so >> its PMC ? >> >> - Mridul >> >> On Tue, Jul 21, 2015 at 9:22 AM, Shivaram Venkataraman >> <shiva...@eecs.berkeley.edu> wrote: >> > There is technically no PMC for the spark-ec2 project (I guess we are >> > kind >> > of establishing one right now). I haven't heard anything from the Spark >> > PMC >> > on the dev list that might suggest a need for a vote so far. I will send >> > another round of email notification to the dev list when we have a JIRA >> > / PR >> > that actually moves the scripts (right now the only thing that changed >> > is >> > the location of some scripts in mesos/ to amplab/). >> > >> > Thanks >> > Shivaram >> > >> > On Mon, Jul 20, 2015 at 12:55 PM, Mridul Muralidharan <mri...@gmail.com> >> > wrote: >> >> >> >> Might be a good idea to get the PMC's of both projects to sign off to >> >> prevent future issues with apache. >> >> >> >> Regards, >> >> Mridul >> >> >> >> On Mon, Jul 20, 2015 at 12:01 PM, Shivaram Venkataraman >> >> <shiva...@eecs.berkeley.edu> wrote: >> >> > I've created https://github.com/amplab/spark-ec2 and added an initial >> >> > set of >> >> > committers. Note that this is not a fork of the existing >> >> > github.com/mesos/spark-ec2 and users will need to fork from here. >> >> > This >> >> > is >> >> > mostly to avoid the base-fork in pull requests being set incorrectly >> >> > etc. >> >> > >> >> > I'll be migrating some PRs / closing them in the old repo and will >> >> > also >> >> > update the README in that repo. >> >> > >> >> > Thanks >> >> > Shivaram >> >> > >> >> > On Fri, Jul 17, 2015 at 3:00 PM, Sean Owen <so...@cloudera.com> >> >> > wrote: >> >> >> >> >> >> On Fri, Jul 17, 2015 at 6:58 PM, Shivaram Venkataraman >> >> >> <shiva...@eecs.berkeley.edu> wrote: >> >> >> > I am not sure why the ASF JIRA can be only used to track one set >> >> >> > of >> >> >> > artifacts that are packaged and released together. I agree that >> >> >> > marking >> >> >> > a >> >> >> > fix version as 1.5 for a change in another repo doesn't make a lot >> >> >> > of >> >> >> > sense, >> >> >> > but we could just not use fix versions for the EC2 issues ? >> >> >> >> >> >> *shrug* it just seems harder and less natural to use ASF JIRA. >> >> >> What's >> >> >> the benefit? I agree it's not a big deal either way but it's a small >> >> >> part of the problem we're solving in the first place. I suspect that >> >> >> one way or the other, there would be issues filed both places, so >> >> >> this >> >> >> probably isn't worth debating. >> >> >> >> >> >> >> >> >> > My concerns are less about it being pushed out etc. For better or >> >> >> > worse >> >> >> > we >> >> >> > have had EC2 scripts be a part of the Spark distribution from a >> >> >> > very >> >> >> > early >> >> >> > stage (from version 0.5.0 if my git history reading is correct). >> >> >> > So >> >> >> > users >> >> >> > will assume that any error with EC2 scripts belong to the Spark >> >> >> > project. >> >> >> > In >> >> >> > addition almost all the contributions to the EC2 scripts come from >> >> >> > Spark >> >> >> > developers and so keeping the issues in the same mailing list / >> >> >> > JIRA >> >> >> > seems >> >> >> > natural. This I guess again relates to the question of managing >> >> >> > issues >> >> >> > for >> >> >> > code that isn't part of the Spark release artifact. >> >> >> >> >> >> Yeah good question -- Github doesn't give you a mailing list. I >> >> >> think >> >> >> dev@ would still be where it's discussed which is ... again 'part of >> >> >> the problem' but as you say, probably beneficial. It's a pretty low >> >> >> traffic topic anyway. >> >> >> >> >> >> >> >> >> > I'll create the amplab/spark-ec2 repo over the next couple of days >> >> >> > unless >> >> >> > there are more comments on this thread. This will at least >> >> >> > alleviate >> >> >> > some of >> >> >> > the naming confusion over using a repository in mesos and I'll >> >> >> > give >> >> >> > Sean, >> >> >> > Nick, Matthew commit access to it. I am still not convinced about >> >> >> > moving >> >> >> > the >> >> >> > issues over though. >> >> >> >> >> >> I won't move the issues. Maybe time tells whether one approach is >> >> >> better, or that it just doesn't matter. >> >> >> >> >> >> However it'd be a great opportunity to review and clear stale EC2 >> >> >> issues. >> >> > >> >> > >> > >> > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
