Hmm. Actually, did we? I’m conflating anonymous with logged-in.
> On 19 Mar 2019, at 13:43, Benedict Elliott Smith wrote:
>
> We can, but we will need to arrange another vote, since we explicitly
> discussed this and voted in favour of lifting any limitation on anonymous
> u
did not.
> On 19 Mar 2019, at 13:45, Joshua McKenzie wrote:
>
> I don't recall a vote about anonymous users having transition rights. This
> topic irritates me enough that I'm pretty sure I'd go full-on campaign mode
> against it. :)
>
> On Tue, Mar 19, 20
A couple of people have recently raised the possibility of an Author field in
JIRA, that permits multiple authors (much like we now support multiple
reviewers).
Unfortunately this can never be quite as clean as Reviewers, as Assignee is a
core Jira field and cannot be replaced entirely by Autho
st curious.
>
>
> On Mon, Apr 8, 2019 at 8:55 AM Benedict Elliott Smith
> wrote:
>
>> A couple of people have recently raised the possibility of an Author field
>> in JIRA, that permits multiple authors (much like we now support multiple
>> reviewers).
>>
>
lly compared to the
> committers that have been working on these issues for years such as
> the 15066 authors as well as Jason Brown—but like many Cassandra users
> I am familiar with many of the classes of issues Aleksey and Benedict
> have identified with this patchset (especially rela
gt;>> a hard requirement for 4.0? In my opinion no and Dinesh has done a
>> good
>>>> job
>>>>> of providing some reasons as to why so I won’t go into much detail
>>> here.
>>>> In
>>>>> short, a bug and a missing safety mechanism
+1
I’m also just as excited to see some standardised workloads and test bed. At
the moment we’re benefiting from some large contributors doing their own
proprietary performance testing, which is super valuable and something we’ve
lacked before. But I’m also keen to see some more representativ
I would once again exhort everyone making these kinds of comment to actually
read the code, and to comment on Jira. Preferably with a justification by
reference to the code for how or why it would improve the patch.
As far as a design document is concerned, it’s very unclear what is being
requ
d others have worked for).
> Everything we want to do: better testing, better review, better code, is
> made easier with better design review, better discussion, and more
> digestible patches among many of the other things suggested in this thread.
>
> Jordan
>
> On Fri, Apr 12,
t;> for after-the-fact research to determine who wrote a thing to reach out
>> to
>>> them for context? If the latter, does a change in JIRA metadata give us
>>> more context than good git commit message hygiene (i.e. list all authors
>> on
>>> commit msg)
Some exciting news from the Jira changes (maybe).
We’re done! We’ve even achieved the stretch goals.
Does anyone have any further suggestions from the new workflow, after having
tried it out for a bit? Speak up while we have the easy capability to make
changes!
- Somebody has proposed making
end, which should be your evening, could work?
>>>>>
>>>>> I can set up a Zoom conference to get everyone acquainted. We can
>>>>> record and post it for any who can't make it.
>>>>>
>>>>> I'm thinking Tuesday,
Hi Abhishek,
Sorry for the slow response.
I would assume the main reason is simply that nobody has implemented the
functionality. However, there might be some ideological opposition as well.
This query is impossible to implement as efficiently on the server as it is on
the client.
It shou
How would people feel about introducing a field for the (git) commit SHA, to be
required on (Jira) commit?
The norm is that we comment the SHA, but given this is the norm perhaps we
should codify it instead, while we have the chance? It would also make it
easier to find.
--
gt;
>> Please
>>
>> --
>> Jeff Jirsa
>>
>>
>>> On May 14, 2019, at 7:53 AM, Benedict Elliott Smith
>>> wrote:
>>>
>>> How would people feel about introducing a field for the (git) commit SHA,
>>> to be required on
>
> On Wed, May 15, 2019 at 3:39 AM Sam Tunnicliffe wrote:
>
>> +1
>>
>>> On 14 May 2019, at 20:10, Benedict Elliott Smith
>> wrote:
>>>
>>> It will be possible to insert n/a. It will simply be a text field -
>> Jira doesn’t know
d
> understood what you were saying, and then bounced down the thread; that's
> completely on me and in no way a phrasing error on your part.
>
> You are 100% correct and are supporting my (apparently multiple) bad
> habits. +1 again!
>
> On Wed, May 15, 2019 at 9:19 AM
It would be nice to have time to get CASSANDRA-14812 in, as it was also
(consciously) missed from the last release, and struggled to find a reviewer
since. Mick kindly found time to take a look while I was away. It’s a bit
rough to force affected users to wait another lengthy release cycle for
3.11.3 compiles just fine, I have just corroborated. Sir Jeff is in fact a
Cassandra developer, so please feel free to engage with his question, which was
designed to help diagnose your problem.
> On 16 Jul 2019, at 14:54, Nimbus Lin wrote:
>
> To Sir Jeff:
> your method of "ant realcl
So, I think we need to figure out if anybody is actually willing to put in the
time to help and mentor these contributors, since the last person to reach out
was roundly ignored.
Who volunteered the project for this? I think they need to step up and get
involved. Right now, I don't feel comfo
Glad to hear it - perhaps it would help if there were a bit more visibility?
Last I saw was Immanuel contacting the list almost a month ago and, well...
(seemingly) crickets.
On 23/07/2019, 21:44, "Dinesh Joshi" wrote:
Hi Benedict,
Nate & I are driving this effo
re putting. I just wish we already knew this, and
that we had been more involved.
On 23/07/2019, 21:57, "Dinesh Joshi" wrote:
Hi Benedict,
I am sorry for the lack of communication. We will send out an update soon.
Based on GSoD's guidelines, Nate created gsod2...@
Seems to make sense to branch, right?
On Thu, Aug 29, 2019 at 11:10 PM +0100, "sankalp kohli"
wrote:
Will we cut alpha1 and later alpha releases from trunk or create a new
branch?
On Friday, August 30, 2019, Nate McCall
+1
These should be sent to commits@, not dev@
On 05/09/2019, 09:19, "Stefan Miklosovic"
wrote:
Hi,
maybe I am missing here something but how can I get rid of these
emails which are polluting my inbox?
"[GitHub] [cassandra-builds] michaelsembwever commented on issue #
I think anybody can run these tests locally. It's just possible to pay to
offload them.
And when I say anybody, I don't mean me, because I always fail to get dtests to
run due to environmental problems. But I'm reliably informed that others
manage.
On 06/09/2019, 11:48, "Mick Semb Wever"
I think we need to have a meta discussion about the goal for introducing a new
process. Your email mentions two reasons that I can see:
1) Clarity of the outcome? "For example they have been written up in jira
tickets, in a way that becomes quite difficult to unpack afterwards the
difference
Can we modify the document to make this really explicit then? Right now, the
language suggests the process is mandated, rather than encouraged and
beneficial.
It would be nice to frame it as a positive and incentivised undertaking by
authors, and to list the intended advantages, as well as the
1.During ApacheCon, Laxmikant approached me to discuss CASSANDRA-14227. It
was also raised on the list back in January.
Taking a closer look, it probably is not very difficult for us to fix this –
either by treating the int as unsigned, or by widening it to a long value.
Since this can
e, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith
wrote:
> Can we modify the document to make this really explicit then? Right now,
> the language suggests the process is mandated, rather than encouraged and
> beneficial.
>
> It would be nice to frame it
Lazy consensus still requires a formal vote, just one that is declared to be
governed by lazy consensus.
I think we need to spend some time formalising our governance, so that we can
employ it confidently. At the very least, we should try to codify where we are
comfortable employing lazy conse
with what you've stated here bes: "participation in decision-making is
costly, and that proposers should understand that they need to work to
lower the cost of decision-making on their proposal, and that we as a
project need to figure out how to help them do this.&quo
Perhaps we should move the proposed document to the cwiki for purposes of
voting? That way it's in a place owned by the project, with a permanent
history. Otherwise it's not entirely clear what was voted on.
On 30/09/2019, 20:10, "Sumanth Pasupuleti"
wrote:
+1
On Mon, Sep 30,
As a brief side-step on the topic only of versioning (which no doubt will cause
enough consternation), I personally endorse streamlining it. We have not had a
consistently meaningful convention on this, at any point, and we made it even
worse in the 3.x line. There's no real difference between
>> This has definitely been a confusing topic in the past, I completely
agree
>> Benedict. Glad you brought this up.
>>
>> I'm 100% on board with 5.0 after 4.0.
>>
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith
>>
+1
On 09/10/2019, 17:50, "Oleksandr Petrov" wrote:
Hi,
During NGCC/ACNA19 we've had quite a few conversations around the 4.0
release. Many (minor) features and changes suggested during that time are
possible to implement in 4.next without any problem. However, some changes
+1
We need to do something about this, and I don't mind what. It would be better
if we cut fix releases immediately after a critical fix lands, much as we used
to. We've got fairly lazy about producing releases, perhaps because many of
the full-time contributors now work for organisations tha
+1
On 25/10/2019, 13:58, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:31 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 3.0.19.
> >
>
+1
On 25/10/2019, 13:59, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:25 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 2.2.15.
> >
>
+1
On 01/11/2019, 12:33, "Mick Semb Wever" wrote:
Please vote on accepting the Cassandra Enhancement Proposal (CEP) document
as a starting point and guide towards improving collaboration on, and success
of, new features and significant improvements. In combination with the recently
accep
I personally welcome your increased participation in any role, and more focus
on project delivery is certainly a great thing. But developer time from your
employer would probably be more impactful, as the main active contributors
right now have their own project management infrastructure, and a
they are and add what value I can
and work with the project to help keep momentum high and remove blockers or
stalls from people's workflows.
Does the above make sense?
On Fri, Jan 10, 2020 at 8:30 AM Benedict Elliott Smith
wrote:
> I persona
> Isn’t this the point of project management; to avoid this issue?
Is the point of project management to avoid the problems caused by project
management? That feels like a Dilbert cartoon.
To be clear, I'm simply responding to the apparent suggestion that we assign
every 4.0 ticket to somebod
Yes, I also miss those fortnightly (or monthly) summaries that Jeff used to
do. They were very useful "glue" in the community. I imagine they'd also make
writing the board report easier.
+1, those were great
-
To uns
ge.
Patrick
On Fri, Jan 10, 2020 at 3:21 PM Jeff Jirsa wrote:
> On Fri, Jan 10, 2020 at 3:19 PM Jeff Jirsa wrote:
>
> >
> >
> > On Fri, Jan 10, 2020 at 2:35 PM Benedict Elliott Smith <
> > bened...@apache.org> wro
s allowed
to use his time to try and get some people together to discuss contributing?
-Jeremiah Jordan
Person with no formal role in the Apache Cassandra project.
> On Jan 10, 2020, at 7:44 PM, Benedict Elliott Smith
wrote:
>
> This is also great. But i
ting to the dev list.
Hugs and kisses friends,
- Jeff
> On Jan 10, 2020, at 6:05 PM, Benedict Elliott Smith
wrote:
>
> To be clear, as it seems like I'm being very negative here, I'm really
pleased to see DataStax suddenly increase their
thread.
https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith
wrote:
> I recall this being discussed at ApacheCon, and I recall the ide
nyone can propose an alternate time. How is it private ?
What else do you suggest ?
> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith
wrote:
>
> I think everyone is missing my point, and the reason for it. I am super
focused on not repeating the situati
he will do
it.
Ideas and suggestions can be interrupted as told but again that is
interpreted differently but everyone.
(We have a thread I linked so let’s move there if anyone has suggestion on
video call To keep all context in one thread)
> On Jan 11, 2020, at 10:02 AM
> I think as long as we all believe we're all good faith actors, truly believe
> we all want what's best for the project (even if we don't necessarily all
> agree on what that is all the time), and internalize that nobody wants to see
> a monoculture on the project, we'll be fine.
I realised re
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't know we've ever been totally consistent
about it across major versions though.
I think we can view 4.
t was
delivered.
On 15/01/2020, 13:34, "Benedict Elliott Smith" wrote:
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't kno
This is brought up roughly once per year. If anything, you're a bit behind
schedule
https://lists.apache.org/thread.html/0750a01682eb36374e490385d6776669ac86ebc02efa27a87b2dbf9f%40%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/c21ccedc7fbda18558997dee8f86c074514b67387858ec12
The common factor is flaky tests, not people. You get a clean run, you commit.
Turns out, a test was flaky. This reduces trust in CI, so people commit
without looking as closely at results. Gating on clean tests doesn't help, as
you run until you're clean. Rinse and repeat. Breakages accum
nt wouldn't be made in Jira, it probably shouldn't be
made.
On 24/01/2020, 08:56, "Benedict Elliott Smith" wrote:
The common factor is flaky tests, not people. You get a clean run, you
commit. Turns out, a test was flaky. This reduces trust in CI, so people
commi
PRs on clean runs won’t
> achieve anything other than dealing with folks who straight up ignore the
> spirit of the policy and knowingly commit code with test breakage that can
> be attributed to their change. I’m not aware of such committers in this
> community, however
Behaviours don't have to be switched only with a new protocol version; it's
possible to support optional feature/modifier flags, the support for which is
negotiated with a client on connection.
A protocol version change seems reasonable to limit to major releases, but a
protocol feature seems p
You could push to the repository that triggers CI less frequently? I don't
think it cares about commits, but pushes.
I think some people like to see feedback promptly, without having to go in
manually until a dtest run is needed closer to patch completion. Unfortunately
this is a situation wh
ose that work on a variety of machines over
time, this does represent a sub-optimal arrangement.
On Tue, Mar 24, 2020 at 4:38 PM Benedict Elliott Smith
wrote:
> You could push to the repository that triggers CI less frequently? I
> don't thi
I would personally prefer we simply bump tickets from the milestone
periodically. The point of a milestone is to collect tickets we expect to land
there, and since we want to release ASAP we should have at most a handful of
optional items there sponsored by some community members, so the burden
Sorry if this is a repeat message; I messed up my mail client settings (I don't
see it today, but it might just be stuck in an unmonitored moderator queue):
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella, surely?
I
There it is. I knew it would show up eventually.
On 04/04/2020, 06:26, "bened...@apache.org" wrote:
> scope creep.
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella.
I don't personally mind if
+1
On 08/04/2020, 16:53, "Mick Semb Wever" wrote:
Can we agree on keeping such test changes out of CHANGES.txt ?
We already don't put entries into CHANGES.txt if it is not a change
from any previous release.
There was some discussion before¹ about this, and the problem
> become much easier to agree on which tickets we put in 4.0.
>
>
>
>
>
>
>
>
> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith >
> wrote:
>
> > There it is. I knew it would show up eventually.
This is a silly pet peeve. In this context it was unambiguous what was meant,
and to snipe at people who do not have English as their first language in such
an irrelevant context is a waste of everyone's time and energy.
Please update your approach to the community.
On 16/04/2020, 10:35, "Gr
guous, only
that it was not perfectly crafted.
On 16/04/2020, 14:24, "Christopher" wrote:
Benedict,
Please consider the possibility that Greg was offering constructive
criticism. He used polite wording, such as "Please", and clearly
explained why the mi
+1. This might also serve to produce specific points of discussion around the
topic as the CEP progresses.
Maybe put it high up the list, e.g. after Description of Approach?
On 22/04/2020, 17:40, "Joshua McKenzie" wrote:
Link to CEP guide:
https://cwiki.apache.org/confluence/pages/
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?
On 22/0
above.
On 22/04/2020, 21:25, "Nate McCall" wrote:
On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith
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 won
0, 10:51, "Sylvain Lebresne" 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 th
I vote to nuke it post-4.0, when we have time to put together a working group
to discuss its replacement.
On 30/04/2020, 19:21, "Mick Semb Wever" wrote:
The C* codebase contains the cassandra-stress tool that is seeing less
maintenance and is getting replaced in popularity by other too
I think our "pre-beta" criteria should also be our "not in a major" criteria.
If work is prohibited because it invalidates our pre-release verification, then
it should not land until we next perform pre-release verification, which only
currently happens once per major.
This could mean either l
d important places but the important thing is
> to see how exactly it touches, I think
> - Considering it for alpha before the major testing in beta sounds
> reasonable to me but I guess it also depends on people availability to
> review it in detail and the exact
ow]" because it
invalidates "4.0 Verification Work" must also be prohibited until "5.0 Dev"
because the next equivalent work that can now validate it occurs only at "5.0
Verification Work"
On 27/05/2020, 19:05, "Benedict Elliott Smith" wrote:
I
> It seems all rules on voting are predicated on the question being binary
ASF votes are meant to be - as far as possible - a formality confirming
consensus, or something to resolve irreconcilable disagreements. The
discussion section describes how to build consensus when there are multiple
o
q9IbiFFC3d3efJSj9OIrGcqQ8/edit#
>> >
>> > The doc is only 2 pages long; if you're interested in engaging in a
>> > discussion about how we evolve and collaborate as a project, please
take
>> > some time to read through the doc, think thro
OIrGcqQ8/edit#
> >
> > The doc is only 2 pages long; if you're interested in engaging in a
> > discussion about how we evolve and collaborate as a project, please take
> > some time to read through the doc, think through things, and engage on
> thi
rote:
Oh, interesting. I checked the doc and didn't see a time frame on the roll
call but maybe I just missed it.
I'll open it up for comments either way.
On Thu, Jun 4, 2020 at 5:51 PM Benedict Elliott Smith
wrote:
> I think the 24 hours point that was raised was
So, if it helps matters: I am explicitly -1 the prior version of this work due
to the technical concerns expressed here and on the ticket. So we either need
to revert that patch or incorporate 15299.
On 16/06/2020, 21:48, "Mick Semb Wever" wrote:
>
> 2) Alternatively, it's been 3 yea
+1
On 16/06/2020, 22:23, "Nate McCall" wrote:
+1 (binding)
On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie
wrote:
> Added unratified draft to the wiki here:
>
>
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I pr
tc (is any of this documented, I couldn’t find
any last time I was talking to others about this).
Now, lets say we close alpha and cut a beta release, my understanding is
that tickets which block the next beta release are alpha…. So do we still mark
them alpha (even though we won’t h
ts surfaced by a diverse
collection of users and I'd like to see us move in that direction again for
the long-term health of the project. Hence my attempts to move us towards
beta and take on an awareness campaign and call to action for the community
to engage in testing.)
O
Sorry, I've been busy so not paid as close attention as I would like after
initial contributions to the formulation. On the document I raised this as an
issue, and proposed lowering the "low watermark" to a simple majority of the
electorate - since if you have both a simple majority of the "act
ou're concerned about, or just musing over?
On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith
wrote:
> Sorry, I've been busy so not paid as close attention as I would like after
> initial contributions to the formulation. On the document I raised this
as
&g
> >
> > Yeah, I didn't think you were serious about it being a problem, just
> wanted
> > to check.
> >
> > I'm changing my vote to a -1, in favor of a simple majority as the low
> > watermark in vote participation (not appr
ut just my 2c.
On 17/06/2020, 21:58, "Jon Haddad" wrote:
For what it's worth, I thought Benedict's suggestion was a pretty
reasonable one and am in favor of it.
On Wed, Jun 17, 2020 at 1:40 PM Joshua McKenzie
wrote:
> Race condition on that last one
thing that would be a non-issue assuming positive intent and
> > alignment
> > > between response to roll call and participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai wrote:
> > >
> > >> +1 nb
> > &g
but not so much that I think we'll end up backed into
a corner. I didn't do a good job of explaining that though.
Might be useful to take a roll call now just to get a feel for what we're
voting for.
On Thu, Jun 18, 2020 at 11:21 AM Benedict Elliott Smith
wr
ation.
> > > > >
> > > > >
> > > > >- Vote will run through 6/24/20
> > > > >- pmc votes considered binding
> > > > >- simple majority of binding participants passes the vote
> > > >
Also, +1
On 22/06/2020, 11:23, "Benedict Elliott Smith" wrote:
If you read the clauses literally there's no conflict - not all committers
that +1 the change need to review the work. It just means that two committers
have indicated they are comfortable with the patch bei
The purpose of this document is to define only how the project makes decisions,
and it lists "tenets" of conduct only as a preamble for interpreting the rules
on decision-making. The authors' intent was to lean on this to minimise the
rigidity and prescriptiveness in the formulation of the rule
--> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0
This. This is all that matters IMO. Some have been saying 4.0.0 is very
delayed, and that this harms the project - and they're right. So I'm surprised
to see those same voices advocating we prioritise th
Ok, I'm sorry for reaching the opposite conclusion before reading this email -
the implication here instead appears to be that, you believe, people are
advocating to integrate work that should be deferred - is that correct?
Perhaps we should have a direct conversation about the tickets you cons
> Nothing is stopping us for discussing CEPs now, and nothing prevents folks
> from making their own feature branches.
I disagree. CEPs are just as - if not more - of a distraction than branching.
Work doesn't happen in a vacuum. Those who are today focusing what resources
they can on shippin
ests, or you pay money to be able to
run the tests... If the intent is to make it easier for new people to
contribute to the project, shouldn't the focus be on fixing their pain
points such as testing?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West wrote:
> On Fri, Jun 26
ew contributions from the same quarters
>
Just a heads up - this comes across as passive aggressive sniping. I'm sure
you didn't mean it as such but it does read that way (at least to me).
When it comes to quality, much like you said in another thread Benedict I
thin
On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith
wrote:
> > Just a heads up - this comes across as passive aggressive sniping. I'm
> sure you didn't mean it as such
>
> I think indirect criticism is a normal part of discourse, particula
need both new features/improvements and stability.
It is natural that some people push a bit more towards new
features\improvements and others towards stability.
I would be worried if everybody wanted to go in the same direction.
On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smi
o be addressed.
On 29/06/2020, 15:33, "Benjamin Lerer" wrote:
Sorry, Benedict. My answer was probably not phrased in the correct way.
I just believe that we should not look at the organizations behind the
persons participating in the project. I am not my organization
I think, just as importantly, we also need to grapple with what went wrong when
features landed this way, since these were not isolated occurrences -
suggesting structural issues were at play.
I'm not sure if a retrospective is viable with this organisational structure,
but we can perhaps engag
401 - 500 of 747 matches
Mail list logo
