I've removed debated line from the document. As we don't have consensus on
lazy consensus it is better to start a separate discussion for this topic.
I prefer to build consensus here while procedural changes do not require it
and Majority Approval is enough.
We time to time use lazy consensus, so
Nikolay, sorry for going off-topic of the current thread. Just a few
examples:
https://issues.apache.org/jira/browse/IGNITE-8376
https://issues.apache.org/jira/browse/IGNITE-11521
https://issues.apache.org/jira/browse/IGNITE-11397
https://issues.apache.org/jira/browse/IGNITE-11346
https://issues.ap
Dmitriy.
Actually, I doesn't understand your last mail.
Do we have some issue to solve?
If yes, can you write it down?
What fixes need to be reviewed?
пн, 18 мар. 2019 г. в 16:31, Dmitriy Pavlov :
> I'm not second-guessing someone's motivation. And without a particular
> case, it is not reason
I'm not second-guessing someone's motivation. And without a particular
case, it is not reasonable to discuss reasons why a patch is not merged.
Silence=agreement in case there was clearly stated about it. Lazy consensus
is simply an announcement of 'silence gives assent.' When someone wants to
det
In case nobody cares, most likely we have a problem with a contribution or
motivation, not with lazy committers :)
Please remove the "lazy" phrase, since it can be interpreted as "silence as
an agreement" which is always not true.
On Mon, Mar 18, 2019 at 1:13 PM Dmitriy Pavlov wrote:
> Hi, thank
Hi, thank you all for your replies, I'm happy we discussing it, so we could
clearly understand this policy and how to apply it.
a committer will always merge the change, was it approved by another
contributor/committer/lazy consensus/vote - does not matter. And a
committer will be responsible to t
Hello, Vladimir.
Thanks for the detailed answer.
I think your statement doesn't differs with Dmitry statement much.
Do we have committer who merge without confidence in patch content?
If yes, they should stop to do it.
пн, 18 мар. 2019 г. в 12:00, Anton Vinogradov :
> Huge +1 to "We should stre
Huge +1 to "We should stress out that a patch should be committed if and
only if committer is confident with the changes."
On Mon, Mar 18, 2019 at 11:54 AM Vladimir Ozerov
wrote:
> Hi,
>
> This is tough question, and first of all I'd like to ask participants to
> keep cold head. This is a public
Hi,
This is tough question, and first of all I'd like to ask participants to
keep cold head. This is a public question and can be discussed on the dev
list safely.
On the one hand, it is true that a number of patches are not reviewed for a
long time, what negatively affects community development.
Dmitry,
Phrase "Code modifications can be approved by silence: by lazy consensus
(72h) after Dev.List announcement." looks unacceptable to me.
Please roll back the changes and start the discussion at the private list
and never do such updates in the future without the discussion.
On Fri, Mar 15,
Hi Igniters,
sorry for the late reply. Because this process time to time causes
questions, I decided to add a couple of words to our wiki.
I've added topics about peer review to HTC
https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-PeerReviewandLGTM
Actually, i
Dmitry,
I like your suggestion very much! And I want everyone to follow. Let's see
if it helps.
Can I ask everyone who has submitted tickets for review to add a comment
described by Dmitry to each ticket submitted and see if any additional
check is still required and fix remaining issues? I belie
Great idea!
Review is not only meant for the committers, but for everyone in the
community. Committers are only responsible for final reviews and merges.
D.
On Thu, Aug 16, 2018 at 7:29 AM, Dmitriy Pavlov
wrote:
> Hi Igniters,
>
> For a long time review queue in the community is quite long. Ti
13 matches
Mail list logo
