In order to unblock the current situation, I've come around to just setting up aurora-compactor and aurora-pesos for now (later it may make sense to do aurora-pystachio and aurora-thermos as well.) If there ever becomes a consistent story for the mesos github organization, we can reevaluate.
Jake, what do we do about setting up these repositories? On Thu, Apr 23, 2015 at 7:14 PM, Jake Farrell <[email protected]> wrote: > Creating a project on Github as suggested does not give the IP rights to > the ASF for any of the code, it would be an external project and would no > different than keeping it as your personal github project. I do not think > this is a good route to start down for any Apache Aurora/Mesos additions > like this > > -Jake > > On Wed, Apr 22, 2015 at 4:33 PM, Brian Wickman <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 > > > > > > > > > >
