+1, this is essentially my position, and I agree with the baseline requirements
for a merged project. I'm not trying to rule anything out, just wondering what
the optimal division is.
I think from the user point of view we can hopefully achieve the same
appearance with or without the same project governance. The goal should
absolutely be to have "official" drivers, and close association. We can link
them directly in the Cassandra site either way. The question is only how the
projects are best structured.
It seems to me that drivers benefit from an umbrella structure for their
governance and for discussing their commonalities and direction, but also need
their own distinct lists and Jira. So we'd be talking about going from a flat
hierarchy to perhaps a three-tier structure, something like:
PMC
/ \
Drivers Cassandra
/ | \ \
Driver1 Dvr.2 Dvr.3 ... Sidecar?
Since drivers are functionally very different to the database server and its
accoutrements, there will likely be very different kinds of discussions, with
completely different release schedules - hopefully mostly around programmatic
API UX, client-side performance, etc. It feels to me intuitively like there is
benefit in keeping distinct the projects with different focuses and technical
problems, so that discussions more easily can happen simultaneously at the
design and decision-making levels.
This might not only help avoid fragmentation of the decision-making in this
community, but also help unify decision-making across the drivers. By having a
decision-making body whose purview is only drivers, we might better emphasise
collaboration between those drivers, since that is the body's only function.
I'm not staking this out as a strongly held prior conviction, just that I see
these problems and think we have to consider this carefully upfront, as I don't
think this kind of decision is easy to revisit.
On 27/04/2020, 10:51, "Sylvain Lebresne" <[email protected]> wrote:
Fwiw, I agree with the concerns raised by Benedict, and think we should
carefully think about how this is handled. Which isn't not a rejection of
the donation in any way.
Drivers are not small projects, and the majority of their day to day
maintenance is unrelated to the server (and the reverse is true).
From the user point of view, I think it would be fabulous that Cassandra
appears like one project with a server and some official drivers, with one
coherent website and documentation for all. I'm all for striving for that.
Behind the scenes however, I feel tings should be setup so that some amount
of
separation remains between server and whichever drivers are donated and
accepted, or I'm fairly sure things would get messy very quickly[1]). In my
mind that means *at a minimum*:
- separate JIRA projects.
- dedicated _dev_ (and commits) mailing lists.
But it's also worth thinking whether a single pool of committers/PMC
members is
desirable.
Tbc, I'm not sure what is the best way to achieve this within the
constraint of
the Apache fundation, and maybe I'm just stating the obvious here.
[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.
--
Sylvain
On Fri, Apr 24, 2020 at 12:54 AM Benedict Elliott Smith
<[email protected]>
wrote:
> Do you have some examples of issues?
>
> So, to explain my thinking: I believe there is value in most contributors
> being able to know and understand a majority of what the project
> undertakes. Many people track a wide variety of activity on the project,
> and whether they express an opinion they probably form one and will
involve
> themselves if they consider it important to do so. I worry that importing
> several distinct and only loosely related projects to the same governance
> and communication structures has a strong potential to undermine that
> capability, as people begin to assume that activity and decision-making is
> unrelated to them - and if that happens I think something important is
lost.
>
> The sidecar challenges this already but seems hopefully manageable: it is
> a logical extension of Cassandra, existing primarily to plug gaps in
> Cassandra's own functionality, and features may migrate to Cassandra over
> time. It is likely to have releases closely tied to Cassandra itself.
> Other subprojects are so far exclusively for consumption by the Cassandra
> project itself, and are all naturally coupled.
>
> Drivers however are inherently arms-length endeavours: we publish a
> protocol specification, and driver maintainers implement it. They are
> otherwise fairly independent, and while a dialogue is helpful it does not
> need to be controlled by a single entity. Many drivers will continue to
be
> controlled by others, as they have been until now. We're of course able
to
> ensure there's a strong overlap of governance, which I think would be very
> helpful, and something Curator and Zookeeper seem not to have managed.
>
> Looking at the Curator website, it also seems to pitch itself as a
> relatively opinionated product, and much more than a driver. I hope the
> recipe for conflict in our case is much more limited given the functional
> scope of a driver - and anyway better avoided with more integrated, but
> still distinct governance.
>
> That's not to say I don't see some value in the project controlling the
> driver directly, I just worry about the above.
>
>
>
> On 22/04/2020, 21:25, "Nate McCall" <[email protected]> wrote:
>
> On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith <
> [email protected]>
> wrote:
>
> > I welcome the donation, and hope we are able to accept all of the
> > drivers. This is really great news IMO.
> >
> > I do however wonder if the project may be accumulating too many
> > sub-projects? I wonder if it's time to think about splitting, and
> perhaps
> > incubating a project for the drivers?
> >
>
> This is a legit concern and good question, but I think this is more a
> natural evolution of growing a project. There is precedent for this in
> Spark, Beam, Hadoop and others who have a number of different
> repositories
> under the general project umbrella.
>
> What I would like to avoid is a situation like with Apache Curator and
> Apache Zookeeper. The former being a zookeeper client donation from
> Netflix
> that came in as a top level project. From the peanut gallery, it seems
> like
> that has been less than ideal a couple of times in the past
> coordinating
> releases, trademarks and such with separate project management.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
