Re: [Twisted-Python] towncrier review policies and etiquette (and maybe releases too)
I'd love to update these policy documents to have something explicitly org-wide, but until somebody has the time to go through and do that properly, this is generally a good assumption to have. > On Oct 21, 2020, at 1:59 PM, Tom Most wrote: > > I think that it's fine to fall back to the twisted/twisted policies[1] for > any project in the Twisted GitHub organization. The workflow won't apply > directly --- no Trac, etc. --- but the core "someone must review all changes" > and "test all the things" principles are relevant. That's how I treat Treq. > > ---Tom > > [1]: https://twistedmatrix.com/trac/wiki/ContributingToTwistedLabs > > On Wed, Oct 21, 2020, at 12:11 PM, Kyle Altendorf wrote: >> Where does towncrier stand on review policies and etiquette? I >> generally don't like to just jump into new projects and start reviewing >> and merging but I don't see other activity on that front nor do I see >> any guidance on how it should be done. If I know how to proceed >> properly then I might dedicate some review time to it. >> >> Cheers, >> -kyle > > ___ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] towncrier review policies and etiquette (and maybe releases too)
I think that it's fine to fall back to the twisted/twisted policies[1] for any project in the Twisted GitHub organization. The workflow won't apply directly --- no Trac, etc. --- but the core "someone must review all changes" and "test all the things" principles are relevant. That's how I treat Treq. ---Tom [1]: https://twistedmatrix.com/trac/wiki/ContributingToTwistedLabs On Wed, Oct 21, 2020, at 12:11 PM, Kyle Altendorf wrote: > Where does towncrier stand on review policies and etiquette? I > generally don't like to just jump into new projects and start reviewing > and merging but I don't see other activity on that front nor do I see > any guidance on how it should be done. If I know how to proceed > properly then I might dedicate some review time to it. > > Cheers, > -kyle ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] towncrier review policies and etiquette (and maybe releases too)
Where does towncrier stand on review policies and etiquette? I generally don't like to just jump into new projects and start reviewing and merging but I don't see other activity on that front nor do I see any guidance on how it should be done. If I know how to proceed properly then I might dedicate some review time to it. Cheers, -kyle ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] revert / rework of "AMPv2" change?
On 2020-10-20 04 h 57, adi at roiban.ro (Adi Roiban) wrote: > Just my 2 cents > I think that whether this should be reverted or reworked should be between > the person raising this issue (Glyph) and the author of the PR (Jonathan). Glyph has asked me to submit the type annotation work on AMP, I will do this. I also plan on resubmitting a reworked patch that addresses the issues that glyph raised. > > I see that Jonathan has responded to the feedback inside the merged PR.I > hope it can be reworked. > > Since AMP v2 is not standardized maybe is ok to have it as a separate > experimental top level name. > > I have never used AMP ...I tried to use it via ampoule but ended up using > the stdlib process pool as I was not able see any performance difference. > > Since `amp` is used by `trial -j` we need to keep it inside twisted. > > But since AMP v2 is experimental, I think that is best to have it as a > separate txamp2 project. > In this way, the twisted AMP v2 project can follow its own rules. > Once AMP v2 is "mature" it can be moved to core twisted > > So my take is to revert it and move it to twisted/txamp2. I have no issue with changing the name or if this patch lives as a project besides twisted. I might even rework it into something more forward-compatible as suggested by glyph. I think netstrings are a decent option as it would make long value handling easier since values would always be contiguous without "continuation markers" interspersed. The main thing I dislike about netstrings are the variable-length ASCII numbers, but that is not a big complexity. Could the next AMP version use values framed using 32 bit or 64 bit integers ? Transmitting long-ish values is a real use case and whatever extension we do must retain the dead-simple, easy to implement nature of the current AMP protocol. I now realise that I somewhat hijacked the "streaming values" bug (2529). IMHO, streaming should be handled at the application level, but I digress. > > > > BTW this is also my suggestion for the PR trying to introduce support for > SMB have twisted SMB implementation in a separate project. > All the best, Jonathan ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
