Hi Alex and Jeremy, We've been thinking of the driver codebase on a repository level in the CEP, which is why we do not mention any specific branch. To clarify, our intention is to donate the entire repository, including all existing commits, branches and tags. So don't worry: the Java driver 3.x branch would naturally be part of the donation. I will include a sentence in the CEP to make this statement explicit.
Thanks, Alex On Tue, Aug 4, 2020 at 8:30 PM Jeremy Chapman <jere...@netflix.com.invalid> wrote: > +1 on both starting with just the Java driver first and contributing all > 3.x and 4.x branches. Some of our long-running apps may continue using 3.x > for quite a while simply due to the extra effort due to their > deep-maintenance lifestyle. > > -Jeremy > > On Tue, Aug 4, 2020 at 4:26 AM Oleksandr Petrov < > oleksandr.pet...@gmail.com> > wrote: > > > I've tried to find this information in the document above, but couldn't > > find an explicit mention of it, possibly because it's implied. If we take > > java-driver as an example, is this CEP proposing to contribute all > branches > > (3.x and 4.x) or only the latest one? > > > > Thank you, > > -- Alex > > > > On Wed, Jul 29, 2020 at 12:16 PM Alexandre Dutra < > > alexandre.du...@datastax.com> wrote: > > > > > Hi Dinesh, > > > > > > While we think that maintaining the drivers together as a long-term > goal > > > would be beneficial as it would allow the drivers to evolve together > and > > > adopt similar design decisions, we also understand that donating 7 > > drivers > > > at once may put the whole operation at risk, as some folks here already > > > pointed out. > > > > > > The current CEP text actually advocates for a phased approach (see > > > "Approach" section): > > > > > > [...] the donation process will be iterative, and will start with only > > the > > > > Java driver in a first phase; then, in a second phase, it will be > > > extended > > > > to the remaining drivers. > > > > Once the Java driver is transferred, and before the others are > > > > transferred, we will revise the methodology described in this CEP, > and > > if > > > > necessary, revise its parameters and adjust them accordingly. A > second > > > CEP > > > > may be required if the changes to the methodology are found to be > > > > substantial. > > > > > > > > > > What do you think of this idea, does it sound reasonable ? > > > > > > Thanks, > > > > > > Alex > > > > > > On Mon, Jul 27, 2020 at 11:53 PM Dinesh Joshi <djo...@apache.org> > wrote: > > > > > > > Alexandre, > > > > > > > > I gave the document a quick read and TL;DR seems to be that we'd like > > to: > > > > > > > > 1. Bring in all drivers > > > > 2. They're part of the C* project > > > > > > > > If so, I would prefer if we add the Java driver first to the project. > > > > Based on that experience we can move forward with other drivers. > > > However, I > > > > am open to the idea of adding all the drivers to the project. > > > > > > > > Please correct me if I misunderstood something. > > > > > > > > Thanks, > > > > > > > > Dinesh > > > > > > > > > On Jul 26, 2020, at 8:41 PM, Nate McCall <zznat...@gmail.com> > wrote: > > > > > > > > > > This is fantastic, Alexandre, thanks for putting this together! > > > > > > > > > > I put an initial set of comments/concerns on there and will loop > back > > > > later > > > > > this week after other folks have a go. > > > > > > > > > > Cheers, > > > > > -Nate > > > > > > > > > > On Sat, Jul 25, 2020 at 7:35 AM Alexandre Dutra < > > > > > alexandre.du...@datastax.com> wrote: > > > > > > > > > >> Hi, > > > > >> > > > > >> As per the CEP process guidelines, I'm starting a formal DISCUSS > > > > >> thread to resume the conversation > > > > >> started here[1]. > > > > >> > > > > >> On behalf of the developers who maintain the DataStax drivers, I > > > > >> confirm that we are offering to > > > > >> donate to the Apache Software Foundation all seven DataStax-funded > > > > >> drivers, and are therefore > > > > >> opening this CEP[2] to discussion. > > > > >> > > > > >> In the CEP document linked above, we tried our best to address all > > the > > > > >> issues that we anticipate > > > > >> going forward with this endeavor, but the task is big: your > > > > >> suggestions, remarks and comments are > > > > >> most welcome. > > > > >> > > > > >> As stated previously, we understand that we're all primarily > focused > > > > >> on the C* 4.0 release > > > > >> currently; therefore we don't mind deferring any concrete progress > > on > > > > >> this until after C* 4.0 is > > > > >> out. > > > > >> > > > > >> However, as you can judge from the CEP draft document, the > donation > > is > > > > >> likely to have many > > > > >> implications on sensitive areas, e.g. on project governance; which > > is > > > > >> why we think best to open the > > > > >> discussion as early as possible, so that we all have enough time > to > > > > >> determine what we think best > > > > >> suits the project going forward. > > > > >> > > > > >> Kind regards, > > > > >> > > > > >> Alex Dutra > > > > >> > > > > >> [1] > > > > >> > > > > > > > > > > https://lists.apache.org/thread.html/ra7caa1dd42ccaa04bcabfbc33233995c125c655f9a3cdb2c7bd8e9f7%40%3Cdev.cassandra.apache.org%3E > > > > >> [2] > > > > >> > > > > > > > > > > https://docs.google.com/document/d/1e0SsZxjeTabzrMv99pCz9zIkkgWjUd4KL5Yp0GFzNnY/edit?usp=sharing > > > > >> > > > > >> -- > > > > >> Alexandre Dutra > > > > >> alexandre.du...@datastax.com > > > > >> > > > > >> > > --------------------------------------------------------------------- > > > > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > >> For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >> > > > > >> > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > -- > > > Alexandre Dutra > > > e. alexandre.du...@datastax.com > > > w. www.datastax.com > > > > > > > > > -- > > alex p > > > -- Alexandre Dutra e. alexandre.du...@datastax.com w. www.datastax.com
