Re: [Twisted-Python] automatic subscription should be working again
Hey Glpyh, Am 30/03/2017 um 10:14 schrieb Glyph Lefkowitz: > This is probably a bigger deal to me than anyone else, since making sure > our abysmal mail infrastructure didn't fall over and stop delivering > messages to project members or DDoS some poor soul on the other side of > the planet has been a grindingly tedious intermittent task for me over > the last year. Processing new subscription requests, and trying to > disambiguate them from spammers, has been particularly time-consuming > and frustrating; I suspect that a few dozen people who would really > prefer to be on this list now have bounced off of the byzantine > subscription process in the last six months. > > Thank you all for your patience, and I _really_ hope that this is my > last posting about meta-level mailing list junk this year :-). I'm glad to read this, hopefully I was one of your last manual approvals and you'll have one thing less to think about ^^. Best wishes, -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] ask not
Bug is fixed by someone - PR is made - Comments are made - Comments are discussed / implemented - Stuff works - PR remains open without further comments. - External contributor forgets about Twisted and moves on or waits indefinitely, while they could be fixing more stuff. This could be because of a lack of active core-developers, which leads me to: 10. "Project Governance", which has already been indirectly raised by Glyph this week when presenting Tom Most (welcome, and thanks!). Who works on twisted? When? Are they active? Partially active? What do they do? What needs to be worked on? How does Twisted as an organisation work? All of these are questions that don't seem too important when it comes to code, but they extremely relevant when it comes to the project and when it comes to users deciding Twisted over other options. I explain further: if person A at company X uses Twisted and they have the feeling, that Core-Developers are overwhelmed, person A could put pressure in company X to get some of their time going to helping out in Twisted. But if they don't know this, they can't. And if they knew this, how would they? Notice that I said "uses Twisted", Twisted is quite mature and it is very possible to use it for a long time without hitting bugs. That's why the health of the project (as opposed to the code) needs to be visible from the outside, to non Twisted developers (either core or external). 11. Twistedchecker: from what I've been reading in open PRs, right now it may be doing more harm than good. What's the coding standard? testAll? test_all? Twistedchecker says something, documentation says nothing. Core developer says something different. What About newlines? Same issue. This is also a key point in getting stuff done by non-core developers; if they can't trust the tools to help them produce a worthy patch, why bother? As a side question: do core-developers use twistedchecker? I would have imagined these issues would have resulted on bug tickets that do not (yet) exist. 12. Bug discussion integration between Github and Trac? Discussion about bugs is taken place on GitHub. At least about bugs someone is working on. This makes sense, since the workflow involves a PR and GH makes reviewing easier, that's where it ends being discussed. Why is this a problem? Well, anyone who is not familiar with Twisted's development will judge this from Trac: - Oldest bug is #50. Open for nearly 16 years. - There is nearly no discussion on newer bugs. - Bugs that get closed, have usually no discussion. - Therefore, users are being neglected. That's, of course, an exaggeration and over-simplification; but the point stands for outsiders. Some integration could mitigate that. That being said, I could help with some things for a few hours a week. I just... you know, can't. I guess, since I'm hijacking threads, I might as well go all-in and ask for Wiki edit permissions to begin with. PS: This email got so long, my bread was burning in the oven! Sorry about that, but I hope it is somehow beneficial. [1]: http://twistedmatrix.com/trac/wiki/DocumentationAnalysis [2]: http://twistedmatrix.com/pipermail/twisted-python/2005-May/010386.html [3]: http://twistedmatrix.com/trac/ticket/9100 [4]: https://github.com/twisted/twisted/pull/769 [5]: https://github.com/twisted/twisted/pull/740 [6]: https://github.com/twisted/twisted/pull/747 -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] 'ok to merge' label in github?
Hi Glyph, Am 03/07/2017 um 14:08 schrieb Glyph: > Unfortunately, our CI runs can be quite lengthy. When doing a quick code > review, it can often be quite demoralizing to see an hour or two worth of > appveyor backlog that needs to run before a ticket can be merged. > > I have been thinking about adding a specific "OK to merge" label to PRs that > indicates that they've been submitted to pr_as_branch, they've been reviewed, > and if the CI results or positive they should be merged, so that someone > other than the reviewer might come along and do the actual merge later. Does > anyone else think this would be a good idea? If those are GitHub labels and only modifiable by repo owners, it sounds like a sane thing to do. One thing that would worry me though, is that more commits could come to that PR after the reviewer (repo owner) sets the 'OK to merge' tag, I guess such a tag should be associated with the last commit but I'm not too sure that's possible out of the box with GitHub. > (I know that there are ways that bots can facilitate this, and if someone > else would like to set that up, that would be great.) Maybe a bot could figure out the last reviewed commit and remove the label if it detects new (not reviewed) commits in that PR. I... would actually be interested in taking a look at it, got any pointers / are there already some bots for the twisted project running? -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] 'ok to merge' label in github?
Am 03/07/2017 um 14:24 schrieb Evilham: > Hi Glyph, > > Am 03/07/2017 um 14:08 schrieb Glyph: >> Unfortunately, our CI runs can be quite lengthy. When doing a quick code >> review, it can often be quite demoralizing to see an hour or two worth of >> appveyor backlog that needs to run before a ticket can be merged. >> >> I have been thinking about adding a specific "OK to merge" label to PRs that >> indicates that they've been submitted to pr_as_branch, they've been >> reviewed, and if the CI results or positive they should be merged, so that >> someone other than the reviewer might come along and do the actual merge >> later. Does anyone else think this would be a good idea? Isn't this exactly what you want Glyph? (maybe I missed sth :-D) https://help.github.com/articles/about-required-reviews-for-pull-requests/ It could affect the workflow of people with write-access though. > If those are GitHub labels and only modifiable by repo owners, it sounds > like a sane thing to do. > > One thing that would worry me though, is that more commits could come to > that PR after the reviewer (repo owner) sets the 'OK to merge' tag, I > guess such a tag should be associated with the last commit but I'm not > too sure that's possible out of the box with GitHub. > >> (I know that there are ways that bots can facilitate this, and if someone >> else would like to set that up, that would be great.) > > Maybe a bot could figure out the last reviewed commit and remove the > label if it detects new (not reviewed) commits in that PR. > > I... would actually be interested in taking a look at it, got any > pointers / are there already some bots for the twisted project running? > -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Twisted 18.7.0rc1 Release Candidate Announcement
Am 04.07.2018 um 12:44 schrieb Amber Brown: > You can read the full changelog here: > > https://github.com/twisted/twisted/blob/release-18.7.0-9475/NEWS.rst > > Please do some testing, and if all goes well, 18.7 will release proper > in a week. Noticed a documentation issue with #9387 (see #9479) and as I was preparing a patch for it, I noticed that it implemented `samesite` as an argument which AFAIU is in violation of Twisted coding style. Just to illustrate: the same method has another parameter called `httpOnly` and one called `max_age`. Having `samesite` adds yet a third style to the same method. AFAIU, the Naming Convention suggests it should be `sameSite` instead. Opened another ticket for that (#9480). Since once this is released, it's pretty much un-changable, I would think it's release critical; "Release blocker: Regression" sounded like the most suitable tag. See Pull Request: https://github.com/twisted/twisted/pull/1036 #9479: https://twistedmatrix.com/trac/ticket/9387 https://github.com/twisted/twisted/commit/1504c345c2b3ce73b63cf8d27f353c5e9be70f4f#diff-a31693cfdecc4bc57f3dd9ce31445237R1154 #9479: https://twistedmatrix.com/trac/ticket/9479 #9480: https://twistedmatrix.com/trac/ticket/9480 -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Twistedmatrix.com: scheduled maintenance July 18th
Am 13.07.2018 um 08:35 schrieb Glyph: >> DNS could be pointed at an S3-backed website to serve a maintenance >> message, at least. Not optimal, but better than ECONNREFUSED I would >> think. I'd be happy to set this up and foot the bill - if someone >> provides the content (I can make web pages but no one really wants that). > > Please do so! > > Although keep in mind that it is the DNS primary as well, so you'll have > to update it with enough of a buffer that the secondary has cached the > address by the time it goes offline. I could also set this up on a Data Center in Switzerland; without spending a penny :). Only TLS is kind of a thing though, I'd probably generate LE certs to keep visitors happy and promise to delete those after the maintenance time-window. It'd make sense if that's kind of a no-go ^^. If it does sound like sth to do, just let me know in advance and I'll set up the thing + be available to trigger LE cert generation as soon as DNS is set up. (In that case, I noticed twistedmatrix.com doesn't have HSTS headers, so note to self: do not set those up :-D) As for content, I have a placeholder I've used in the past, which I've adapted to Twisted. Feel free to use/modify/not use at will. Preview: https://evilham.com/twisted_placeholder/ Source: https://evilham.com/twisted_placeholder.tar.gz -- Evilham --- This email is cryptographically signed and could have been encrypted. My key fingerprint: B265 7ED4 5F7A DD90 7F1D D5C7 5516 1BE6 0CE2 CB87 Learn how to encrypt your email with the Email Self Defense guide: https://emailselfdefense.fsf.org/en/ signature.asc Description: OpenPGP digital signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
[Twisted-Python] State of Names / DNS server
Dear Twisted people, I've been taking a good look at twisted.names as a sever after checking twisted-infra/braid/services/names and how the zones are saved. Basically, I wonder what the state-of-afairs of running DNS with twisted is. By checking the code I see a couple things like: * That zone transfers are enabled by default and open to any host and only subclassing would help override that (it is the case on twistedmatrix.com btw). * Comments saying how some things are not RFC-compliant, but not how. * That DNSSEC is not implemented Besides the 1st point which could be a ticket (should I open it?), the other points appear to be somewhat documented in the open tickets: https://twistedmatrix.com/trac/query?status=assigned&status=new&status=reopened&component=names&group=priority&max=200&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority But I wonder if there is something like a roadmap that I haven't seen or a very specific way to start helping on this front. Basically, I'd hate to start working on sth and it overlapping with someone else's work ;). I checked a couple tickets, and see that there is definitely a need for some cleanup, e.g. this one appears to be ready for closing https://twistedmatrix.com/trac/ticket/5048 as it is marked as duplicate of a closed ticket. Also, I recall this PR from early summer, which appears to have been OK'd but is blocked by some failure in appveyor + buildbot: https://github.com/twisted/twisted/pull/954 Thank you for any pointers, and thank you for Twisted! -- Evilham signature.asc Description: OpenPGP digital signature ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] State of Names / DNS server
Always a pleasure to read you Glyph, Am 15/10/2018 um 2:00 schrieb Glyph: >> On Oct 12, 2018, at 12:18 PM, Evilham > <mailto:cont...@evilham.com>> wrote: >> >> Dear Twisted people, >> >> I've been taking a good look at twisted.names as a sever after checking >> twisted-infra/braid/services/names and how the zones are saved. > > The way the zones are saved there is fairly primitive. It would be nice > if we had a more robust backend; in particular I'd love it if we had a > DNS API so that e.g. https://github.com/glyph/lancer could talk to > something on twistedmatrix.com <http://twistedmatrix.com> to provision > HTTPS certificates via the LE DNS-01 challenge. indeed, this is pretty much one of the main reasons why I am looking into Twisted as a my DNS server :-). Twisted DNS + Klein --> (große) Awesomeness (reading Twisted's source code, makes you prone to bad jokes, that should be an official warning somewhere) >> Basically, I wonder what the state-of-afairs of running DNS with >> twisted is. > > We run it on production on twistedmatrix.com <http://twistedmatrix.com> > and that site sees plenty of DNS traffic :-). > >> By checking the code I see a couple things like: >> * That zone transfers are enabled by default and open to any host and >> only subclassing would help override that (it is the case on >> twistedmatrix.com <http://twistedmatrix.com> btw). > > It would certainly be nice if this were controllable via a flag. As you > notice, this should be a ticket. Done, ticket #9551. (Trac always thinks I am Spam with probability 90%, wonders!) https://twistedmatrix.com/trac/ticket/9551 >> * Comments saying how some things are not RFC-compliant, but not how. > > Some investigation into these comments to make them more specific would > be good. Also documented in ticket #9552; mostly to use trac as a quick overview. https://twistedmatrix.com/trac/ticket/9552 >> * That DNSSEC is not implemented > > On the one hand, it would be great if someone would take the DNSSEC > support already in various branches and get it over the finish line. On > the other, DNSSEC is bad (see > <https://sockpuppet.org/blog/2015/01/15/against-dnssec/> for example), > and is really not necessary to run a real-life DNS server or client, so > it's a little difficult for various DNS-interested parties to get > excited about it. Nonetheless if people are going to do DNSSEC I'd > rather they do it with Twisted than BIND, so if you could help integrate > DNSSEC work that is a definite goal for the project! So I hope somebody > who disagrees with me about the utility of DNSSEC contributes to it. :-D I am also not fond of DNSSEC being *the* thing; but apparently email servers complain otherwise in certain environments. Twisted supporting DNSSEC would indeed make things easier. >> the >> other points appear to be somewhat documented in the open tickets: >> https://twistedmatrix.com/trac/query?status=assigned&status=new&status=reopened&component=names&group=priority&max=200&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=milestone&order=priority >> >> But I wonder if there is something like a roadmap that I haven't seen or >> a very specific way to start helping on this front. > > Right now the main thing we need is a motivated, interested maintainer > to advance these goals. This email sounds suspiciously like > volunteering to be that :). Ouch, I guess I'll have to invent a time-dilution bubble first :-D. I'll see what I can do about this (DNS, not time-dilution bubble). >> Basically, I'd hate to start working on sth and it overlapping with >> someone else's work ;). > > There's lots of other work in progress, but as you can see from most of > them, most of this work is stalled. I'm 100% sure that if you started > working on some of these tickets, the people whose work you might > duplicate would be /overjoyed/ that someone had done that, so I don't > think you need to worry about stepping on anyone's toes. > >> I checked a couple tickets, and see that there is definitely a need for >> some cleanup, e.g. this one appears to be ready for closing >> https://twistedmatrix.com/trac/ticket/5048 >> as it is marked as duplicate of a closed ticket. > > Please go ahead and close it if you are reasonably sure of that! I was hoping for one of the involved parties remembering and saying "oh yeah, that should be closed" otherwise it requires actual analysis, so I'll leave that for some-time-soon. >> Also, I recall this PR from early summer, which appear
Re: [Twisted-Python] Twisted 18.9.0 Release Announcement
Am 22/10/2018 um 10:33 schrieb Glyph: >> - twisted.internet._sslverify.ClientTLSOptions no longer raises IDNAError >> when given an IPv6 address as a hostname in a HTTPS URL. > This is twisted.internet.ssl.optionsForClientTLS for those of you who are not > maintaining Twisted's innards :-). > Ahà! I think I was hit by this last week while using treq and decided to pass bytes directly :-D didn't have time to research it more / make it reproducible, but this was likely it! Thanks everyone. -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] a farewell to buildbot
Am 03/03/2019 um 7:32 schrieb Glyph: > So, do folks have any strong feelings, or would anyone like to volunteer > to help with some aspect of this? As always: we don't have enough folks > to keep up with the operational demands of twistedmatrix.com > <http://twistedmatrix.com>, so if you want to dev some ops or ops some > infra, please speak up :). This together with the 1password email raises following question: Is there anything particular that needs more support? Amber's point about Buildkite's bring-your-own-builders offering sounds interesting, and if lack of Mensch-power is the only issue, maybe a call to arms in a somewhat more specific fashion would be in order? I mention because that would help with some ML readers who may think "no way I can help with that" and actually could have the expertise on specific bits that are needed. Also, listing needs could be a good exercise overall and it could be listed here: https://twistedmatrix.com/trac/wiki/Infrastructure PS: Since Amber is part of Matrix' team, I just realised the silliest thing: following Twisted's tradition of awesome/awful naming puns, Matrix' Homeserver reference implementation, synapse, is written on Twisted, and this project's website is... twistedmatrix.com (!) -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Backward incompatible fixes to backward incompatible changes
Jean-Paul Calderone writes: On Thu, Apr 25, 2019 at 12:52 PM Jean-Paul Calderone < exar...@twistedmatrix.com> wrote: Hello all, I'd like to discuss the project policy/process for dealing with incorrect backward incompatibilities that end up released. Considering the lack of interest in the topic, I'm going to suppose that there is no policy and the decision is made case-by-case. In the case I referenced, I'm going to approve the change in behavior as "compatible" by on the grounds that it restores the original behavior. What you say makes sense and, as read on one of the tickets, if there *is* a need for that situation to raise an error: `AttributeError` certainly isn't the kind of error. So that should be a totally different discussion. As for a general policy: it doesn't look like this situation happens often enough for there to be a need for one (de facto, indeed that means that it is made on a case-by-case basis). Effort in general should be to prevent the situation from happening, which everyone regularly involved in Twisted does a great job at already. Basically: ACK, fully agreed, you are not talking to the void. As a case study, we could look at https://twistedmatrix.com/trac/ticket/9410 <https://twistedmatrix.com/trac/ticket/9410#comment:17> / https://github.com/twisted/twisted/pull/1106 In Twisted 16.3.0 the behavior of Request.write was changed so that it raises an AttributeError if called after the connection has closed. Prior to that release, it silently did nothing in that case. Now, three years later, we have a PR which proposed restoring the behavior of silently ignoring the write to a closed connection. The original change was incompatible. The new change is incompatible. What should win out? -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Twisted for http/2 (RESTful) webservices - client/server
Hello, On dv., maig 24 2019, Jayanth Acharya wrote: Thanks Meejah. Appreciate your clearing up that Flask is not based on twisted, not sure I got that impression earlier. Checked Klein, and it seems quite promising (and seem quite similar to Flask, from developer standpoint). From the documentation it was not quite evident to me, as to how to use HTTP2 under Klein. I did find a reference to HTTP2 in this pull-request, but again not clear to me: https://github.com/twisted/klein/pull/113 Checked treq, but is it really advantageous over request ? Also found no reference to HTTP2 in treq documents. Alao thanks for the references to Crossbar.io and Autobahn. Will check them out shortly. Just let me add something that may have been "obvious to everyone" on that PR and not to you at that point, but it will be "obvious" to you after the next 5-20 minutes: Notice how that PR introduces the "endpoints" concept, that is a *very* useful concept in Twisted, which basically allows you to add support for pretty much any transport without any effort. So, if you want to run an HTTP2 server, you need two things: 1. Read this bit of the klein and twisted documentation: https://klein.readthedocs.io/en/latest/examples/alternativerunning.html#example-ipv6-tls-unix-sockets-endpoints https://twistedmatrix.com/documents/current/core/howto/endpoints.html 2. Then you have to install the optional twisted[http2] dependency *and* because HTTP2 requires TLS, you have to enable that by using the endpoints API (e.g. in klein). That's it for the server. Twisted's documentation *could* be a bit better on this, if you want to take a go at it, I'm reasonably sure everyone would be happy. The only mention I found for http2 on twisted docs is: https://twistedmatrix.com/documents/current/installation/howto/optional.html?highlight=http2 There is also this article which AFAIK still applies, except the optional dependency is twisted[http2] instead of twisted[h2]: https://pawelmhm.github.io/python/twisted/http2/python3/2016/07/30/twisted-http2.html Notice that an easy one would be to edit the documentation I linked to before, and add an example that runs an HTTP2 server, future people like you will be able to find a small example with the search bar :-). -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] New release of ldaptor
On dt., jul. 09 2019, Thomas Westfeld wrote: Dear all, I would love to see a new release of ldaptor, which incorporates the recent compatibility fixes with python 3. Furthermore I have submitted a new pull request for ticket #9596 and revised my pull request about documentation fixes #9243. Best regards, Thomas This would be awesome indeed. I keep going even if maybe only tangentially related: I want to stop deploying my ugly hacks to klein :-D [1]. [1]: https://github.com/twisted/klein/issues/96 The reason why I raise that is because IIUC, ldaptor and klein have the same kind of relationship to the Twisted project? Is there anything specific that can be done to help with the releases of these non-core but very related and useful components? -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Help with twisted.conch.manhole
On dg., abr. 19 2020, salil GK wrote: I am real need to debug my python application for memory issues. I found that using twisted.conch.manhole we can get a telnet session to python interpreter so that we can do some debugging sessions there. I am using twisted 16.6 in my server. Could you some one please give me some sample program for achieving this. Thanks ~S PS: I have posted this message in stack overflow. Sorry for cross posting. I have joined this group only today. As glyph mentioned, you really should be running newer Twisted; it is entirely possible that many recommendations would not work because of the old version. That being said, you can peek in this repository, which has a manhole over SSH and public key-based auth: https://github.com/evilham/isalive.me/blob/master/isaliveme/conch_helpers.py (At least parts of the code in that file should end up in Twisted some day) Or peek in matrix-synapse's code, which has a telnet-based one. Or these, even more minimal examples: https://twistedmatrix.com/documents/current/conch/examples/index.html -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] Help with twisted.conch.manhole
On dl., abr. 20 2020, Richard van der Hoff wrote: Or peek in matrix-synapse's code, which has a telnet-based one. synapse's manhole is SSH-based :) (dunno why, given it uses hardcoded auth, so all security depends on the manhole port being locked down, but still) I actually remembered this the second I sent that email :-D. My brain jumped from "hardcoded username and password" to Telnet somehow :-p. -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] bad news about twistedmatrix.com's hosting
\o On dg., ag. 01 2021, Glyph wrote: Hello Twistors, Our venerable hosting provider, tummy.com <http://tummy.com/>, will be terminating their business operations on September 30, 2021. datetime.date(2021, 9, 30) - datetime.date.today() datetime.timedelta(days=60) In addition to being a bit personally sad - Tummy has been an avid supporter of the Twisted community since the very beginning - this means we have just about 60 days to fully migrate our website, mailing list, and DNS's hosting from Dornkirk, the machine where it's been running continuously since 2013, to ... something else. it is sad indeed when friendly businesses terminate operations, but Twisted will go on :-). There are 2 problems here: We need a sponsor to help us find a new hosting or cloud provider where things can be hosted. We do pay tummy currently, and we can probably ask the SFC to pay a different hosting provider a similar price for equivalent services, but ideally we'd find someone willing to donate something so as not to put a drain on those resources. Let's define this so I and others can ask around with various infra providers: - What is the service currently? (e.g. VPS/Physical? Which resources?) - Are the resources allocated adequate? Can/should they be increased/reduced? - Is currently something on the "wishlist" for this service? (e.g. IPv6 support!) - Even if the goal is and should be for that expense to disappear or go down significantly: roughly what is the compensation being offered for this service? (it might be easier to convince someone to offer it at cost/partial compensation than it is to offer it for free) - Is location important? E.g. if I asked around and it were fruitful, it'd be EU or Switzerland-based and not US-based as it is right now. I will need significant help with the operational aspects of the migration. I typically do a bunch of behind-the-scenes system administration for twistedmatrix.com <http://twistedmatrix.com/> to keep the whole thing clunking along, but after my brain has been fried by a year and a half's worth of pandemic stress, I simply don't have the time, energy, or mental capacity to do this. I know I've asked for help before and rarely received any, but if I have to do this entirely by myself, the most likely outcome is that I'll migrate DNS to some free cloud thing so at least my email address doesn't break (I migrated SMTP, and thereby everything associated with personal email addresses to Mailgun some years ago, so Tummy is not in that loop for that), and the website (and this mailing list) will simply stop working sometime between now and October. So if you'd like to keep www.twistedmatrix.com <http://www.twistedmatrix.com/>, speed.twistedmatrix.com <http://speed.twistedmatrix.com/>, our IRC bot (which is offline anyway right now due to Freenode shutting down), https://twistedmatrix.com/highscores/ <https://twistedmatrix.com/highscores/>, this mailing list, or our dogfooding instance for Twisted Names DNS, please volunteer so we can start to coordinate. Thank you for both doing this so long and so far and for being straightforward about not being able to do it as much now. I'd like to help and would be particularly (aka more intensively) able to do so during August, even if that's just helping document what needs to be done and how. On a day-to-day basis I do some other sysadmin work and if necessary would be able to accommodate taking care of Twisted-related things into that. This is the documentation that I am aware of: https://twistedmatrix.com/trac/wiki/Infrastructure Particularly braid: https://github.com/twisted-infra/braid Is there anything else to look at? Something known to not be supported in braid / only partially supported? Would you rather schedule some online voice session where I poke your brain at what needs to be done (IIRC something similar was done about 5 years ago) and take notes that can be used (also by someone else) while you let your mind flow happily? If you've been wanting to just use Github Issues and don't care about preserving any of the data in Trac, congratulations, you're about to win that argument by default ;-). In the worst case scenario, I will download a backup image before things get turned off in case someone wants to deal with this I personally hope this doesn't happen; particularly the mailing list is a great low-bandwidth way of staying mostly up-to-date with the project. Cheers, -- Evilham ___ Twisted-Python mailing list Twisted-Python@twistedmatrix.com https://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
Re: [Twisted-Python] bad news about twistedmatrix.com's hosting
On dt., ag. 03 2021, Adi Roiban wrote: On Sun, 1 Aug 2021 at 10:29, Evilham wrote: \o On dg., ag. 01 2021, Glyph wrote: > Hello Twistors, > > Our venerable hosting provider, tummy.com > <http://tummy.com/>, > will be terminating their business operations on September > 30, > 2021. > >>>> datetime.date(2021, 9, 30) - datetime.date.today() > datetime.timedelta(days=60) > > In addition to being a bit personally sad - Tummy has been an > avid supporter of the Twisted community since the very > beginning > - this means we have just about 60 days to fully migrate our > website, mailing list, and DNS's hosting from Dornkirk, the > machine where it's been running continuously since 2013, to > ... > something else. it is sad indeed when friendly businesses terminate operations, but Twisted will go on :-). > There are 2 problems here: > > We need a sponsor to help us find a new hosting or cloud > provider where things can be hosted. We do pay tummy > currently, > and we can probably ask the SFC to pay a different hosting > provider a similar price for equivalent services, but ideally > we'd find someone willing to donate something so as not to > put a > drain on those resources. Let's define this so I and others can ask around with various infra providers: - What is the service currently? (e.g. VPS/Physical? Which resources?) We only have a single server. It is called "dornkirk" I don't know if it's a VM or bare-metal... but it shouldn't matter. - Are the resources allocated adequate? Can/should they be increased/reduced? I don't understand this question. Sorry. Can you please rephrase ? Thanks. This was very poorly worded, my bad. I meant how big of a machine (storage excluding ML archives, RAM, CPU, traffic) is currently used and whether or not it is over/under-provisioned. Without knowing this concretely, it is hard to try to get an entity to commit to donating resources. It is good to know that VM vs physical and location are not important factors. - Is currently something on the "wishlist" for this service? (e.g. IPv6 support!) Many things are on the wishlist. The priority is to have the services up and running, even after dornkirk is dead. - Even if the goal is and should be for that expense to disappear or go down significantly: roughly what is the compensation being offered for this service? (it might be easier to convince someone to offer it at cost/partial compensation than it is to offer it for free) I don't know what is the current cost to cover the expenses for dornkirk. - Is location important? E.g. if I asked around and it were fruitful, it'd be EU or Switzerland-based and not US-based as it is right now. No. Location is not important. > I will need significant help with the operational aspects of > the > migration. I typically do a bunch of behind-the-scenes > system > administration for twistedmatrix.com > <http://twistedmatrix.com/> > to keep the whole thing clunking along, but after my brain > has > been fried by a year and a half's worth of pandemic stress, I > simply don't have the time, energy, or mental capacity to do > this. I know I've asked for help before and rarely received > any, but if I have to do this entirely by myself, the most > likely outcome is that I'll migrate DNS to some free cloud > thing > so at least my email address doesn't break (I migrated SMTP, > and > thereby everything associated with personal email addresses > to > Mailgun some years ago, so Tummy is not in that loop for > that), > and the website (and this mailing list) will simply stop > working > sometime between now and October. So if you'd like to keep > www.twistedmatrix.com <http://www.twistedmatrix.com/>, > speed.twistedmatrix.com <http://speed.twistedmatrix.com/>, > our > IRC bot (which is offline anyway right now due to Freenode > shutting down), https://twistedmatrix.com/highscores/ > <https://twistedmatrix.com/highscores/>, this mailing list, > or > our dogfooding instance for Twisted Names DNS, please > volunteer > so we can start to coordinate. Thank you for both doing this so long and so far and for being straightforward about not being able to do it as much now. I'd like to help and would be particularly (aka more intensively) able to do so during August, even if that's just helping document what needs to be done and how. On a day-to-day basis I do some other sysadmin work and if necessary would be able to accommodate taking care of Twisted-related things into that. To coordinate migration and also day-to-day Twisted project things we
