> On May 30, 2019, at 11:39 PM, Hynek Schlawack <h...@ox.cx> wrote:
>
>> If you love NNTP, and would like to help this package stick around by
>> maintaining it, that would be great! However, please note that at this
>> point it's not worth discussing unless you have the actual free time to
>> dedicate to doing the py3 port, cleaning up the test coverage, and generally
>> keeping it updated and maintained going forward. Any PR wanting to
>> un-deprecate it is also going to have to get it working on py3 :-).
>
> I don’t think this is necessarily the narrative that ought to be had in 2019.
>
> I’d push for: if you love NNTP and want it to stick around, do all the work,
> put it on PyPI, and if it’s good, we’ll move it into the Twisted orga on
> GitHub. NNTP support looks quite independent to me and at this point we
> can/should apply Amber’s core summit talk to Twisted’s batteries just as
> well..
This is a nice hypothetical, since I very much doubt that anyone cares enough
to resurrect NNTP, so it's nice to discuss without the possibility that reality
will rear its ugly head ;-).
In principle I agree with you. The major practical issue that gets in the way
here, if we were to, say, try to do this with twisted.mail, twisted.conch, and
twisted.positioning tomorrow (and that makes the existing somewhat large matrix
of ancillary projects under the Twisted org somewhat of a maintenance
nightmare) is the non-replicability of our various CI setups.
I do ~nothing (other than code reviews) to maintain Twisted these days except
for shuffle YAML files back and forth between Appveyor and Travis and Circle
and Azure and Codecov and Read The Docs and Coveralls and frankly I'm a bit
sick of it. Already, Klein, Treq, and the Divmod universe lag/diverge
somewhat; Ldaptor is completely separately maintained. The idea of manually
redoing this work across a massively exploded matrix of subprojects makes me
dizzy.
That said this problem is far from intractable. Computers are great at
automating things, especially other computers. One thing that occurs to me is
that if we maintained a repository containing a cookiecutter template that
could be re-run to regenerate the best-practice CI configuration for each
project from some minimal configuration ("what python versions do you support",
"do you have C modules", "what operating systems do you care about testing
on"), rather than editing the CI configuration directly, we could possibly make
cross-cutting CI changes there, and then re-apply it to all relevant projects.
This will only become more critical as we do stuff like auto-release to PyPI,
uploading wheels from CI artifacts. Which we're doing, like, any day now,
right? :)
And, hey, Hynek, you're an expert on how open source projects should be set up,
right? Didn't you give a talk about it recently? Maybe you could make that
repeatable? ;-)
If spinning up a new project were as simple as "run this script to create a
repo already hooked up to all the maximally-awesome Twisted-level continuous
integration goodness", I'd feel much better about our already-planned
(deferred, filepath) and possible future (basically all protocols but HTTP and
AMP probably) split-out projects.
Finally of course we need that bot that we keep talking about which allows
external contributors to re-request reviews so we can build
https://twistedmatrix.com/highscores/ <https://twistedmatrix.com/highscores/>
and https://twisted.reviews/ <https://twisted.reviews/> on Github, so that
other projects can have a unified view across the whole Twisted org ;-).
> Cheers,
> —h
>
> P.S. Please don’t storm out of the room. ;)
Heaven forfend.
-g
_______________________________________________
Twisted-Python mailing list
Twisted-Python@twistedmatrix.com
https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
