lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <gus.h...@gmail.com>
Subject Re: Commit / Code Review Policy
Date Mon, 02 Dec 2019 16:58:55 GMT
Some thoughts from reading the doc and this thread


   1. This doesn't sound like a huge change, mostly a change in tone since
   nearly everything in it is a judgement call.
   2. I agree that the word policy seems iffy. It has a "consequences for
   violation" tone to it, and without some sort of "what happens if you break
   it" it's really just a recommendation anyway. Maybe call it "Commit Process
   Recommendations"
   3. It would be nice if JIRA had a (*optional!*) PATCH_REVIEW status
   (down stream from PATCH_AVAILABLE and it's infrastructure, but not
   requiring PATCH_AVAILABLE as a prior step) that could be hooked up to send
   a mail with an easily filterable subject line to individuals that have
   (somehow) nominated themselves as interested in the associated Jira
   Component
   4. If we add the status, we should formalize the expected time period
   that reviewers will have to respond, even if it's just with "I want to
   review this but I can't get to it till Thursday..." (I'm thinking 1 week).
   This timeline would only apply to issues that use this status, timelines
   for small stuff, or major changes etc as per the recommendations... This is
   just an idea to help folks who want a review to connect with and get the
   attention of folks who care particularly deeply about a feature area.


On Mon, Dec 2, 2019 at 6:00 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> > For example, I opened some patches to improve solr's security because
> its currently an RCE-fest. I'm gonna wait a couple days, if nobody says
> anything about these patches I opened for Solr, I'm gonna fucking commit
> them: someone needs to address this stuff. Why should I wait weeks/months
> for some explicit review? There is repeated RCE happening, how the hell
> could I make anything worse?
>
> +1 Robert, totally agree. RCE etc should be absolutely top priority.
> Thanks a ton for tackling this. Breaking functionality (not deliberately of
> course) is better than having RCEs in a release. IOW, it can't get worse.
>
> On Mon, 2 Dec, 2019, 3:03 PM Robert Muir, <rcmuir@gmail.com> wrote:
>
>>
>>
>> On Mon, Dec 2, 2019 at 3:49 AM Jan H√łydahl <jan.asf@cominvent.com> wrote:
>>
>>> I think the distanse is not necessarily as large as it seems. Nobody
>>> wants to get rid of lazy consensus, but rather put down in writing when we
>>> recommend to wait for explicit review.
>>>
>>
>> Then change the document's name to be Recommendation instead of Policy!
>>
>

-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Mime
View raw message