> I would love to have a "problems statement" as
introduction: what problems we see concretely (and with facts to prove
that), what are the proposals in the bylaws to fix that.
Thanks JB for bringing this up.
+1 to collect all the problems from the community first by openly
discussing it (without
I meant precision (not prevision) :)
Typo mistake :)
Regards
JB
Le mar. 25 juin 2024 à 07:53, Jean-Baptiste Onofré a
écrit :
> Hi,
>
> Just a couple of comments and prevision from ASF standpoint:
>
> 1. Generally speaking, I like this bylaws proposal, and I don't see a
> problem to state again
Hi,
Just a couple of comments and prevision from ASF standpoint:
1. Generally speaking, I like this bylaws proposal, and I don't see a
problem to state again what is defined at ASF level (I'm thinking
about vote which is described here
https://www.apache.org/foundation/voting. As reminder, it's n
HI,
> This was in response to the discussion on emeritus, looks like Jack already
> took this into account in the latest proposal, so it is ok with me. I'm
> still for tracking emeritus status, as in the long run more PMC's naturally
> become inactive and it is harder to pass a majority vote.
Hi
Also copying my previous response in private.
Hi
> Thanks Jack for taking the time for this doc. While the Iceberg community
> and PMC so far has been one of the most collaborative, and I have
> personally the utmost respect for those that laid the groundwork without
> which we would not be h
Hey everyone,
Thanks Jack for setting this up, and everyone for their feedback so far.
Sharing my exact response from the private@:
Hey Jack,
>
> Thanks for raising this, and favor of having a bylaws where we can
> formally adopt ways of working that are specific to the Iceberg project.
> For exa
I don't have strong opinions either way here, just thought it was worth
raising some concerns over possible evolution here. Some responses inline,
but if capabilities seem to meet the requirement at hand, then it does
potentially seem the simplest mechanism.
I think we also want to avoid relyanc
Hey Micah,
I think what we're trying to achieve is strike a balance between client
complexity and ability to support multiple server-side capabilities. One
challenge we've run into is if a client performs an operation (e.g.
listViews), but receives a 403 code, it's not clear whether the client
do
Here is my original email from the thread on the private list. It echoes
Carl's suggestion in point 5, that we should focus on adopting bylaws that
solve challenges that we are facing in this community, rather than adopting
bylaws en masse or from another community with different concerns.
Origina
+ private for PMC members who may not follow dev
1/ I encourage the folks who have already responded on the private@ thread
to replay their comments here. As I noted earlier, this discussion falls
outside the categories that belong on the private list.
2/ I think adopting a set of clearly articul
Thanks for pointing to the ASF guidelines Carl, I did not know that. I had
the impression of engaging with the private list first due to responses in
previous devlist discussions, but I guess I landed in the right place
eventually :)
> In light of the recent change of company for a few committers
The motivation for bylaws was this: "In light of the recent change of
company for a few committers and PMC members".
That means that we're talking about new rules based on what a few specific
people might do. Speculation like that belongs on a private list, just like
discussing actual behavior wou
Hi Ryan and Jack,
The ASF's PMC Guide [1] is pretty clear on what belongs on the private list:
- pre-disclosure security problems
- pre-agreement discussions with third parties that require
confidentiality
- nominees for project committer, PMC or Foundation membership
- personal c
> The reason for that is that there's a long-standing norm to discuss the
conduct of individuals only on private lists. In this case, I think it
applies even though it is discussing hypothetical conduct. And note that
I'm one of the individuals here.
Respectfully, what does this mean, Ryan? No ind
Sorry for the confusion Ryan, this is not mistakenly sent to devlist. As we
discussed, this is the thread for collecting community feedback, which is
essential for forming bylaws with the community.
We have that separated discussion thread in the private list, which we will
continue to iterate, an
Hey everyone, I think Jack mistakenly sent this to the dev list so please
let's pause discussion for now.
There's a thread on the private list about this in which PMC members,
including me, have asked to keep it on the private list right now.
The reason for that is that there's a long-standing no
Yes I also agree there is the issue of accumulated proposals and PRs. And I
think we should discuss it as a part of the bylaw, since the voting process
matters a lot regarding the velocity.
For the PR part, my approach in the bylaws is to make sure code
modification is a lazy consensus of a commit
Thanks Piotr. I agree with both points. I added a doc comment to clarify
both the description and name for this property. Hopefully, we're all in
sync now:
https://docs.google.com/document/d/1UnhldHhe3Grz8JBngwXPA6ZZord1xMedY5ukEhZYF-A/edit?disco=AAABFwRPGoA
On Mon, Jun 24, 2024 at 4:58 AM P
Thanks Jack for raising this, this is quite important to keep healthy of
this community.
I agree with Ajantha about the concerns of accumulated proposals and prs,
and maybe we should have another thread to discuss about it?
On Mon, Jun 24, 2024 at 20:37 Robert Stupp wrote:
> Thanks Jack for the
Thanks Jack for the proposal.
I’m generally +1 on this. There are a few details to clarify, but I suspect
nothing that’s controversial.
> On 24. Jun 2024, at 12:45, Ajantha Bhat wrote:
>
> Thank you, Jack, for your diligent work on this.
>
> This seems essential at the moment.
>
> I would lik
Hi,
For the MV to be useful, the grace period (max staleness) should be part of
materialized view definition.
Ultimately it's the query engine responsibility to implement grace period
behavior correctly, but the engine needs to know what amount of staleness
is OK for this particular view and that's
Hi everyone,
We've only received one review so far (from Benny).
We would appreciate more eyes on this.
- Ajantha
On Tue, Jun 4, 2024 at 7:25 AM Ajantha Bhat wrote:
> Hi All,
> Please find the proposal link
> https://github.com/apache/iceberg/issues/10432
>
> Google doc link is attached in th
Thank you, Jack, for your diligent work on this.
This seems essential at the moment.
I would like to address a couple of additional points that need our
attention:
*Criteria for Committership/PMC:*We've observed an inconsistency in how
committership is granted. Contributors to sub-projects ofte
Hi everyone,
In light of the recent change of company for a few committers and PMC
members, I hear an increasing ask from the community to define proper
processes in Iceberg to ensure its vendor neutral stance.
I propose that we put up a bylaws document like other projects such as
Apache Hadoop a
We had a separate discussion with Dan on the *oauth2* flag last week and
came to the same conclusion that removing the *oauth2* capability is
probably the best for now.
This is mainly because we can't really act on the *oauth2* capability right
now, because the */tokens* endpoint is called before w
25 matches
Mail list logo
