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. > >> > > >> > > > > > >
