Re: Can we move the activity on this list to the Forum now?

2023-05-06 Thread Carlton Gibson
Hey Curtis.

The notifications settings are very flexible, and allow good filtering (to
your inbox) if that's how you want them.

For example, I'm able to get notifications for the Django Internals
category, and the Async subcategory of Using Django (and then I'm able to
keep up with the rest just by glancing at the latest tab.)

The water is nice  😅
C.


On Thu, 4 May 2023 at 07:29, Curtis Maloney  wrote:

> Does the Forum allow me to get email notifications / summaries?
>
> If not, it will mean I disconnect with that part of the community.
>
> --
> Curtis
>
> On Thu, 4 May 2023, at 15:19, Arthur Rio wrote:
>
> Yes please!
>
>
>
> On May 3, 2023 at 11:19:12 PM, jure.erznoz...@gmail.com (
> jure.erznoz...@gmail.com) wrote:
>
>
> +1
>
>
>
> *From:* django-developers@googlegroups.com <
> django-developers@googlegroups.com> *On Behalf Of *natali...@gmail.com
> *Sent:* sreda, 03. maj 2023 20:10
> *To:* Django developers (Contributions to Django itself) <
> django-developers@googlegroups.com>
> *Subject:* Re: Can we move the activity on this list to the Forum now?
>
>
>
> Hello everyone!
>
>
>
> I was wondering if we could make a decision about this topic. On the one
> hand, and as far as I understand, the forum is the preferred channel of
> communication. On the other hand, having multiple channels of communication
> can spread important discussions too thin, making it difficult to have
> productive conversations in one place.
>
>
>
> As a newcomer to the contributing community, I can attest that the current
> situation causes some confusion. IMHO, the same applies to the chat
> options: there is IRC and the Discord server (though perhaps I should start
> a new forum topic about that in order to keep decisions separated).
>
>
>
> In summary, I'm +1 to "move on-mass (all few of us :) over there"!
>
>
>
> Thank you!
>
> Natalia.
>
> On Thursday, January 26, 2023 at 10:07:36 AM UTC-3 Alex Krupp wrote:
>
> I just submitted a proposal to create a Discourse plugin to improve the
> accuracy of their inbound email parsing. This would enable two things:
>
>- Folks who prefer to live in their inbox could continue to do so and
>contribute by just replying to emails. Discourse currently has
>reply-by-email, but it often mangles formatting and/or entirely deletes
>text. Once these issues are fixed, folks who like the current experience
>would be able to just pretend the forum doesn't exist and continue having
>the same experience as they currently have with Google Groups.
>- Right now importing the archives from Google Groups into Discourse
>isn't realistic for the same reasons; some messages will import correctly,
>but others will be mangled or missing text. This would also be made
>possible.
>
> If this is something you care about (positively or negatively), here is
> the exploratory proposal:
>
>
>
>
> https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944
>
>
>
> Any feedback and/or testing would be much appreciated! Right now Discourse
> recognizes that this is a problem and is interested in solving it, but
> getting it prioritized will require folks to A) speak up saying they want
> it done B) test the underlying API to verify that it actually solves the
> problem.
>
>
>
> Alex
>
>
>
> On Fri, Jan 20, 2023 at 2:24 AM Carlton Gibson 
> wrote:
>
> OK, I've updated the Trac wiki page to point to the forum too. (We use
> this as a wiki-link in responses to guide folk onwards.)
>
>
>
> The docs have a `|django-developers|` shortcut used in quite a few places
> so that needs a moment more to review and adjust.
>
> (I'll look at it soon-ish... — if no-one beats me to it :)
>
>
>
> Thanks.
>
> C
>
>
>
> On Thu, 19 Jan 2023 at 18:15, Andrew Godwin  wrote:
>
> 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 people here from Trac and the
> Triage Workflow docs — so if there's a rough "Yeah, let's do it" we can
> adjust practice there.
>
>
>
> I expect there will always be the "How do I start?" posts. The Forum at
> least has a pinned post for that. ...
>
>
>
> On Thu, 19 Jan 2023 at 01:04, 'Kye Russell' via Django developers
> (Contributions to Django itself)  wrote:
>
> Hi all,
>
>
>
> I find that the signal-to-noise ratio on this mailing list is (by my
> determination) quite bad around this time of year.
>
>
>
> Is a move to the forum still on the cards?
>
>
>
> Kye
>
> On 6 Dec 2022 at 7:16 AM +0800, Andrew Godwin ,
> wrote:
>
>
>
> I did some investigation of moving django-users and django-developers to
> the Forum right after DjangoCon; I wanted to see if we could import all the
> old posts too, which we probably could, but I'm not entirely sure of the
> utility of that.
>
>
>
> I will say that the for

Re: Deprecate CICharField, CIEmailField, CITextField

2023-05-06 Thread 'Johannes Maron' via Django developers (Contributions to Django itself)
Hello again,

I trust Mariusz' assessment regarding the maintainability. In that case, I
presume a separate package from a 3rd party with commercial interest might
be the best option going forward.

Thanks for all the considerations and explanations.

Cheers!
Joe

On Wed, Apr 19, 2023 at 3:48 PM fly.a...@gmail.com 
wrote:

> Hey everyone!
>
> Thanks for the discussion.
> And special thanks @Adam, for the great article, helped us with the
> migration.
>
> What I am struggling now with is whenever I specify
> `db_collation="case_insensitive"` on the field and this field is used in
> `ModelAdmin.search_fields` - Django simply breaks (as it by default uses
> `icontains` lookup).
> That is quite unfortunate for the big projects, as I have to come up with
> some generic solution to something that was not broken before this feature
> deprecation (and the docs does not mention this case).
> Good that Adam covered it in the article, but I feel that this could be
> handled on a lower level than right now. Currently, we'd need to write a
> manual annotation for admin queryset in almost every project that uses
> usernames or emails (which my guess is something you'd want to be
> case-insensitive on a database level).
>
> I wonder how we could move forward (in case reverting this is not an
> option) and reduce overall aftermath stress.
> For example, in terms of documentation, we could add a note on
> `db_collation` to `icontains` page:
> https://docs.djangoproject.com/en/4.2/ref/models/querysets/#icontains
>
> But I also feel that might not be enough.
>
> Best,
> Rust
>
>
> On Tuesday, 18 April 2023 at 09:52:20 UTC+2 Johannes Maron wrote:
>
>> Thanks Adam,
>>
>> of course I read your well-written article before diving into this topic,
>> thanks for sharing.
>>
>> However, I don't agree about the index. The best solution is using the
>> CITEXT db type, which is very much alive.
>> Should Django to deprecate support for the db type, a 3rd party package
>> seems the bast choice for me.
>> With the downside of me having to maintain yet another package. But I can
>> understand if the Django project has no interest in maintenance.
>>
>> In any event, I opened a ticket:
>> https://code.djangoproject.com/ticket/34501
>>
>> Best Joe
>>
>>
>> On Fri, Apr 14, 2023 at 11:36 AM 'Adam Johnson' via Django developers
>> (Contributions to Django itself)  wrote:
>>
>>> Just to note, for anyone that finds it useful, that I wrote a blog post
>>> on migrating to collations:
>>> https://adamj.eu/tech/2023/02/23/migrate-django-postgresql-ci-fields-case-insensitive-collation/
>>>
>>> But yes, I have also been thinking like Tom that indexing UPPER("email")
>>> seems to be the path of least complexity...
>>>
>>> On Thu, Apr 13, 2023 at 8:12 AM Tom Carrick  wrote:
>>>
 Hi,

 I wrote most of the code for collation support, and I also argued
 (softly) against deprecating citext support for the reasons you stated.

 However, I've changed my mind on this now. As you can't index the
 citext column for LIKE queries, doing these types of searches on any real
 amount of data is going to be too slow in most cases. I actually think the
 best practice right now for having searchable case-insensitive emails is to
 do it old-school - have a regular EmailField with an index on
 UPPER("email") and then make sure you always use iexact, istartswith etc.
 and this will properly use the indexes and result in a faster search.

 So I see very few advantages now to keeping CITEXT at all, and they're
 quite easy to add as a third party package as Mariusz suggested if anyone
 is so inclined.

 Cheers,
 Tom

 On Wed, 12 Apr 2023 at 12:09, Mariusz Felisiak 
 wrote:

> Hi
>
> > Unless we want to drop support for the CITEXT extension, ...
>
> What do you mean by that? As far as I'm now, we don't do anything
> special to support CITEXT extension 🤔.
>
> > I'd caution to revert the deprecation and keep support ...
>
> I'm obviously biased as the author of this proposition and patch,
> however, IMO, small differences between using CI fields and collations
> don't justify maintaining 3 additional fields that were mostly untested.
> Also, they are deprecated in a LTS so folks still have *3* more years
> to update their code. In the worst case someone can create 3rd party
> package with them.
>
> Unless something is fundamentally broken I'm against reverting.
>
> Best,
> Mariusz
>
> --
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5c11b704-68c4-490d-84bf-90c734cc02d1n%40go