The problem we are discussing here is not really a django specific one. The
concerns Adrian pointed out can be easily taken care of by using branches.
In theory the generic documentation enhancement should be applicable to all
releases, but we know its only really applicable to the previous
On 8/26/07, James Bennett <[EMAIL PROTECTED]> wrote:
> I don't think it's really something that'll be voted on, at least not
> in a broad general sense. If releases happened based on people in the
> mailing list saying they want it to happen, we'd be on Django 3000 by
> now ;)
That's not
Oh, and:
[1]:
http://code.djangoproject.com/browser/djangoproject.com/django_website/apps/docs
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
I'm also a lurker on the dev list, so excuse the interruption.
James Bennett wrote:
Thus, the problem to solve here is simple: how do we ensure that
someone who downloads the 0.96 release uses the 0.96 version of the
documentation?
Bundling HTML versions of the docs isn't a solution,
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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.
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:
I know I'm just a lurker, but I'd really like to see a release with
the various bug fixes and such to match up to the documentation.
There's plenty I'd like to use, and yes - I'm one of the many that
reads one and wonders why things don't work that way. I do eventually
figure it out - and not
On 8/25/07, James Bennett <[EMAIL PROTECTED]> wrote:
> So I'd ben tentatively -1 on doing a release, and more interested in
> finding a solution to the documentation problem -- we're going to need
> that solution anyway, or else we're going to end up in hot water every
> time there's something
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_length".
How about if we just go back to "maxlength" for even
On 8/25/07, James Bennett <[EMAIL PROTECTED]> wrote:
>
> So I'd ben tentatively -1 on doing a release, and more interested in
> finding a solution to the documentation problem -- we're going to need
> that solution anyway, or else we're going to end up in hot water every
> time there's something
On 8/25/07, James Bennett <[EMAIL PROTECTED]> wrote:
> The documentation issue is tough, because it really is a RTFM issue:
> all that's needed is some way to make it very clear to users of 0.96
> that they ned to use the 0.96 docs, and I wonder if perhaps changing
> the documentation landing
On 8/25/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> However I don't see any other way to kill the max_length problem. One
> the one hand, the max_length problem is is an RTFM issue - but on the
> other hand, if multiple users keep making the the same error over and
> over again, there
On 8/25/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> Hi guys,
>
> I've been wondering of late if we need to cut a new release. I have a
> few reasons:
>
> 1) Its been six months since the release of 0.96, and we've made some
> good progress since then;
Looking at the wiki, I couldn't
Seems reasonable to me
On Aug 26, 1:21 am, "Russell Keith-Magee" <[EMAIL PROTECTED]>
wrote:
> Hi guys,
>
> I've been wondering of late if we need to cut a new release. I have a
> few reasons:
>
> 1) Its been six months since the release of 0.96, and we've made some
> good progress since then;
>
Hi guys,
I've been wondering of late if we need to cut a new release. I have a
few reasons:
1) Its been six months since the release of 0.96, and we've made some
good progress since then;
2) The current trunk seems to be in pretty good condition, and Malcolm
is about to land a big refactor of
28 matches
Mail list logo
