I'll add the both of you, and anyone else that speaks up.
To clarify, being a moderator to the mailing list is only about
accepting/rejecting posts being sent from recipients that have not (yet)
subscribed.
This is usually 95% spam and 5% existing users posting from a
different account.
On Fri,
I am also happy to be a moderator. Melissa and I together can ensure we have a solid level of coverage. On Jan 20, 2023, at 11:03 AM, Melissa Logan wrote:I appreciate the open and more structured approach to publicity & marketing so everyone can provide input and for transparency.I'm also happy
I appreciate the open and more structured approach to publicity & marketing
so everyone can provide input and for transparency.
I'm also happy to be a moderator.
On Fri, Jan 20, 2023 at 7:01 AM Patrick McFadin wrote:
> I would be happy to be one of the moderators. Not sure if that's singular
More eyes are of course always welcome.
That said, there haven’t been many volunteers so far, despite its development
going on for many months now, in the open, in official ASF repos. I suspect
mainly because it’s pretty hard and not exactly very fun (speaking from
experience).
> If it
What Benedict says is that the commits into cassandra/cep-15-accord and
> cassandra-accord/trunk branch have all been vetted by at least two
> committers already. Each authored by a Cassandra committer and then
> reviewed by a Cassandra committer. That *is* our bar for merging into
> Cassandra
I might be completely off, but I think what others are referring to here is
that 2 committers is the minimum bar, and for any commit there could be
other contributors wishing to review some part or even in full what is
being merged, and we would always allow for that, within reasonable time
What Benedict says is that the commits into cassandra/cep-15-accord and
cassandra-accord/trunk branch have all been vetted by at least two committers
already. Each authored by a Cassandra committer and then reviewed by a
Cassandra committer. That *is* our bar for merging into Cassandra trunk.
I would be happy to be one of the moderators. Not sure if that's singular
or plural. :D Just need to know how to do it.
Patrick
On Fri, Jan 20, 2023 at 1:44 AM Mick Semb Wever wrote:
> *To achieve this, we are proposing the formation of a Publicity &
>> Marketing Working Group, and we are
These tickets have all met the standard integration requirements, so I’m
> just unclear what “higher pre-commit gateway” you are referring to.
>
A merge into trunk deserves extra eyeballs than a merge into a feature
branch.
We can refer to this as a "higher pre-commit gateway" or a "second
> Both a git post-checkout and a build fail-fast will protect us here. But
>>> the post-checkout will need to fail silently if the .git subdirectory
>>> doesn't exist.
>>>
>>
>> Correction: the build fail-fast will need to fail silently if the .git
>> subdirectory doesn't exist.
>>
>
> How will
On Fri, Jan 20, 2023, 8:31 AM Mick Semb Wever wrote:
> Both a git post-checkout and a build fail-fast will protect us here. But
>> the post-checkout will need to fail silently if the .git subdirectory
>> doesn't exist.
>>
>
>
> Correction: the build fail-fast will need to fail silently if the
>
> Both a git post-checkout and a build fail-fast will protect us here. But
> the post-checkout will need to fail silently if the .git subdirectory
> doesn't exist.
>
Correction: the build fail-fast will need to fail silently if the .git
subdirectory doesn't exist.
Thanks Mick and David. I've been following this silently for a few days
because we already exhausted my knowledge on the topic. But it seems your
collective knowledge is uncovering a nice solution.
If I summarize, I like all of this:
- link to SHA, not library version
- use git submodules
These tickets have all met the standard integration requirements, so I’m just unclear what “higher pre-commit gateway” you are referring to.I think the existing epics are probably more natural tickets to reference in the merge, eg 17091 and 17092.On 20 Jan 2023, at 11:04, Mick Semb Wever
replies are inline to your inline replies to my inline replies 論
> We can ask INFRA to set up a separate snapshots repository just for us,
> with a longer expiry policy. I'd rather not create extra work for infra if
> there's other ways we can do this, and this approach would always require
>
On Tue, 17 Jan 2023 at 10:29, Benedict wrote:
> but the pre-commit gateway here is higher than the previous tickets being
> worked on
>
> Which tickets, and why?
>
All tickets resolved in the feature branch to which you are now bringing
from feature branch into trunk.
A quick scan I see…
>
> *To achieve this, we are proposing the formation of a Publicity &
> Marketing Working Group, and we are requesting your participation.*
>
+1 to the proposal and everything you write Patrick!
I've submitted the request for the ML (can take 24 hours). Who would like
to be a moderator for the
17 matches
Mail list logo
