+1 on deprecating databrowse. Dead code should be excised.
As for webdesign, why not roll the one piece in it (the marginally-useful
lorem tag) into the main library and deprecate the hook in contrib?
-0 on deprecating formtools.
For the sake of argument I could see admindocs being deprecated
>
> +0 on webdesign, since it's functionality that's probably in transient
> use by the more invisible members of our community. If it were more
> fleshed out, I'd say leave it, but since it's just that single
> function, it should probably go eventually.
>
I'd miss it even though it's just a
It depends how surgical this discussion is; if we're at the model
level, then it's pretty clear that we need to reinvent auth.User and
deprecate functionality accordingly.
I'm not hearing anyone say that contrib.auth is an undesired battery
tout court, but the sentiment that it fails to "get out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/20/2011 06:13 AM, ptone wrote:
> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
>
> Talk of reducing contrib has been around a long time.
>
> Per policy,
On 20.09.2011, at 14:13, ptone wrote:
> At DjangoCon.us there was positive reception to Jacob's thoughts that
> Django core could be leaner - people liked the kernel analogy.
>
> Talk of reducing contrib has been around a long time.
>
> Per policy, it takes 3 minor versions to remove something
At DjangoCon.us there was positive reception to Jacob's thoughts that
Django core could be leaner - people liked the kernel analogy.
Talk of reducing contrib has been around a long time.
Per policy, it takes 3 minor versions to remove something from Django
- near as I can tell, a
