Swappable Flatpage model

[Vlastimil Zíma]

Hi,

as there is several requests for extension of Flatpage model, it might be 
the easiest solution to make Flatpage model swappable as User model. 
Anybody else for this enhancement?

References
 * Request for markdown support https://code.djangoproject.com/ticket/23743
 * Request for flatpage reusability 
https://code.djangoproject.com/ticket/26762
 * Longer template_name field https://code.djangoproject.com/ticket/18331
 * There are several attempts to support translations in flatpages.

Vlastik

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8dd0bb1c-780e-4806-b3c3-156e803c6fce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Google Summer of Code Updates - Class based indexes

[Jani Tiainen]

Hi,

On 26.07.2016 04:28, akki wrote:


  * Fixed #24442  -
Improved schema's index name creating algorithm
Updated !6898  to take
all column names into account while creating index name

  * Add support for column ordering (ASC/DESC) in class based indexes
Somewhat provides the feature requested in #20888

WIP code on my branch -
https://github.com/akki/django/commits/gsoc-indexes-order
Modifying introspection of all databases to return column order as
well (required for testing) -- implementation for Oracle remaining.



If you get stuck with Oracle I can lend a hand to help to figure out the 
details.



  * Implement Hash index class
WIP implementation at
https://github.com/akki/django/commits/gsoc-indexes-hash
Currently implemented only for postgresql because that's the only
backend which fully supports it AFAIK (MySQL supports for some
storage engines but neither for MyISAM nor InnoDB).


On Tuesday, 19 July 2016 10:41:16 UTC+5:30, akki wrote:

  * Introduce Meta.indexes
PR - https://github.com/django/django/pull/6857
.
Ticket - https://code.djangoproject.com/ticket/26808
.
Made a design change so that index can drop it's model
attribute by introducing /Index.set_name_with_model/ method
Wrote some left out tests for /related_dependencies/.

  * Fixed #24442  -
Improve schema's index name creating algorithm
PR  - https://github.com/django/django/pull/6898

Updated according to reviews and suggestions.

  * Resolved bug when unique_together was dropped along with it's
field
PR - https://github.com/django/django/pull/6926
.
Initially wrote a temporary fix (which left out some other
corner cases) to the problem (afterwards I realised the better
fix and sent PR).
Other comments about the issue on the ticket -
https://code.djangoproject.com/ticket/26180
.
Resolved a similar issue that had crept up for Meta.indexes -
updated !6857 
accordingly.

On Tuesday, 12 July 2016 14:17:21 UTC+5:30, akki wrote:

  * Restructure index migrations - Polished according to all
reviews, the PR
 has been merged.
  * Introduce Meta.indexes - Updated PR
 according to
suggestions as per reviews.
  * Improve schema's index name creating algorithm - #24442
!6898
.
  * Add support for indexes to inspectdb - This depends on
!6857  so I
will send a PR once indexes are added to Meta class;
Current work on my local branch -
https://github.com/akki/django/commits/gsoc-indexes-inspectdb


On Tuesday, 5 July 2016 11:54:00 UTC+5:30, akki wrote:

  * Restructure index migrations
PR  - https://github.com/django/django/pull/6866

Modified the internal working of migrations/schema
methods related to indexes. This mainly aims at
stabilising the newly added migrations for Indexclass.

  * Introduce Meta.indexes
PR ready for review at
https://github.com/django/django/pull/6857
.
Ticket - https://code.djangoproject.com/ticket/26808



On Tuesday, 28 June 2016 18:44:37 UTC+5:30,
thinkwel...@gmail.com wrote:

Wonderful!  I make heavy use of btree_gin in one of my
projects; will be great to have these new Index classes!

On Monday, June 27, 2016 at 6:51:31 PM UTC-4, Tim
Graham wrote:

Support for more index types is planned. This is
only part 1 of the work. Please see

https://gist.github.com/akki/7fd50505928dac58dc350e6cb186a404


for the timeline

Resolved: wontfix is not productive

[Charlie Hayes]

Ticket https://code.djangoproject.com/ticket/19447 was resolved as wont fix.

Although this PR is insufficient for our needs (we would also need 
localized abbreviations), it would certainly be more useful than the 
nothing that exists now.

How does the Django team know how many developers would use a feature like 
this when said developers never get a chance to use it? Django includes a 
lot of inane features that many fewer developers would use compared to 
this. The documentation for all of Django is already pretty bad (it's 
poorly organized, poorly hyperlinked, uses bad examples, etc, regardless of 
what others say); blocking a PR from acceptance because the documentation 
doesn't measure up to the bar set in practice is illogical.

Practically every site that prints numbers to the screen (read: all sites) 
could benefit from features like this. If the work is incomplete, let 
someone take over or explain what else needs to be implemented before 
acceptance is gained. Closing it as won't fix is irrational and discourages 
the community (and adoption of the framework).

-Charlie

PS: I can't add this as a comment to the ticket because:



-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/163e3b24-aa17-4f82-bc48-3104d3e0d203%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resolved: wontfix is not productive

[Aymeric Augustin]

Hello Charlie,

Glad to meet you!

Trac says I’m the person who closed that ticket two years ago. I don’t remember 
it specifically but hopefully I can give you some context.

