On Aug 26, 9:44 am, "Yuri Baburov" <[EMAIL PROTECTED]> wrote:
> > That being said if you could point me to the patch (if it exists) so
> > that I can try to help get it going again in or just lend another pair
> > of eyes that would be really useful. If not, and if the admin isn't in
> > too much
On 8/26/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> And after we checked in an updated tutorial with admonitions
> explaining the exact source of the error for those who run into it, we
> *still* got someone opening a ticket telling us the tutorial needs to
> use "maxlength" instead of "max_l
On 8/26/07, Simon Greenhill <[EMAIL PROTECTED]> wrote:
> There are two tickets outstanding for a similar issue -
>
> #528 (add a local PDF/HTML docs generator)
> #4940 (have downloadable PDF versions of the docs).
>
> Please feel free to get stuck into implementing these :-) If we could
> provide
I did some work on a new patch for http://code.djangoproject.com/ticket/3583
in the weekend.
What it does is refactor the existing apache auth method (which uses
basic HTTP auth) and add a new method which uses the contrib.auth
authentication.
The patch is ready for checkin (in my opinion) but I
I've had very positive reports from users of my Django Docs app
(http://smileychris.tactful.co.nz/ramblings/django-documentation/).
Do the core developers think this something that would be worth
including as part of the core admin app?
--~--~-~--~~~---~--~~
You
On Aug 26, 4:19 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> How about if we just go back to "maxlength" for even the SVN tutorial,
> and hold off changing the tutorial until the latest available release
> of Django includes support for it?
Reverting trunk documentation due to stupidity is ju
2007/8/26, James Bennett <[EMAIL PROTECTED]>:
>
> On 8/26/07, David Larlet <[EMAIL PROTECTED]> wrote:
> > I agree that users do not try to read the local docs for the moment,
> > but maybe it's because the ReST style discourage them to do so. Let's
> > try to add html doc with the djangoproject's
In that case, I will start snooping around the admin contrib and see
if I am up for improving the selection and ordering. I will probably
wait until the new queryset code drops to do anything large so that I
don't work on something that's already been fixed.
On Aug 25, 8:44 pm, "Yuri Baburov" <[
On 8/26/07, David Larlet <[EMAIL PROTECTED]> wrote:
> I agree that users do not try to read the local docs for the moment,
> but maybe it's because the ReST style discourage them to do so. Let's
> try to add html doc with the djangoproject's css and maybe more users
> will use local docs. A lot of
Matt McClanahan a écrit :
> Between max_length and the earlier version of the same confusion
> (__str__ to __unicode__), I wonder if it's time to make the default /
> documentation/ refer to the latest release, rather than trunk.
+1
For newcomers, I think it would be a wise decision. We are use
On Sun, Aug 26, 2007 at 04:47:28AM -0500, James Bennett wrote:
>
> On 8/26/07, Sandro Dentella <[EMAIL PROTECTED]> wrote:
> > While I completely agree on what you say, I'd point out that not only
> > differences from 0.96 to trunk should be noted, if possible, but also
> > between svn versions fo
2007/8/26, Simon Greenhill <[EMAIL PROTECTED]>:
>
> On Aug 26, 9:56 pm, "David Larlet" <[EMAIL PROTECTED]> wrote:
> > I agree that users do not try to read the local docs for the moment,
> > but maybe it's because the ReST style discourage them to do so. Let's
> > try to add html doc with the djan
On Aug 26, 9:56 pm, "David Larlet" <[EMAIL PROTECTED]> wrote:
> I agree that users do not try to read the local docs for the moment,
> but maybe it's because the ReST style discourage them to do so. Let's
> try to add html doc with the djangoproject's css and maybe more users
> will use local docs
2007/8/26, James Bennett <[EMAIL PROTECTED]>:
>
> On 8/26/07, Nicola Larosa <[EMAIL PROTECTED]> wrote:
> > They shouldn't have to go the web site: the release docs should be on their
> > disk, within the installed release itself (see my other message).
>
> See above. I'm sure you mean well, but th
On 8/26/07, Sandro Dentella <[EMAIL PROTECTED]> wrote:
> While I completely agree on what you say, I'd point out that not only
> differences from 0.96 to trunk should be noted, if possible, but also
> between svn versions following latest release. As an example when
> test.clinet.login changed I'v
> Our philosophy so far has been that documentation improvements are
> something that *all* current Django users should benefit from,
> including users of trunk *and* users of the latest release. If we find
> typos, or we take the time to write up better explanations of things,
> we want to have t
Evenin' all.
Could we not just make the warning at the top of each docs page a
little bit more obnoxious? Currently we have the following at the top
of each docs page:
"""
These examples are from Django's SVN release, which can be
significantly different than previous releases. Get old examples
On 8/26/07, Nicola Larosa <[EMAIL PROTECTED]> wrote:
> Only if you make it so, and you shouldn't. :-)
So do you have a means of pushing out updated docs to everyone who's
downloaded a tarball, every time we make a change that's not related
to documenting a change in Django itself?
> It does not
On Sun, 2007-08-26 at 10:27 +0200, Nicola Larosa wrote:
> Adrian Holovaty wrote:
[...]
> > But the problem isn't with the documentation improvements, of course --
> > those don't confuse people (we hope!). The problem is with the parts of
> > the documentation that are specific to the Django devel
> Nicola Larosa wrote:
>> include the documentation in the frigging release, and make it usable!
Malcolm Tredinnick wrote:
> You've completely misunderstood the question.
I don't think so, but thanks for your gentle remark. ;-P
Rather, I skipped saying why I think it's not a worthy goal; I now
Adrian Holovaty wrote:
> There are two types of documentation changes: general improvements (bug
> fixes, typo corrections, better explanations) and documentation of
> new/changed features in trunk. The tension between those changes is the
> issue here.
Only if you make it so, and you shouldn't.
On Sun, 2007-08-26 at 09:35 +0200, Nicola Larosa wrote:
> Adrian Holovaty wrote:
> > Is there any other, better way to do it than how it's currently being
> > done? It's an imperfect system, but it's "more perfect" than the other
> > choice that comes to mind.
>
> Yes, there is a better way to ge
Adrian Holovaty wrote:
> Is there any other, better way to do it than how it's currently being
> done? It's an imperfect system, but it's "more perfect" than the other
> choice that comes to mind.
Yes, there is a better way to get the right documentation in the hands of
those who use a release:
23 matches
Mail list logo
