Proposal: deprecate and remove django.contrib.comments

[Jacob Kaplan-Moss]

Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.

My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and have much better features (spam prevents,
moderation, etc.). If you want something complex and specific, on the
other hand, you're better off writing something from scratch.

Practically, I'd do this by deprecating `django.contrib.comments` in
1.6. We'd immediately stop making any changes to it (except for
security or data loss issues). It'd stay deprecated in 1.7, and would
be removed in 1.8.

If someone volunteers to maintain it as an external project I'll move
the code to a new repo and direct people there in the docs. If nobody
volunteers, then it'll go to the great /dev/null in the sky.

Any objections?

Jacob

[Carl Meyer]

On 03/07/2013 09:48 AM, Jacob Kaplan-Moss wrote:
> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.
>
> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.

+1

Carl

[Mikhail Korobov]

A good idea, +1.

четверг, 7 марта 2013 г., 22:48:11 UTC+6 пользователь Jacob Kaplan-Moss написал:

[Aymeric Augustin]

On 7 mars 2013, at 17:48, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:

> This one's simple: I'd like to deprecate `django.contrib.comments`,
> scheduling it to be removed in a couple of releases.

+1

> My rationale is this: if you don't really care much about how comments
> work but just want something easy, then Disqus (and its competitors)
> are easier to use and have much better features (spam prevents,
> moderation, etc.). If you want something complex and specific, on the
> other hand, you're better off writing something from scratch.

The mere existence of django.contrib.comments implies that it's the
sanctioned way to add comments to a Django application, but in 2013
it's most likely not going to be the right answer. Leaving it in contrib
is a disservice to many developers using Django.

Even www.djangoproject.com stopped using d.c.comments in 2009.

> If someone volunteers to maintain it as an external project I'll move
> the code to a new repo and direct people there in the docs. If nobody
> volunteers, then it'll go to the great /dev/null in the sky.

Even if no one volunteers to maintain it, I'd still consider putting it on
life support somewhere under github.com/django. The goal is to
provide an easier upgrade path for maintainers of websites currently
using it.

Otherwise we'll have people stuck at the last version of Django that
still contains d.c.comments.

--
Aymeric.

[Donald Stufft]

> --
> You received this message because you are subscribed to the Google Groups "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
> To post to this group, send email to django-d...@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

+1

[Carlos Aguilar]

I think i can maintain comments if you want the time you need.

I only use few zinnia blogs, then, is not really important to me, but I suppose it is important for many others developers.

Best Regards

--
You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Carlos Aguilar
Consultor Hardware y Software
DWD&Solutions
http://www.dwdandsolutions.com

http://www.houseofsysadmin.com
Cel: +50378735118

USA: (301) 337-8541

[Alex Gaynor]

Jumpin' on the +1 train.

Choo, choo!

Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero

[Luke Granger-Brown]

+1 from me too - I've only tried using django.contrib.comments once, and it ended up not being what I needed anyway, so I had to write my own comments module (Disqus was out of the question)

[Alex Ogier]

I think it can't just disappear. Even if you can't find a maintainer, core should put at least a little effort to make sure that an API compatible third-party application exists that is compatible at least through version 1.8 when "import django.contrib.comments" stops working (basically, do the work ourselves to make sure that it doesn't rely on undocumented internals and can be cleanly split). Then, if it's not maintained, it can fester and stop being compatible with new Django versions or whatever. If it's really not important enough to anyone that it can stay modern outside of core, then it will die, but we should make it a trivial matter to fork and adopt for whoever needs it.

Anyways, +1 from me.

Best,

Alex Ogier

[Javier Guerra Giraldez]

On Thu, Mar 7, 2013 at 12:41 PM, Luke Granger-Brown <luk...@lukegb.com> wrote:

> I've only tried using django.contrib.comments once, and it ended up not
> being what I needed anyway, so I had to write my own comments module (Disqus
> was out of the question)

i had exactly the same experience.

--
Javier

[Russell Keith-Magee]

+1 to trimming comments from contrib.

However, I'd argue against using /dev/null as a disposal mechanism. I don't think the code should ever completely disappear. If someone offers to take over, that's great; but just because nobody volunteers to maintain the project, doesn't mean nobody is using the code. 

Keeping the code in our repo with a big "DEPRECATED - THIS CODE IS NOT MAINTAINED" warning in the README (or maybe even a new "django-attic" repository) means the code can live on. If someone wants to use it, they can. If someone needs to make a minor tweak, they can fork the repo and make that change without needing to commit to maintaining the project publicly. 

Yours,

Russ Magee %-)

