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
