Thanks everyone, I've created https://issues.apache.org/jira/browse/INFRA-26212

Kind Regards,
Brandon

On Thu, Oct 17, 2024 at 9:55 AM Ekaterina Dimitrova
<e.dimitr...@gmail.com> wrote:
>
> It would have been nice to be in red italic but… :-)
>
> Thanks, Brandon, +1 to the suggestion on my end too. Sounds reasonable to me
>
>
> On Thu, 17 Oct 2024 at 17:50, Abe Ratnofsky <a...@aber.io> wrote:
>>
>> +1 to CASSDRIVER-JAVA et al.
>>
>> On Oct 17, 2024, at 10:37 AM, Jon Haddad <j...@rustyrazorblade.com> wrote:
>>
>> Sgtm, let’s ship it
>>
>> +1
>>
>>
>>
>> On Thu, Oct 17, 2024 at 4:09 AM Brandon Williams <dri...@gmail.com> wrote:
>>>
>>> Nobody wants to suggest a color for this bikeshed?  I'll start:
>>> CASSDRIVER-<language>. I'd like to get on this sooner than later since
>>> during the time we wait the situation worsens.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Wed, Oct 2, 2024 at 5:07 PM Brandon Williams <dri...@gmail.com> wrote:
>>> >
>>> > I think we just need to ask infra to create the jira instances, but I
>>> > guess we need to have some kind of consistent naming scheme to help
>>> > identify them?
>>> >
>>> > Kind Regards,
>>> > Brandon
>>> >
>>> > On Wed, Oct 2, 2024 at 1:02 PM Francisco Guerrero <fran...@apache.org> 
>>> > wrote:
>>> > >
>>> > > +1 too on the points brought by Mick, we need more visibility into
>>> > > subprojects. For starters, we should look into integrating Qbot
>>> > > notifications in #cassandra-dev and #cassandra-noise for
>>> > > CASSANDRASC tickets. Let me know if I can help with that.
>>> > >
>>> > > On 2024/10/02 17:39:28 Yifan Cai wrote:
>>> > > > +1 on all the points raised by Mick. Please let me know if there is
>>> > > > anything I can help with.
>>> > > >
>>> > > > - Yifan
>>> > > >
>>> > > > On Wed, Oct 2, 2024 at 8:13 AM Josh McKenzie <jmcken...@apache.org> 
>>> > > > wrote:
>>> > > >
>>> > > > > - Qbot notifications in #cassandra-dev and #cassandra-noise , as 
>>> > > > > well as
>>> > > > > in any subproject channels
>>> > > > > - some cadence of dev@ ML updates, e.g. on activities, or dependency
>>> > > > > changes, etc
>>> > > > > - regular releases
>>> > > > >
>>> > > > > Agree on all 3 points. Also - I've *definitely* fallen off on the 
>>> > > > > project
>>> > > > > updates for mainline; I'll pick that back up after ApacheCon.
>>> > > > >
>>> > > > >
>>> > > > > On Wed, Oct 2, 2024, at 1:57 AM, Mick Semb Wever wrote:
>>> > > > >
>>> > > > > To play devil's advocate here, it's important that the subprojects 
>>> > > > > don't
>>> > > > > lose visibility and silo from the rest of the project.
>>> > > > >
>>> > > > > There are different ways to solve this, and lumping everything into 
>>> > > > > one
>>> > > > > jira project is a messy and poor way of doing it.  But as the 
>>> > > > > sidecar has
>>> > > > > shown us, subproject activity should somehow be made noisy to us.  
>>> > > > > We need
>>> > > > > sorts of common spaces in the project.
>>> > > > >
>>> > > > > If we go the separate jira project route, then some suggestions to 
>>> > > > > help
>>> > > > > with this are:
>>> > > > > - Qbot notifications in #cassandra-dev and #cassandra-noise , as 
>>> > > > > well as
>>> > > > > in any subproject channels
>>> > > > > - some cadence of dev@ ML updates, e.g. on activities, or dependency
>>> > > > > changes, etc
>>> > > > > - regular releases
>>> > > > >
>>> > > > >
>>> > > > > On Tue, 9 Apr 2024 at 04:11, Dinesh Joshi <djo...@apache.org> wrote:
>>> > > > >
>>> > > > > hi folks - sorry to have dropped the ball on responding to this 
>>> > > > > thread.
>>> > > > >
>>> > > > > My 2 cents are as follows -
>>> > > > >
>>> > > > > 1. Having a separate JIRA project for each sub-project will add 
>>> > > > > management
>>> > > > > overhead. This option, however, allows us to model unique workflows 
>>> > > > > for the
>>> > > > > sub-project.
>>> > > > >
>>> > > > > 2. Managing the sub-project as part of the Cassandra JIRA project 
>>> > > > > would
>>> > > > > imply less management overhead but the sub-project would need to 
>>> > > > > conform to
>>> > > > > the same workflows.
>>> > > > >
>>> > > > > I would pick option 1 unless there is a strong reason and desire to 
>>> > > > > manage
>>> > > > > a separate Jira project. We can always split out the Java Driver 
>>> > > > > project if
>>> > > > > things don't work out. OTOH merging a Jira project is harder.
>>> > > > >
>>> > > > > Thanks,
>>> > > > >
>>> > > > > Dinesh
>>> > > > >
>>> > > > > On Thu, Apr 4, 2024 at 12:45 PM Abe Ratnofsky <a...@aber.io> wrote:
>>> > > > >
>>> > > > > CEP-8 proposes using separate Jira projects per Cassandra 
>>> > > > > sub-project:
>>> > > > >
>>> > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-8%3A+DataStax+Drivers+Donation
>>> > > > >
>>> > > > > > We suggest distinct Jira projects, one per driver, all to be 
>>> > > > > > created.
>>> > > > >
>>> > > > > I don't see any discussion changing that from the [DISCUSS] or vote
>>> > > > > threads:
>>> > > > > https://lists.apache.org/thread/01pljcncyjyo467l5orh8nf9okrh7oxm
>>> > > > > https://lists.apache.org/thread/opt630do09phh7hlt28odztxdv6g58dp
>>> > > > > https://lists.apache.org/thread/crolkrhd4y6tt3k4hsy204xomshlcp4p
>>> > > > >
>>> > > > > But looks like upon acceptance that was changed:
>>> > > > > https://lists.apache.org/thread/dhov01s8dvvh3882oxhkmmfv4tqdd68o
>>> > > > >
>>> > > > > > New issues will be tracked under the CASSANDRA project on 
>>> > > > > > Apache’s JIRA <
>>> > > > > https://issues.apache.org/jira/projects/CASSANDRA> under the 
>>> > > > > component
>>> > > > > ‘Client/java-driver’.
>>> > > > >
>>> > > > > I'm in favor of using the same Jira as Cassandra proper. 
>>> > > > > Committership is
>>> > > > > project-wide, so having a standardized process (same ticket flow, 
>>> > > > > review
>>> > > > > rules, labels, etc. is beneficial). But multiple votes happened 
>>> > > > > based on
>>> > > > > the content of the CEP, so we should stick to what was voted on and 
>>> > > > > move to
>>> > > > > a separate Jira.
>>> > > > >
>>> > > > > --
>>> > > > > Abe
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > >
>>
>>

Reply via email to