[Michael Manfre]

On Thursday, March 7, 2013 1:05:53 PM UTC-5, Alex Ogier wrote:

I think it can't just disappear. Even if you can't find a maintainer, core should put at least a little effort to make sure that an API compatible third-party application exists that is compatible at least through version 1.8 when "import django.contrib.comments" stops working (basically, do the work ourselves to make sure that it doesn't rely on undocumented internals and can be cleanly split). Then, if it's not maintained, it can fester and stop being compatible with new Django versions or whatever. If it's really not important enough to anyone that it can stay modern outside of core, then it will die, but we should make it a trivial matter to fork and adopt for whoever needs it.

This approach sounds a lot better than just booting it from the repo.

Regards,

Michael Manfre

[Alex Gaynor]

It's not like /dev/null'ing it erases it from the annals of history. I don't see what the point of creating an un-maintained repo is, if someone decides they want to maintain it at some later point it's pretty trivial to resurrect from VCS history.

Alex

--

You received this message because you are subscribed to the Google Groups "Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

[Jacob Kaplan-Moss]

On Thu, Mar 7, 2013 at 5:55 PM, Russell Keith-Magee
<rus...@keith-magee.com> wrote:
> However, I'd argue against using /dev/null as a disposal mechanism. I don't
> think the code should ever completely disappear. If someone offers to take
> over, that's great; but just because nobody volunteers to maintain the
> project, doesn't mean nobody is using the code.

Yeah, that part was hyperbolic. I'll put it somewhere
(github.com/django/django-uncontrib-comments :) and invite anyone who
wants to maintain it to take it over.

Jacob

[Babatunde Akinyanmi]

+1

Sent from my Windows Phone
From: Jacob Kaplan-Moss
Sent: 3/7/2013 5:48 PM
To: django-developers
Subject: Proposal: deprecate and remove django.contrib.comments

Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases.

My rationale is this: if you don't really care much about how comments
work but just want something easy, then Disqus (and its competitors)
are easier to use and have much better features (spam prevents,
moderation, etc.). If you want something complex and specific, on the
other hand, you're better off writing something from scratch.

Practically, I'd do this by deprecating `django.contrib.comments` in
1.6. We'd immediately stop making any changes to it (except for
security or data loss issues). It'd stay deprecated in 1.7, and would
be removed in 1.8.

If someone volunteers to maintain it as an external project I'll move
the code to a new repo and direct people there in the docs. If nobody
volunteers, then it'll go to the great /dev/null in the sky.

Any objections?

Jacob

[shacker]

Sorry, but -1 from me.

Given the core premise that the job of a web application framework is to find the common features that many websites need to implement and make them easy to achieve, commenting definitely fits into this category. 

I run two sites that use Django comments heavily. Django comments were easy to implement, and  work very well (though a layer of spam protection would be nice), and I have no desire to migrate years of historical comments to a 3rd party system, or to write my own system (given the choice, I would write my own).

Yes, I could handle having comments moved out of core as long as they were maintained somewhere "official," but I don't quite see the necessity. Commenting is a feature that most sites need, so commenting seems like something that Django should provide. That's part of what "using a kick-ass framework" means to me. 

My .02,

./s

[Richard Bronosky]

Yes. Aymeric, you covered every point I wanted to make.

Sent from my Samsung Galaxy S3 using the Swype software keyboard.
--Richard Bronosky

[Richard Bronosky]

Django should have a boneyard. Here is the homebrew boneyard
https://github.com/Homebrew/homebrew-boneyard

Sent from my Samsung Galaxy S3 using the Swype software keyboard.
--Richard Bronosky

[Thiago Avelino]

+1

Cheers,
Thiago Avelino

[Val Neekman]

Yep. +1


Val
Sent from my mobile device.

[Adrian Holovaty]

Late to the party, but +1 from me.

Adrian

[Thejaswi Puthraya]

On Thursday, March 7, 2013 10:18:11 PM UTC+5:30, Jacob Kaplan-Moss wrote:

Hi folks --

This one's simple: I'd like to deprecate `django.contrib.comments`,
scheduling it to be removed in a couple of releases. 

 

[snipped]

 

Any objections?

As the student (back then) who worked on Jacob's code, I too have no objections and support the move to deprecate comments and translocate it into a separate repo.

On a related note, can we also move a lot of the other contrib apps (except for auth and contentypes) into the separate repo?

 

Jacob