The startproject template already uses 64 bit integers, and the default
will change in a future version. See the 3.2 release notes (
https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-auto-created-primary-keys
) :
Starting with 3.2 new projects are generated with
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
I noticed I've continued to encounter this problem in code review
relatively frequently, so I made a ticket:
https://groups.google.com/g/django-developers/c/7JwWatLfP44/ . Tim then
pointed me back to this discussion.
I'm happy to implement Tim's suggestion of a RuntimeWarning followed by
DRF remains an extension to Django. We don't want Django to depend on it.
But you're free to set up a startproject template that includes the
settings, and use that.
https://docs.djangoproject.com/en/3.2/ref/django-admin/#cmdoption-startproject-template
On Tue, 14 Sept 2021 at 08:44, abdul azeez
I've replied on the forum.
On Tue, 14 Sept 2021 at 13:21, Roxane Bellot
wrote:
>
>
> Hi guys !
>
> First of all, i’m new here, so if this issue has already been discussed or
> if here is not the place to talk about it (I also opened a forum post
>
This is the wrong mailing list for such requests. Try posting on the django
forum or Twitter.
On Sun, 5 Sept 2021 at 15:49, 'la...@larrylobert.com' via Django developers
(Contributions to Django itself) wrote:
> I would like to connect with an experienced Django developer to continue
> with
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
I'm in favour of the change. Leaving the file as-is when no actual data
changed just makes sense to me.
The original discussion didn't touch upon the --update flag, so maybe it
didn't exist then, or the participants didn't know about it. Its existence
really weakens the argument that “we
Hi
You can use 'pip install --editable' with the path to your copy of the
django repo to test it in another virtualenv.
Here's the option docs:
https://pip.pypa.io/en/stable/cli/pip_install/#install-editable
Here's a demo video: https://www.youtube.com/watch?v=gYYi7varbmE
Thanks,
Adam
On
I'm responding to your other thread where you gave a little more
information. Please be careful posting to the list in future ;)
On Thu, 19 Aug 2021 at 07:17, No Offence wrote:
> Hey there, I'm new in this contributing environment. I have fixed one
> issue but now I don't know how to test it
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
August 10, 2021 at 6:26:42 PM UTC+5 Adam Johnson wrote:
>>
>>> Hi!
>>>
>>> I think you've found the wrong mailing list for this post. This mailing
>>> list is for discussing the development of Django itself, not for support
>>> using Django. This mea
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Ruby on Rails uses "correct" plural forms in code. But in order to do this
it contains a special library to pluralize words correctly, e.g. octopus ->
octopuses. And naturally that strategy requires per-language and per-word
knowledge, and can go wrong when trying to use non-english words.
Rather
I'd be +1 on moving the default to UTC.
Or we could change Trac to pick up the browser's timezone offset and
display datetimes accordingly.
On Fri, 6 Aug 2021 at 15:28, Tom Carrick wrote:
> While moving the default to UTC is probably a good idea - you can change
> this for yourself in
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
It should already work to do `Model.objects.filter(...).bulk_update(...)` ,
no?
On Tue, 13 Jul 2021 at 00:50, opqpop wrote:
> Hi, I'd like to pass additional partition columns into the filters for a
> QuerySet's bulk_update(). These would be no-op filters solely for the DB to
> understand from
It's not appropriate to promote unofficial channels on this mailing list.
On Mon, 19 Jul 2021 at 11:19, SKYLINE TV wrote:
> Welcome to Django developer meeting hub
>
>
> developer meeting point is a discussion forum where we talk about our
> various challenges in python programming and Django
+1 I’m in favour of giving Florian the access and necessary training,
should he want it.
On Wed, 21 Jul 2021 at 10:18, Carlton Gibson
wrote:
> Hello Technical Board.
>
> Mariusz is working on updating the Organisation docs to reflect the DEP 10
> governance changes.
>
>
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi,
If you just opened a ticket there's no need to come directly to the mailing
list. Someone will respond to you on the ticket tracker first.
Thanks,
Adam
On Tue, 6 Jul 2021 at 10:55, shrwnkr wrote:
> Hi,
> can we talk more about this, ticket (
> https://code.djangoproject.com/ticket/32907)
ket number (in fact I think I saw Nick Pope point
>>> to something today that says we don't ref tickets?). [1]
>>>
>>> - For the headline features add names to the blog post [2]. Could also
>>> add link to their blog / website /Twitter (less sure about this second
>&
Hi Alexandre
This ticket does go quite deep into the URL resolution infrastructure. You
could try reading more of its internals, but for a first ticket I'd say
this one is quite advanced. If there's another ticket in an area of Django
you are more comfortable with, perhaps that would be better.
юн. 2021 г. в 16:45, 'Adam Johnson' via Django developers
> (Contributions to Django itself) :
>
>> What validation do you need? Much can be done in the database with
>> constraints, especially check constraints.
>>
>> On Wed, 30 Jun 2021 at 08:05, Михаил Итпрогер
What validation do you need? Much can be done in the database with
constraints, especially check constraints.
On Wed, 30 Jun 2021 at 08:05, Михаил Итпрогер
wrote:
> Hello, I am currently developing a reusable application using the Django
> framework.
>
> It just so happens that the instances of
pymemcache also supports a cas() method, so that's two backends that could
have the other method.
I think the main problem is as Russell highlighted - supporting other
backends. It would be nice to see research into emulating cas(), at least
on LocMemCache which is often used as a fake during
Django has the TemplateCommand class to support its startproject and
startapp. These two are fairly similar so the class exists to share code
between them.
As I understand, your GDAPS project aims to provide similar functionality,
but with differences. In this case I can see that you'd have
Would it be bad to have Django respond to both shortcuts?
On Mon, 21 Jun 2021 at 21:40, Matthew Pava wrote:
> Ctrl + Break and Ctrl + C are treated slightly differently by Windows.
> Ctrl + Break is always a signal, but an application can override the
> functionality of Ctrl + C.
>
>
>
> Please
ity into
> django itself? I hadn't seen anything related before now.
>
> On Tue, Jun 1, 2021 at 11:38 AM 'Adam Johnson' via Django developers
> (Contributions to Django itself)
> wrote:
>
>> Hi Mike!
>>
>> Probabilistic culling probably is the best we can d
t in this direction.
>
> Thanks again to you guys for taking the time to lead me through this!
>
> Sébastien
>
> Le mardi 8 juin 2021 à 17:39:22 UTC+2, Adam Johnson a écrit :
>
>> I'd be happy to suggest longer versions (if technically possible to
>>> implement)
Model defines these defaults:
def __repr__(self):
return '<%s: %s>' % (self.__class__.__name__, self)
def __str__(self):
return '%s object (%s)' % (self.__class__.__name__, self.pk)
The repr includes "self", which will call __str__, which includes self.pk.
So the default
>
> I've gone through the documentation of pymencache and if I'm not wrong its
> nowhere written that it recommends default_noreply to be set to True
>
It's covered in the "best practices" section, which is a list of their
recommendations:
Hi Thomas
As I understand there wouldn't be much required by Django to support this -
just one function. So if it came to Python, I think we'd like to see a
working snippet, maybe in a third party package, before merging support.
In terms of the PEP, - there are already "too many" ways to
>
> I'd be happy to suggest longer versions (if technically possible to
> implement).
>
At least the documentation for triaging tickets is here:
https://github.com/django/django/blob/main/docs/internals/contributing/triaging-tickets.txt
.
I do not understand why the $.fn.djangoAdminSelect2
Yes we use fastly and that's the reason it has been down.
On Tue, 8 Jun 2021 at 14:38, Roger Gammans
wrote:
> It may have had something to do with this? I seem to remember fastly
> did offer some OSS projects some CDN services.
>
> https://www.bbc.co.uk/news/technology-57399628
>
>
> On Tue,
Sébastien - on your original post: you didn't provide any useful title or
ticket links in your post. That may have stopped readers engaging on the
list. No one knows ticket numbers, but some people will be interested when
they see a post on "the admin autocomplete". Links would make it easy to
Hi Diptesh
Django's serialization framework is mostly used for saving model data for
later loading into the DB - normally for setting up environments or tests.
I don't think saving properties is useful in this case. If you're using
serialization for API responses, look at Django REST Framework's
Hi
I believe archiving stopped with the introduction of GDPR, which caused the
IRC archive bot we were using to shut down. GDPR made it quite unclear if
persisting chat logs (that users could assume to be ephemeral) would be
allowed. There was a previous django-developers thread on this.
Thanks,
Hi
This mailing list is not for commercial purposes.
Thanks,
Adam
On Sun, 6 Jun 2021 at 08:31, Cyber Black
wrote:
> hey, i am tushar chauhan from india in dehradun so i hope everyone are
> good i want to discuss for django scope in india i want to say i have
> completed django framework and
The logs last a limited amount of time, I think it’s maybe 7 days. You’ll
need to push again to trigger a new run after that.
On Sun, 6 Jun 2021 at 12:57, Sanskar Jaiswal
wrote:
> Hello everyone
>
> I'm working on this PR
>
I think a breaking change for the widget HTML is fine too, if it improves
everyone’s apps. Perhaps documenting in the release notes how to undo it
(eg copy this template file into your project, reconfigure the widget to
use the template like so) will make it easier for folks with incompatible
CSS
The packages Django-import-export provides such functionality in a fairly
robust manner. Try that. I don’t see a reason to merge too much
functionality into the core Django admin, as it will become a maintenance
burden.
On Fri, 4 Jun 2021 at 16:51, Mohit Gupta wrote:
> Hello,
>
> I'm Mohit
Hi Mike!
Probabilistic culling probably is the best we can do in the DB cache, aside
from moving culling to a background task.
I wrote an implementation of this probabilistic culling in the django-mysql
cache backend (which is mysql only):
ith the other methods i.e db_for_read / db_for_write
>>>> as
>>>>they clearly indicate certain operational semantics which aren't tied
>>>> to a
>>>>transaction since it can have both reads and writes within it.
>>>>2. Als
Aditya - you didn't answer Simon's first question: "Can you think of places
where this db_for_transaction hook would differ in any way from what
db_for_write returns?" I think this is the crux of the issue. atomic does
already call DB routers - in what case could you need to return a different
t is that by default it
> should fully serialize tests it's mixed into, and that by configuring a
> different file (or "__file__", say), you can create sub-groups of tests
> that must run serially (while others can continue in other processes).
> Maybe I'm missing a piece of the puzzle her
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
> 1. Should we tweak the docs to show something like the above, that would
> make the solution there easier to just drop in?
>
I don't think so. Locking is a last resort and ruins performance - if used
across your whole test suite you will degrade to *worse than single
process* speed. You should
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi
The search linked from the contributing docs is to:
https://code.djangoproject.com/query?status=!closed=1
If you uncheck the "assigned" flag you'll find those tickets that have not
been claimed by anyone.
That said, often tickets are claimed by people, by assigning them to
themselves, but
>
> To avoid the problems with the bad interaction with the request machinery,
> another approach that came to mind would be to allow inserting / including
> a function at any point in the URLconf. The function would return whether
> the pattern should be skipped or claimed. That would have the
>
> That said, I think doing this in process_response would be preferable over
> doing it in process_request so the extra checks when the URL is valid (the
> common case) are reduced. Resolving URLs can take a bit, especially when
> the urlconf is long and as such I'd like to get that check out of
I don't think Django should change here. The current APPEND_SLASH behaviour
is conservative and expected. Django can't tell the difference between a
catch-all view that "shouldn't really catch the URL", and any other view.
Notably your suggestion would undo the work in django 3.2 to add a
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi Taylor
FYI Disney have already made a snowflake backend - they were asking about
open sourcing it in this thread:
https://groups.google.com/g/django-developers/c/po9dS-2h4lg/m/Qa8H2h_6AwAJ
. You might want to get in touch with them.
Otherwise, if you wanted this developed, it would probably
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Hi
This seems like a genuine bug, Django should not assume that all backends
have the same max table name length. Please file a ticket.
You can workaround this right now by defining db_table on your model. You
might need two model classes, sharing details via inheritance, for the
different
Hi
Check out the wiki page:
https://code.djangoproject.com/wiki/SummerOfCode2021
Adam
On Fri, 9 Apr 2021 at 05:05, fake man wrote:
> Hello there ,
> can u please tell me what is a good idea or proposal for GSOC 2021
>
> thanks
>
> --
> You received this message because you are subscribed to
Okay fair enough, it wouldn't be much work to ship a PositiveBigAutoField
class.
On Wed, 7 Apr 2021 at 08:29, Florian Apolloner
wrote:
> On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:
>
>> I also don't think this is necessary any more and can be closed.
>>
Hi Pratham,
Sorry to be a bit of a downer here...
The django-amp-tools project is not an official django project and has not
been updated for a while (it doesn't support *any* currently supported
Django versions). It's also not particularly popular - 65 stars - and in
general I feel like AMP is
I also don't think this is necessary any more and can be closed.
> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine
> to be honest, for those that need it.
I also would like to meet the django app that *does* need it (for non-silly
reasons like deciding to start ID's
Hi Uri
It depends on someone making the change. It looks like Ryan Cheley assigned
it to themselves but hasn't made a PR. Perhaps you could?
Thanks,
Adam
On Tue, 6 Apr 2021 at 11:17, אורי wrote:
> Hi,
>
> https://code.djangoproject.com/ticket/31937
>
> Any chance this will be fixed
I agree. The time has come to remove it as it offers little protection, and
it's easy to add back if you have the requirement.
Two more data points: securityheaders.com no longer gives you points for
setting the header, and caniuse.com data (
https://caniuse.com/mdn-http_headers_x-xss-protection
Great, thanks Tim.
On Mon, 5 Apr 2021 at 13:28, Tim Graham wrote:
> This was fixed a week ago (will be in Django 4.0).
> https://code.djangoproject.com/ticket/29127
>
> On Monday, April 5, 2021 at 5:18:45 AM UTC-4 Adam Johnson wrote:
>
>> Please don't report bugs here but
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Please don't report bugs here but to the ticket tracker. If you're not sure
there's a bug, django-users, the forum, or IRC are the recommended venues.
That said, I cannot reproduce your problem. Using django's main branch, I
started a new project with a tests.py file using your exact content and
>
> For exemple, if a user changes language at subdomain.exemple.com/whatever,
> by sending a POST request to exemple.com/i18n/setlang, it will be
> redirected to exemple.com/.
Why would you not use subdomain.example.com/i18n/setlang to change the
user's language? That seems like it would work.
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking to work
Welcome Raj,
Have you had a look at the GSoC wiki page?
https://code.djangoproject.com/wiki/SummerOfCode2021 . Do you have any
ideas what you'd like to work on?
I'll also paste below my normal reply for anyone seeking to contribute.
Thanks,
Adam
--
There are many different ways to contribute
Great work Warren and co! I see you already have a number of stars on
GitHub.
A promotional blog post could help get the word out as well. If you do
write one, submit your blog's Django-specific feed to "Community blog
posts" on https://www.djangoproject.com/community/ and it will get picked
up
rt SECURITY_HEADERS
>> SECURITY_HEADERS['REFERRER_POLICY'] = '...'
>>
>> If users redefine the entire dictionary, then adding new SECURITY_HEADERS
>> options in future Django versions will require something like
>> "get_security_header()" since we won't be able t
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Python 3.5 added http.HTTPStatus:
https://docs.python.org/3.9/library/http.html#http.HTTPStatus , so I don't
see a need for such constants in Django, unless they add something extra.
Perhaps you could deprecate from DRF.
On Tue, 23 Mar 2021 at 15:18, Carlton Gibson
wrote:
> Hiya.
>
> Maybe my
Would James' suggestion of reusing the result cache in __repr__ have solved
your issue? I would like to see that first.
I'm not against the DEBUG-only fetching but there hasn't been any
suggestion what to show instead that could be of use.
One can also mitigate against bad queries particularly
Use the modulo operator
In [1]: 4.5 % 1.5
Out[1]: 0.0
https://en.wikipedia.org/wiki/Modulo_operation
https://docs.python.org/3/reference/expressions.html?highlight=modulo#binary-arithmetic-operations
On Sun, 21 Mar 2021 at 23:47, Jacob Rief wrote:
> Say, you have a value and step, both are
I agree that it makes sense to add the argument to FloatField so we can add
the server-side validation logic. I would also like to see it on
IntegerField for consistency, and since IntegerField also maps to a
NumberInput.
I'd also be against the widget_attributes proposal - there are already too
picked up by the main thread:
https://code.djangoproject.com/ticket/32558
On Sat, 31 Oct 2020 at 08:22, Carlton Gibson
wrote:
>
>
> On 30 Oct 2020, at 17:29, Adam Johnson wrote:
>
> Focussing only on the asyncio case may be counter productive. They are
> warnings by default and i
>
> because I think the number of tests inside a PR is small enough that you
> probably do not see isolation failures, but you really want to see progress
> in a PR without random failures due to isolation.
>
I think it's the opposite - most isolation problems are best detected at
the time
Hi Arisophy
I am interested in seeing composite PK's land in Django - I recently made a
composite PK table for a client with a hack to make it work on Django. I'm
sure others are interested too - I just guess at this point there is not so
much momentum on the topic since it's so long running with
+1 for deprecating.
> Yes, it can be reduced to a `user_passes_test` call, but that's more
> verbose for a limited gain (given that this convenience method already
> exists, is tested, etc).
>
I don't see this as an argument not to deprecate staff_member_required,
since the verbosity of
Welcome Vikky,
Have you had a look at the GSoC wiki page?
https://code.djangoproject.com/wiki/SummerOfCode2021 . Do you have any
ideas what you'd like to work on?
I'll also paste below the normal text for anyone seeking to contribute.
Thanks,
Adam
--
There are many different ways to
Hi Ananth
I responded in the other thread you started:
https://groups.google.com/g/django-developers/c/EEij1pzCVD8/m/FkWfc9iHAQAJ
As far as GSoC goes we have limited slots and successful candidates have
often made some contributions to Django or a similar project before, even
if small. If you
Hi Anath,
Did you see the Wiki page on GSoC?
https://code.djangoproject.com/wiki/SummerOfCode2021
Let us know if you have any specific questions after reading that, and the
below links I send to everyone who asks about contributing!
Thanks,
Adam
---
There are many different ways to
Hi Adarsh,
Did you see the Wiki page on GSoC?
https://code.djangoproject.com/wiki/SummerOfCode2021
Let us know if you have any specific questions after reading that, and the
below links I send to everyone who asks about contributing!
Thanks,
Adam
---
There are many different ways to
Hi Khushi
The wiki page has much information, including many potential projects:
https://code.djangoproject.com/wiki/SummerOfCode2021
Thanks,
Adam
On Sat, 13 Mar 2021 at 09:12, Khushi Kaushal
wrote:
> Hello!
> I will be participating in Google Summer of code. I wanted to ask about
> the
This would be something I'd really like to see. Also it would be nice to
make it the default.
I suggest we add the flag as "--random" taking an integer that is the seed,
or 0 to disable.
Do check out my project pytest-randomly for a battle-tested project
randomly shuffling tests.
One thing
I re-submitted my proposal through the "contact the foundation" form (
https://www.djangoproject.com/contact/foundation/ ) since that is the only
way I know of contacting the board.
On Mon, 8 Mar 2021 at 08:09, Florian Apolloner
wrote:
> Mhm, I expected such an answer when I hit send :) I maybe
admin_view does extra stuff like calling the admin site's get_permission
method and using the admin login page rather than the default auth one:
https://github.com/django/django/blob/98d3fd61026457a435ef5b7afce6b6e64e9f241d/django/contrib/admin/sites.py#L198
It should indeed be used only for
I thought of this, but I also wanted to have the discussion out in the open
before the decision that it’s a use of the trademark we want to stop. I
guess we don’t have any other place for such a discussion?
On Mon, 8 Mar 2021 at 00:05, James Bennett wrote:
> Any time this happens, just notify
It has been brought to my attention[1] that running 'npm init django
' works.
This is due to the existence of a package called create-django on npm (
https://www.npmjs.com/package/create-django ). This package is 17 days old
at time of writing. It starts a Python virtualenv, installs Django, and
I also think this is feature creep and if it's a complicated change it's
not worth it.
On Thu, 4 Mar 2021 at 18:36, Tim Graham wrote:
> I'd like to see what your code looks like so far. Personally, this is
> sounding a lot more complicated than I imagined when I accepted the ticket.
> I doubt
I receive an average of one academic survey a week. I think it's a terrible
shame that computer science academia has descended to the same level as the
worst spammers, scraping emails and sending them unsolicited "research"
emails, without a mote of personal thought/engagement.
On Tue, 2 Mar 2021
Click the "GitHub Login" button at the top of the ticket tracker pages to
create an account
[image: Screenshot 2021-03-01 at 19.16.51.png]
Do read the "first patch" tutorial:
https://docs.djangoproject.com/en/dev/intro/contributing/
On Mon, 1 Mar 2021 at 18:54, Mhd Ali wrote:
> Hello, this
Hi Cammil
For small changes it's fine to just open a PR. For larger changes I often
open a ticket with the suggested change, and then maybe a PR to go along to
show what it would look like.
Do check out the Contributing Guide:
https://docs.djangoproject.com/en/stable/internals/contributing/
And
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. Our
Contributing Guide can help you get started with many of these:
https://docs.djangoproject.com/en/stable/internals/contributing/
If you’re looking to work
Welcome!
There are many different ways to contribute to Django - the forum,
blogging, translating, documenting, writing code, and more. As Harouna
pointsout, our Contributing Guide can help you get started with many of
these: https://docs.djangoproject.com/en/stable/internals/contributing/
If
Hi!
I think you've found the wrong mailing list for this post. This mailing
list is for discussing the development of Django itself, not for support
using Django. This means the discussions of bugs and features in Django
itself, rather than in your code using it. People on this list are unlikely
Yes, let's do it. I did it to my open source projects a couple weeks ago
and everything has been smooth since. We'll need some find/replace for
links in the main repo, on djangoproject.com, and I imagine some other
places.
On Tue, 23 Feb 2021 at 22:15, Kenneth wrote:
> I agree. We should go
201 - 300 of 1085 matches
Mail list logo
