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 
requested.  We already had plans, as Jordan knows, to produce a wiki page for 
posterity, and a blog post closer to release.  However, I have never heard of 
this as a requirement for review, or for commit.  We have so far taken two 
members of the community through the patch over video chat, and would be more 
than happy to do the same for others.  So far nobody has had any difficulty 
getting to grips with its structure.

If the project wants to modify its normal process for putting a patch together, 
this is a whole different can of worms, and I am strongly -1.  I’m not sure 
what precedent we’re trying to set imposing arbitrary constraints pre-commit 
for work that has already met the project’s inclusion criteria.


> On 12 Apr 2019, at 18:58, Pavel Yaskevich <pove...@gmail.com> wrote:
> 
> I haven't actually looked at the code



Reply via email to