, 2022 at 1:52:07 PM UTC-5 Andrew Mshar wrote:
> I like that idea, Tim. A few things came up, so I'll open this PR next
> week.
>
> Thanks,
> Andrew
>
> On Friday, November 11, 2022 at 12:21:43 PM UTC-5 schill...@gmail.com
> wrote:
>
>> Hi folks!
>>
We should at least update those Trac and Triage Workflow docs to point to both,
maybe with the Forum first?
Andrew
On Thu, Jan 19, 2023, at 12:30 AM, Carlton Gibson wrote:
> I'm trying to begin new conversations there where I can.
>
> The main issue is that we're still pointing pe
, as it'll be timed right after the
4.2 feature freeze in January.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
- the ability to
moderate after a post has gone out, rather than gating all posts behind
approval if they're untrusted, is a big step in itself, not to mention the
ability to remove sensitive or offensive content once it's posted.
Andrew
On Monday, November 28, 2022 at 10:01:17 PM UTC-7 m
concluded and a result reached.
Andrew
On Wed, Nov 30, 2022, at 10:44 AM, Andrew Godwin wrote:
> Yes, I agree we can use the forum in future since it's less tied to Google.
>
> Provided the current +5 vote carries through to the end of the voting period,
> I will be suggesting that the Tec
Board has performed
their vote, as it only seems appropriate.
Andrew
On Mon, Nov 28, 2022, at 9:30 PM, 'Adam Johnson' via Django developers
(Contributions to Django itself) wrote:
> +1 from me
>
> And +1 to using the forum in future
>
> On Tue, 29 Nov 2022 at 00:23, charettes wr
e DEP here:
https://github.com/django/deps/blob/main/draft/0012-steering-council.rst
My vote is +1, as I am the author of the DEP and believe it is in the best
interests of the longevity of the Django project and sustainable governance.
Andrew
--
You received this message because you are
I like that idea, Tim. A few things came up, so I'll open this PR next week.
Thanks,
Andrew
On Friday, November 11, 2022 at 12:21:43 PM UTC-5 schill...@gmail.com wrote:
> Hi folks!
>
> Andrew (Mshar) how do you feel about reworking:
>
> > If you know someone who you think sh
Just want to pop in and say these are great ideas - feel free to copy me in
on any PR if you want extra opinions!
On Tuesday, November 8, 2022 at 8:26:28 AM UTC-7 Carlton Gibson wrote:
> Great, Thanks Andrew. No urgency
>
> On Tue, 8 Nov 2022 at 16:16, Andrew Mshar wrote:
>
Will do, Carlton.
Tim and Cory, thanks for the suggestions. I'll incorporate those in the PR
and post here when it's ready. Probably not today, but I should be able to
open it before the end of the week.
Thanks,
Andrew
On Tuesday, November 8, 2022 at 10:10:51 AM UTC-5 carlton...@gmail.com
/end new language.
Borrowed the list of categories from Andrew Godwin's DEP for the update to
the technical board. Per Tim's recommendation, do we want to include
anything about the review process?
Also, I'm a little unsure about that last bit about applying, but I wanted
to put something encou
going to introduce this we should _also_ introduce wording for
what happens if we fail to elect a Board, as this makes it much more likely
(barring the entire previous board from running).
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers
On Sun, Oct 30, 2022, at 10:42 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 4:34 PM Andrew Godwin wrote:
>> __
>>
>> I have copied in the DSF Members mailing list as it is a governance-related
>> DEP, but if we could keep all discussion on the thread in the Dj
and
hopefully get more folks (who do fit the criteria) to apply.
If someone wants to draft new language, that would be great. If not, I may
have some time next week to try.
Thanks,
Andrew
P.S. Great meeting both of you at Djangocon last week!
On Thursday, October 27, 2022 at 7:41:15 AM UTC-4 schill
this forward.
(I didn't even discuss how we might fund this, which is also a conversation to
have, but waving our hands in the air and going "sponsorship" is enough for me
to start with)
Andrew
On Wed, Oct 26, 2022, at 4:01 PM, Paolo Melchiorre wrote:
> Hi everyone,
>
> Follow
) as well as initial feedback on its content as
well.
I have copied in the DSF Members mailing list as it is a governance-related
DEP, but if we could keep all discussion on the thread in the Django Developers
mailing list, as per DEP 0001, that would be great.
Thanks,
Andrew
--
You received
DEP shortly so it's more clear exactly
what I want to change at a written-rules level - I suspect feedback on a more
concrete proposal will help us talk about it more clearly.
Andrew
On Wed, Oct 26, 2022, at 4:55 PM, James Bennett wrote:
> On Wed, Oct 26, 2022 at 12:02 PM Andrew Godwin wr
'm more than willing to hear alternative
suggestions for what that change should be (though as outlined previously, I
really don't think that change should be "remove the entire current Board for
underperformance and have another election").
Andrew
On Wed, Oct 26, 2022, at 12:23 PM, Ja
otherwise should.
Is there anywhere that we have a more clear outline of what we expect from
members both before they join and after? If not, could we have that
discussion here to clarify for future members?
Thanks,
Andrew
--
You received this message because you are subscribed to the Google
Again, I'm not saying "we should write a new DEP and *that'll* fix it", I'm
trying to come from a position of working out what we can and should be
*doing*, and then ensuring our rules match that.
Andrew
--
You received this message because you are subscribed to the Google Groups
"
belief in the need for
visible, servant leaders in OSS communities rather than trying to embrace a
flat hierarchy with mechanical checks and balances - but that is for another
day.
Andrew
On Mon, Oct 24, 2022, at 4:26 PM, James Bennett wrote:
> On Mon, Oct 24, 2022 at 2:24 PM Andrew Godw
ven the
most recent TB election was uncontested and several long-time Django
contributors have told me they'd be more willing to join a TB that was less
strictly technical-all-the-time, that it makes sense for us to also look at
those requirements.
Andrew
On Mon, Oct 24, 2022, at 2:54 PM,
ted ideas, including any
additional changes you think might be appropriate that I have not covered here.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group
being
tested in memory though.
On Monday, January 31, 2022 at 6:48:13 PM UTC-5 Adam Johnson wrote:
> Hi Andrew,
>
> I'm afraid I don't know much about async, but I can point you at some
> recent changes. Andrew Godwin created a PR with the draft of the async ORM
> API. Carlton
signed for synchronous
db engines, so the default alias database engine will switch around a bunch
of times.
3. Implement a test decorator that switches the default alias connection.
Lemme know if that's confusing.
Thanks,
Andrew
--
You received this message because you are subscribed to the Google
,
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this
desconstructions, usually).
Andrew
On Sat, Sep 18, 2021, at 9:06 AM, Christian González wrote:
> Hi,
>
> before I issue a bugreport, I'll ask here first.
>
> On
> https://docs.djangoproject.com/en/3.2/topics/migrations/#adding-a-deconstruct-method
> I can read that deconstruc
and can have
everyone developing on it do something at once, you can just do it via a
complete migration reset and be happy. Squashing is for a very specific
backwards-compatibility scenario that, I suspect, many Django projects
developed internally are not in.
Andrew
On Tue, May 11, 2021, at 7
adoption
for webpack, because of the JS bundles continuously growing (being a huge
turn-off once you have a semi-production-grade SPA repository), I proposed
a moderate idea:
To fix this, I'm going to develop a middleware as described in issue #3
here:
https://github.com/Andrew-Chen-Wang/SPA
is found here:
https://github.com/Andrew-Chen-Wang/SPA-with-httponly-sessions .
The original purpose of this thread was for SPA development, not really for
JWTs. I'm a maintainer at SimpleJWT, a repository that almost all tutorials
use to show React/SPA/JS Frameworks and Django integration. I also
I agree we should not be quite so beholden to our existing Python version
policy - that was mostly to get us out of the early 3.x era. Now things are
more stable, I'd support a policy that is much more like "any stable version of
Python currently out there and supported".
Andre
script to mash the APIs over HTTP)
Andrew
On Sun, Nov 8, 2020, at 2:36 PM, Andrew Godwin wrote:
> I have been moving house this week (plus, yknow, the election) so I haven't
> got anything done, but hope to poke at it early next week!
>
> Andrew
>
> On Sun, Nov 8, 2020, at 4:34
I have been moving house this week (plus, yknow, the election) so I haven't got
anything done, but hope to poke at it early next week!
Andrew
On Sun, Nov 8, 2020, at 4:34 AM, Carlton Gibson wrote:
> Hi Tom and Andrew.
>
> This week has been *busy *(shall we say) I know — can I assum
API access for you to try it,
Tom.
Andrew
On Thursday, October 29, 2020 at 9:23:45 AM UTC-6 carlton...@gmail.com
wrote:
> I don’t have any controls here. I’m pretty sure Florian would be the most
> likely candidate. (No doubt it’s Jacob.)
>
>
>
--
You received this message b
.
Andrew
On Tue, Oct 13, 2020, at 10:37 AM, Adam Johnson wrote:
> I'd like to see what Andrew thinks on this.
>
> I had a thought that the issue you're seeing may be related to a dependency
> of your project creating/destroying event loops in the background. If you
> could tr
Hi all,
1.5 weeks ago, I posted that I was interested in making Django's cache
async. Just here to report that the package for django-async-redis is on
pypi and the repo is
here: https://github.com/Andrew-Chen-Wang/django-async-redis. Please test
it out. I have only tested it on a local
right now I would prefer get_async all things considered, since I don't
think autocomplete is necessarily easier either way, but I'm open to
suggestions.
Andrew
On Sun, Sep 27, 2020, at 6:03 PM, Andrew Wang wrote:
> Cool, thanks for the clarification. One thing I noticed while programm
Cool, thanks for the clarification. One thing I noticed while programming
the test cases (so WIP is
here: https://github.com/Andrew-Chen-Wang/django-async-redis) is that it's
not really fun having to type out get_async since autocomplete. If a dev
knows that they'll be using an await, then I
Hey Adam and Andrew,
I can definitely make the naming scheme something like get_async() rather
than just get().
> This section specifically says that the default implementations will back
onto the sync methods by default, so built-in cache backends won't need to
all be converted (at o
of them and if everything can be made to work regardless of what mode (sync or
async) it's in; hopefully there's a lot less long-lived-connection issues than
in the ORM, say.
Andrew
On Sat, Sep 26, 2020, at 3:56 PM, Adam Johnson wrote:
> Hi Andrew
>
> I don't believe any work ha
Hey guys, I'd like to contribute to the effort to make Django more async
capable. I've started to write an aioredis based cache backend based on
django-redis, but I noticed the BaseCache in Django is still all
synchronous basically.
I was wondering which backends I should make async capable
- but that would be my suspicion as to why this
would be structured this way in my original code. As you say, the optimiser has
improved in the years since, but I don't think you can optimise away the
circular reference problem?
Andrew
On Sat, Sep 19, 2020, at 3:20 PM, Silvio J. Gutierrez wrote:
> 3 te
on. Migrations isn't meant to only be "makemigrations" and the model-based
approach; there's also an underlying SQL application and dependency ordering
engine that can be used standalone.
Andrew
On Thu, Aug 6, 2020, at 1:27 PM, Paolo Melchiorre wrote:
> HI all,
>
> I wo
working on something, and if it allows seamless migration, that'd be
great. That said, if they take more than a month or two, we should just change
it and get it over with.
Andrew
On Tue, Jun 16, 2020, at 12:59 PM, Adam Johnson wrote:
> On the branch rename, right now I'd rather wait to see w
Yup, I'm seeing if we can get asgiref fixed today, otherwise I'll revert the
change that broke Django and issue 3.2.9.
Andrew
On Tue, Jun 16, 2020, at 2:48 AM, Florian Apolloner wrote:
> Ok, so rebasing PRs to current master will fix this (leaving this here as
> note for others w
down to just a couple of
migrations each app, it would be nice to have that be a shortcut.
Andrew
On Wed, Apr 22, 2020 at 10:35 AM Javier Buzzi
wrote:
> This comes from a place of headaches: we're a large team, and our sprint
> are a month long, in that month we generate a lot of migr
ly matters, and while the
date is sometimes useful for people to resolve merge conflicts, I don't
think it's better than more informative autogenerated names, so I'm happy
to go with the change.
(60 is a bit long though, maybe we can bump it down to something a bit
shorter?)
Andrew
On Wed, Apr 22,
I also vote in favour of Claude becoming a Merger!
Andrew
On Tuesday, April 21, 2020 at 4:28:41 AM UTC-6, Markus Holtermann wrote:
>
> I vote in favor of Claude becoming a MERGER.
>
> Cheers,
>
> Markus
>
> On Thu, Apr 16, 2020, at 10:31 PM, charettes wrote:
>
I am particularly excited for native async support arriving - that's
something I'd love to have and ship support for from our side when it's
done. The rest looks quite sensible too.
Andrew
On Wed, Mar 11, 2020 at 3:39 AM Jure Erznožnik
wrote:
> His proposed changes look awesome to me!
>
nch are weak in, say, the HTTP-serving-speed area) and then
run them against pull requests and each release, so we can make sure Django
doesn't get slower while nobody is looking.
I'm sure there's a lot more, but these are top of mind at the moment!
Andrew
On Tue, Dec 10, 2019 at 11:52 AM Carlton G
* A proper story and hooks for running Django as a service (i.e. outside of
a traditional HTTP request/response cycle)
And some ludicrous projects I'd still consider:
* Evented/event-sourcing database work on top of the ORM
* A GraphQL-to-ORM mapper
Andrew
On Tue, Dec 10, 2019 at 8:25 AM Carlton
I agree - we need to communicate that ASGI support does *not *mean you can
start writing async def views. I think we should put a big disclaimer to
that effect next to it in the release notes and say it should be coming
next release.
Andrew
On Mon, Oct 14, 2019 at 5:45 PM Josh Smeaton wrote
://forum.djangoproject.com/t/forum-feedback/17/).
See you there!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-
Another point has been raised to me by someone off-list - adding a forum
would significantly increase the surface area that the Code of Conduct team
have to cover (and potentially become one of the biggest time sinks
required), so we need to consider them in any decision.
Andrew
On Mon, Aug 12
Groups is probably
going to be around for a long time).
Andrew
On Monday, August 12, 2019 at 4:04:23 AM UTC-5, James Bennett wrote:
>
> I'm not necessarily opposed to this, but I am a bit skeptical of the
> long-term archival utility of forums, in large part due to my experience as
>
t, though my impression
is that it's relatively easy since he had it up before I'd got off the
plane back to the US. Not sure about the djangoproject.com login situation
- we need to investigate how flexible the plugin system is, and it might
need OpenID on the Django end.
Andrew
--
You received
ense I am describing - one that
has categories, editable posts, and the ability to selectively get email
for certain categories or threads rather than all-or-nothing. The Groups
forum interface is more just an online mailing list interface, with all the
problems of the underlying list model.
Andrew
s I do now!), and honestly the same thing for django-users. That said, I
also recognise that diluting the support/discussion pool is not exactly an
attractive idea, which is why I'm asking for input!
Thanks,
Andrew
--
You received this message because you are subscribed to the Google Groups
"Dj
, but the question I'd really want everyone
to answer is if it's worth the porting effort. I suspect the answer is yes,
but this does need a process DEP and some discussion, and maybe also
looking at what cpython are doing and comparing and contrasting.
Andrew
On Wed, Aug 7, 2019 at 4:12 AM Carlton Gibson
- it needs
stateful storage to aid in transferring connections, and this means it's
really hard to have a single method that will work for everyone. Having
"one right way to do it" is sort of a necessary prerequisite to having
something in Django, and I just don't feel like it's there.
Andrew
On
I agree too. Let's change it.
Andrew
On Sat, Jul 27, 2019 at 4:03 AM Markus Holtermann
wrote:
> Easy: +1 from me as well for reasons state before.
>
> /Markus
>
> On Sat, Jul 27, 2019, at 6:15 PM, Adam Johnson wrote:
> > +1 from me too for the reasons that Aymeric states.
has ever gotten, and
I can only apologise to the incoming board for springing this on them right
after an election!
If anyone on this list would like to continue to talk about the above, or
if a Board member wants to bring their conversation out here, you are all
more than welcome.
Andrew
On Sun
On Sun, Jul 21, 2019 at 1:11 PM Ehigie Aito wrote:
> Django 3.0?
>
Django follows time-based releases; what's in Django 3.0 will depend on
when we can get it landed. At the moment I am optimistic something will
make it in, but I make no promises!
Andrew
--
You received this message b
I'll ask permission and then summarise the points raised back out here!
Andrew
On Sun, Jul 21, 2019 at 1:01 PM Jacob Kaplan-Moss
wrote:
> Congratulations, and great news!
>
> I hope the TB will consider sharing details and/or a summary of the "long
> and involved vote&q
async work.
If you are interested in helping with fundraising, then please get in touch
with me directly; I have some ideas about how to structure it, but I could
do with some people to help out. Otherwise, stay tuned for more information
about how to get involved contributing and what to work on!
.
Andrew
On Thu, Jun 27, 2019 at 2:01 PM Peter Baumgartner
wrote:
> The big issue I see is that a resource must reside directly in a
> Python module. You can not load a resource from a child directory,
> e.g. I can load "index.html" from the Python module
> "myproject.t
migrations) rather than direct file access (like templates).
It would be nice to investigate this a bit more, though. If we can get
Django compatible, or work with PyOxidiser if we find a reasonable
workaround they could implement, it would be great.
Andrew
On Thu, Jun 27, 2019 at 12:39
The DEP is drafted and in the DEPs repo, and awaiting approval by the
freshly-elected Technical Board once I submit it. In the meantime, we
landed the ASGI patch, as well.
Andrew
On Tue, Jun 25, 2019 at 3:30 PM Chris Barry
wrote:
> Hey all,
>
> Just wondering what the future of this i
sn't ready. However, I've been working with it for the
last four years, including on several very large deployments, and there are
some direct benefits that I believe we can get without making things a lot
more complex, even inside Django.
Andrew
--
You received this message because you are subs
/_tomchristie/status/1005001902092967936) using Python
asyncio/ASGI - and see that it does make a difference. Obviously it doesn't
matter for all deploys, but I believe it matters for the majority of site
architectures as they scale up.
Andrew
--
You received this message because you are subscribed to
ore turned around and
blessed greenlets and gevent as the chosen async solution, I'd change my
mind, but I haven't seen any evidence of that over many years.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Djang
on writing up a funding plan for this, including
various options for how we can pay people for their work.
Andrew
On Tue, May 14, 2019 at 2:55 AM Andrew Godwin wrote:
>
>
> On Mon, May 13, 2019 at 4:31 AM Tobias Kunze wrote:
>
>> Hi Andrew (and everybody following the dis
On Mon, May 13, 2019 at 4:31 AM Tobias Kunze wrote:
> Hi Andrew (and everybody following the discussion, of course),
>
> First off, thank you for your work here. DEP9 is an excellent technical
> document, and it was as easy and pleasant to read as a document of this
> scop
One quick clarification - when I said "stable (1.0)" release, I in fact
meant the first release that the Black project officially marks as stable.
Black doesn't use versioning that would result in a stable release being
called 1.0, as far as I know, given they are on 19.3b0 right no
and updating the
DEP!
Yours in auto-formatting,
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developer
section in the DEP that
says why we can't do it in a separate package, but basically, the changes
required to Django are too deep to do separately (or even as a long-running
fork).
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contrib
ORM that works within Django?
>
It is indeed encode/databases!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an
so people can't screw up by accident. It would be quite easy to
extend this to enforcement on both the sync and async versions - there's
maybe an edge case that you can call an async function from a thread you
have not started an event loop in _yet_, but I'd rather see if and when
that happens and provide
nd proposal, probably, but it might be a nice way out of the
initial thing of requiring select_related. I just don't know enough about
how that might cascade down the ORM internals to judge it at this point!
Andrew
--
You received this message because you are subscribed to the Google
On Thu, May 9, 2019 at 1:04 PM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello Andrew,
>
> Thanks for your work putting together this plan. Within our constraints,
> it's a good plan.
>
> Regarding templating, I would say it isn't a priority because
f
this async push.
Andrew
On Thu, May 9, 2019 at 12:56 PM Patryk Zawadzki wrote:
> That said, I also think it's important to allow the ORM to support both
>> modes in the long term. I truly believe the best way to be able to write
>> async code is to _have the choice to write
hat's
fine - it takes literally zero extra effort to go either way".
This is why I propose in the DEP that we do the view layer first, and then
move onto the ORM as a second wave.
Andrew
On Thu, May 9, 2019 at 12:29 PM Patryk Zawadzki wrote:
> I'm not sure but for me the "What
those two that works.
Thanks for taking the time to read through!
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
This is quite unrelated to frontend - I'll explain more of the impact and
potential impact in the DEP when I write it up.
Andrew
On Wed, 1 May 2019, 08:30 Elad Yaniv, wrote:
> Exciting stuff!
> does this mean that django 3.0 COULD compete with frontend js frameworks
> ? (angular
o skip writing this up, and from
here on out it becomes much more of a new feature than merely adding safety
and a new handler.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe f
So, it looks like most of the comments on this PR have happened and been
resolved - unless anyone has any objections, I will merge it in after a
couple more days (just in time for PyCon US).
Andrew
On Wed, Apr 24, 2019 at 1:50 PM Andrew Godwin wrote:
> Hi everyone,
>
> Just wante
>From my read this also looks like it would make the auto-reloader able to
work a lot better with an async-capable server, so I would be in favour
given that is likely in the future as well.
Andrew
On Tue, Apr 23, 2019 at 9:33 PM Ramiro Morales wrote:
> Hi all,
>
> I had a stab a
might want to consider a
better avenue for constructive feedback.
Andrew
On Tue, Apr 30, 2019 at 12:31 PM Christian González <
christian.gonza...@nerdocs.at> wrote:
>
> Am 30.04.19 um 14:28 schrieb 'Laurens A. Bosscher' via Django developers
> (Contributions to Django itself):
into, as we
can then start making all the other parts of Django async-capable as a
parallel effort.
Reviews and comments on the PR are encouraged; I want to make sure this is
not going to hurt existing sync Django when it lands, and that it's a
useful stepping stone towards async in views.
Andrew
ot; button to enable much easier browsing
of files prior to it.
For that reason, I am +1 to using the Black code formatter.
Andrew
On Sun, Apr 14, 2019 at 10:22 AM Curtis Maloney wrote:
> So to summarise the discussion so far:
>
> 1. automated code formatting will be a great boon - reduce wo
for Django. Adding "git clean" to the script is probably good enough,
but I might be tempted to make a script where you pass it a commit hash and
it checks it out to a fresh temporary directory and packages from there?
Andrew
On Mon, Feb 11, 2019 at 8:28 AM Carlton Gibson
wrote:
me try that, but I may turn
that off if it turns out to be too much.
Thanks all who came forward. I'm hopeful that things can be kept going!
Andrew
On Wed, Jan 30, 2019 at 2:18 PM Andrew Godwin wrote:
> Just to update on this - nobody has individually come forward to help
> full-time, th
the repos come Feb
1st, and barring positive confirmation someone else is going to actively
take over I'll put up notices on all the projects that they are actively
unmaintained apart from security issues.
Andrew
On Thu, Jan 17, 2019 at 10:06 AM Andrew Godwin wrote:
> Hi all,
>
> I'
On Mon, Jan 21, 2019 at 4:34 AM Michael Martinez <
writemichaelmarti...@gmail.com> wrote:
> Hi Andrew
>
> To me, Websockets is the defining use case for using Django Channels. From
> a user POV, saying that Channels is focused on the wrong problem
> (websockets) is like
On Sat, Jan 19, 2019 at 12:13 PM Carlton Gibson
wrote:
> Hey Andrew.
>
> I've been thinking a lot about this. You clearly shouldn't be maintaining
> Channels single-handedly indefinitely.
>
> I know Channels started out separately, but, it's time to think about
> what, if
outline
what's needed.
Andrew
On Thu, Jan 17, 2019 at 10:10 AM Nasir Hussain
wrote:
> Hi andrew, I can help in maintaining the projects. Kindly let me know what
> are the next steps.
>
> Thanks
>
> On Thu, Jan 17, 2019, 11:07 PM Andrew Godwin
>> Hi all,
>>
>>
. If you want to
help out, please feel free to reply either here or get in touch with me
personally to chat about what's involved.
Andrew
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubs
that sort of
stuff.
Andrew
On Wed, Nov 21, 2018 at 11:48 AM Brylie Christopher Oxley
wrote:
> Hello,
> I have been developing with Meteor.js for about four years now. One really
> nice aspect of Meteor is that it streams data to the client, which in turn
> updates the templates (e.g.
complicated
code in migrations won't be tested properly.
Andrew
On Mon, 8 Oct 2018, 00:59 Ian Foote, wrote:
> Hi all,
>
> On my pull request (https://github.com/django/django/pull/10406)
> refactoring how Django creates database constraints I introduced a
> dependency on sqlpars
Just to say that I've reopened the original issue in question as it's clear
now this needs to be fixed. I won't be able to get to writing a fix for a
bit, though, so if someone else wants to they should.
Andrew
On Tue, Aug 28, 2018 at 5:41 AM John Obelenus wrote:
> Just finished reading b
1 - 100 of 609 matches
Mail list logo