When I closed that ticket, it hadn’t received any activity for two years. No 
one had reacted to the last comment which suggested to build the feature 
externally. There was no clear path of action within Django. Seeing that the 
ticket wasn’t getting much attention, if any, and wasn’t likely to go anywhere 
in its current state, I must have spent no more than a few minutes before 
deciding to drop it. The goal was to improve the signal / noise ratio in the 
ticket tracker. When there's over a thousand open tickets, some gardening helps 
keeping things under control, typically to keep it manageable to look for 
duplicates. I may have closed ten or twenty tickets in that session.

A wontfix isn’t absolute, though. If the idea is interesting, it will come up 
again and could be reconsidered. Perhaps this particular idea is interesting. 
If you explain why you disagree with the current conclusions of the ticket — by 
now you must have spent more time thinking about it that I ever did, if you can 
convincingly address the arguments raised in comments — especially those by 
committers, and if the discussion results in a consensus for making changes to 
Django in this area, then you can reopen that ticket or open a new ticket. The 
latter is often more convenient when the original ticket is several years old 
or contains a confusing discussion. You can add a comment in the old ticket 
pointing to the new one and vice-versa.

Django has evolved over more than ten years now and its current goals aren’t 
the same as when it was just open-sourced, or even when it only existed inside 
LWJ. Some features that you call inane are just quite old. They wouldn’t get 
added today; similar features wouldn’t get added either; but this isn’t 
necessarily a sufficient reason for removing them and break projects that use 
them. Sometimes we deprecate features that we consider undesirable but we try 
to do it conservatively.

Thank you for the kind words about Django’s documentation. It’s always a 
pleasure to know that the tens thousands of hours put by thousands of 
volunteers into writing them are appreciated. In fact, Django’s documentation 
is well known for being one of the worst among popular open-source web 
frameworks. This is expected as the Python ecosystem at large simply sucks at 
documentation. In this sad situation, if we want to improve, we have no choice 
but to raise the bar on documentation that gets added. Otherwise we’ll just 
keep digging our hole. Complain about the poor quality of the documentation and 
advocating merging documentation patches regardless of their quality in the 
same sentence doesn’t strike me as logical.

Okay, for the sake of clarity, I hope that:

1. everyone spotted the irony in the previous paragraph
2. you realize that your email wasn’t setting the tone for a constructive 
discussion, but hopefully we can bounce back :-)

So, with regards to this particular ticket, what new arguments can you bring to 
the table and what’s your proposal for moving forwards? Please build upon the 
discussion in the ticket like I explained above. Specifically, please explain 
why this has to live in Django. djangopackages.com  
proves that tons of widely useful features live happily as third-party apps.

Best regards,

-- 
Aymeric.

PS: We know that Trac's antispam isn’t very good but we had to reactivate it 
when spammers figured out how to use GitHub authentication. FYI, when I was 
managing the antispam, the spam / hame ratio was about 1000 : 1, so it isn’t 
exactly easy to configure. If anyone is experienced with Trac’s antispam and 
knows how to tune it, we’re all ears.


> On 26 Jul 2016, at 22:30, Charlie Hayes  wrote:
> 
> Ticket https://code.djangoproject.com/ticket/19447 
>  was resolved as wont fix.
> 
> Although this PR is insufficient for our needs (we would also need localized 
> abbreviations), it would certainly be more useful than the nothing that 
> exists now.
> 
> How does the Django team know how many developers would use a feature like 
> this when said developers never get a chance to use it? Django includes a lot 
> of inane features that many fewer developers would use compared to this. The 
> documentation for all of Django is already pretty bad (it's poorly organized, 
> poorly hyperlinked, uses bad examples, etc, regardless of what others say); 
> blocking a PR from acceptance because the documentation doesn't measure up to 
> the bar set in practice is illogical.
> 
> Practically every site that prints numbers to the screen (read: all sites) 
> could benefit from features like this. If the work is incomplete, let someone 
> take over or explain what else needs to be implemented before acceptance is 
> gained. Closing it as won't f

Re: Resolved: wontfix is not productive

[Daniele Procida]

On Tue, Jul 26, 2016, Charlie Hayes  wrote:

>How does the Django team know how many developers would use a feature like 
>this when said developers never get a chance to use it? Django includes a 
>lot of inane features that many fewer developers would use compared to 
>this. The documentation for all of Django is already pretty bad (it's 
>poorly organized, poorly hyperlinked, uses bad examples, etc, regardless of 
>what others say); blocking a PR from acceptance because the documentation 
>doesn't measure up to the bar set in practice is illogical.

Please don't be rude. 

You'd like the almost entirely unpaid volunteers in the team to listen 
sympathetically to your concerns; don't begin by insulting their work.

Most people think that Django's documenation is exemplary. I don't think you'll 
find anyone who shares your opinion of it. In any case, a great deal of once 
again almost entirely unremunerated effort has gone into it, just like the rest 
of Django.

You may even be right about the need for this feature, but no-one on the team 
is paid enough to deal with people who insult them, so it doesn't matter 
whether you are or not.

>Practically every site that prints numbers to the screen (read: all sites) 
>could benefit from features like this. If the work is incomplete, let 
>someone take over or explain what else needs to be implemented before 
>acceptance is gained. Closing it as won't fix is irrational and discourages 
>the community (and adoption of the framework).

Feel free to reopen the proposal with a clear picture of what you think is 
needed and how you think the need should be met, but be prepared to state the 
case well. And more courteously please. Nobody on the team is obliged to deal 
with the expression of your anger.

Daniele

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20160726211557.1039918318%40mail.wservices.ch.
For more options, visit https://groups.google.com/d/optout.