Typo , wrong link: (2) requiring full code-modification vote as per [Iceberg improvement proposal](#apache-iceberg-improvement-proposals) => full code-modification vote as per [code modification]( https://www.apache.org/foundation/voting.html#votes-on-code-modification)
On Mon, Jul 29, 2024 at 1:53 PM Szehon Ho <szehon.apa...@gmail.com> wrote: > Hi, > > Also if I read it correctly, I think this proposal imposes the following > workflows in "spec" folders : > > 1. Large and functional changes. These redirect to Iceberg > improvement proposals, which ends in code-modification vote > 2. bug-fixes or clarification, which is specified to require > code-modification vote > 3. grammar, spelling, minor formatting fix, not covered here (I guess > it is like any normal code review?) > > To me, (2) is a bit new here and in the grey area for interpretation. I > was thinking about this while reviewing > https://github.com/apache/iceberg/pull/10793, which could be a category > (2) and non-functional change but would need a full code-modification vote > as per [Iceberg improvement > proposal](#apache-iceberg-improvement-proposals). I can see both sides, to > avoid a potential dispute/misunderstanding over the clarification, it would > be nice to have a vote on the devlist. But it may also be yet another > burden, when something can be more easily decided on the github discussion > itself via approval by the relevant parties. So I think I would agree with > Ryan in mentioning that significant (would maybe add "functional") spec > change needs a vote on the dev list. > > Thanks > Szehon > > On Mon, Jul 29, 2024 at 1:16 PM Ryan Blue <b...@databricks.com.invalid> > wrote: > >> I think the proposed doc looks good, but I'm not sure that it is better >> to add this to our guidelines. >> >> On one hand the doc describes how ASF communities work in general: >> committers review and commit PRs and are expected to use good judgement, >> ask one another for help when necessary, and broaden the set of people in >> the discussion when there's a disagreement. I really appreciate that Micah >> called out that this is intentionally vague to emphasize committer >> judgement. >> >> The problem I'm worried about is the tendency to misuse docs like this >> and become focused on it as a rule. People tend to apply written rules >> mechanically and I worry about people substituting a reading of this text >> for judgement. For example, a strict reading of "encouraged to ask another >> committer" means that it is optional. >> >> Given that the majority of the content here is stating how ASF >> communities work and the only Iceberg-specific parts are the proposal >> process and calling out that we vote on spec changes, I would probably just >> have a description of how to handle proposals (which is already there) and >> a note that significant spec changes should use a vote on the dev list. >> >> On Sun, Jul 28, 2024 at 11:15 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> Hi Micah >>> >>> Thanks ! It looks good to me now you have included comments from >>> everyone. >>> >>> Regards >>> JB >>> >>> On Fri, Jul 26, 2024 at 1:15 AM Micah Kornfield <emkornfi...@gmail.com> >>> wrote: >>> > >>> > As part of the bylaws discussions that have been happening, we are >>> trying to make small focused proposals to move things forward. As a first >>> step towards this I created a proposal for guidelines on committing pull >>> requests [1]. Feedback is appreciated. >>> > >>> > Given the level of interest in the discussions so far, it seems that >>> the best path forward is to hold an official vote before merging. I intend >>> to do this once we appear to have consensus but if the people prefer we can >>> try to avoid the overhead. >>> > >>> > Thanks, >>> > Micah >>> > >>> > >>> > [1] https://github.com/apache/iceberg/pull/10780 >>> >> >> >> -- >> Ryan Blue >> Databricks >> >
