aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Ignazio <ro...@puppetlabs.com>
Subject Re: the status of pesos
Date Wed, 22 Apr 2015 20:45:32 GMT
I think that putting the Pesos project in an aurora* organization on GitHub
might lead to the same confusion that you're concerned about with calling
it aurora-pesos (or something to that effect). Personally, I think Pesos
benefits the Mesos community at large, and I'm in favor of Zameer's
approach: transferring ownership to the mesos GitHub organization.

-- Roger

On Wed, Apr 22, 2015 at 1:33 PM, Brian Wickman <wickman@apache.org> wrote:

> My only reservation with aurora-* repos is that it discourages discovery
> and will lead to confusion about the scope of the projects.  pesos and
> compactor are broadly useful to the mesos ecosystem, so names like
> 'aurora-pesos' can genuinely draw people away.
>
> It sounds like the main concerns people have with the status quo revolves
> around ownership (who can merge patches) and quality (that all code merged
> to master is reviewed with the same scrutiny as the rest of Aurora.)  I
> think these are reasonable concerns, but I think they're more valid once we
> rely upon the code for production.  Right now pesos is purely an optional
> feature, so I don't think that the above review should be blocked on the
> "incubating" nature of pesos, otherwise we'll be stuck with a
> chicken-and-egg situation where we have little way to vet the code in a
> meaningful way.
>
> Here's a counterproposal: we create an Aurora top level project on github a
> la mesos (call it aurora-incubating, aurora-project, apache-aurora,
> whatever, since aurora is taken), giving all committers write access to all
> projects therein.  We may not be able to rely upon reviewboard, but we can
> at least solve the problem of ownership.
>
> Thoughts?
>
>
>
>
> On Mon, Apr 20, 2015 at 7:29 PM, Jake Farrell <jfarrell@apache.org> wrote:
>
> > We only sync reviewboard repos from our git-wip or svn servers. I would
> > recommend that we move them into aurora-<project> name git repos so they
> > can have their own release cycles
> >
> > -Jake
> >
> > On Mon, Apr 20, 2015 at 5:50 PM, Brian Wickman <wickman@apache.org>
> wrote:
> >
> > >  I started work in r/32373 <https://reviews.apache.org/r/32373/> to
> add
> > > pesos <https://github.com/wickman/pesos> support for the Aurora
> > executor.
> > > Pesos is a pure python implementation of the Mesos API.  Adding Pesos
> > > support to Aurora will pave the way towards "pip install" and the
> > standard
> > > python packaging toolchain as a means to package/install the Aurora
> > > executor, without relying upon a cumbersome Mesos build process that is
> > > predicated on the nuances of libmesos and its myriad dependencies e.g.
> > > glibc, C++11 and libsvn/apr.
> > >
> > > Pesos and its dependent library, compactor
> > > <https://github.com/wickman/compactor>, are both projects on my
> personal
> > > github.  I'd like to keep them independent repositories.  My experience
> > > shows that vendoring these sorts of things reduces discoverability and
> > > peoples' willingness to contribute, and increases likelihood of forks.
> > >
> > > That being said, I'm not convinced they should be under my personal
> > github
> > > either because I'm a poor BDFL
> > > <http://en.wikipedia.org/wiki/Benevolent_dictator_for_life> candidate.
> > > Instead they should either be under the moniker of the mesos github
> > > organization (there is precedent <https://github.com/mesos/mesos-go>
> for
> > > this) or we should create an Aurora organization for third party
> projects
> > > that tend to be developed under the Aurora umbrella, e.g. pystachio.
> > >
> > > Regardless of where they live, I think we should immediately start
> using
> > > reviewboard to do code reviews for patches.  Does anyone know if this
> is
> > > feasible using reviews.apache.org if the code does not live under the
> > > apache umbrella?  (The code itself is Apache licensed.)
> > >
> > > ~brian
> > >
> >
>

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