Re: Admin and Related Models/Fields
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 turmoil I can start implementing something like what Tai Lee > > illustrated. > > Sorry, frustrated because didn't found any suitable patches. It > appears to be very challenging problem. > > Found only two related, but seemingly not complete > patches:http://code.djangoproject.com/ticket/2874http://code.djangoproject.com/ticket/2076 > > Obvious there's some more related tickets without any patches, but > they are worthless. Did you look at #3400? It implements following related fields in the admin 'list_filter' option. I did look at updating this patch again to support 'list_display' but at first glance it wasn't as trivial as I had hoped so I just ended up using something like your 'city_state()' method. That being said, a fresh approach to this might be worthwhile. Cheers, Nick --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Tutorial and max_length (was Re: Time for a new release?)
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_length". Sigh... > 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? I don't normally like to cover for > people who can't be bothered to read *multiple* warnings telling them > not to shoot themselves in the foot, but this is just getting > ridiculous. I can't say I'm wild about this idea. This has the potential to just reverse the problem - people that are trying the SVN version are going to try the tutorial, and start logging bugs about the tutorial being out of date. I think we've just about hit the limit of what we can do here, short of cutting a release. IMHO we've reached the point where we will just have to live with the problem until we cut the next release. Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 a > downloadable "bundle" of docs per version, this could help sort this > problem out FYI, I've started working on a local HTML docs generator, based on #528. It's nothing special, but it'll do. Look for it in the next couple of days. Adrian -- Adrian Holovaty holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Apache cookie based authentication
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'd like some other eyes to look at the patch. The ticket discussion got a bit sidetracked, so don't fret over the comments - just review the patch. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Offline HTML docs?
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 received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Tutorial and max_length (was Re: Time for a new release?)
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 just silly. I say we just keep closing tickets until the next release, at which stage we make the latest release docs the default. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 css and maybe more users > > will use local docs. A lot of people don't even know the rst2html > > command... > > I don't mean "users don't read the docs they got with the download", I > mean "they don't know the docs are in the download". Hang out on IRC > for a while and watch how often people ask "where can I get a copy of > the Django documentation to read offline?" I know, I'm here for months (david`bgk). Of course, this new addition need to be documented. > > > About the release question, before voting can we have an estimation of > > how far the newforms-admin branch is ready for the trunk? (did we > > speak about days or weeks or months?) > > 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 ;) > > Given that one of our much-loved BDFLs (Adrian) seems to be against it > and our release manager (me) seems to be against it, I don't think > there'll be a release just yet... > Make sense (but you didn't answer my questions ;-)). David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Admin and Related Models/Fields
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" <[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 turmoil I can start implementing something like what Tai Lee > > illustrated. > > Sorry, frustrated because didn't found any suitable patches. It > appears to be very challenging problem. > > Found only two related, but seemingly not complete > patches:http://code.djangoproject.com/ticket/2874http://code.djangoproject.com/ticket/2076 > > Obvious there's some more related tickets without any patches, but > they are worthless. > > -- > Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov, > MSN: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 people don't even know the rst2html > command... I don't mean "users don't read the docs they got with the download", I mean "they don't know the docs are in the download". Hang out on IRC for a while and watch how often people ask "where can I get a copy of the Django documentation to read offline?" > About the release question, before voting can we have an estimation of > how far the newforms-admin branch is ready for the trunk? (did we > speak about days or weeks or months?) 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 ;) Given that one of our much-loved BDFLs (Adrian) seems to be against it and our release manager (me) seems to be against it, I don't think there'll be a release just yet... -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 to read the documentation for the current stable version. It's the first time I see a documentation for a svn version. Even if a block announce at the beginning of the page that documentation covers the svn version, I'm not so sure users really read it or take it into account. Maybe the first time but then he/she only wants to get the informaiton he/she searches for. I think that : - stable documentation should be available directly in djangoproject.com/documentation - svn documentation should be available in a different path (like djangoproject.com/documentation/svn) My 2 cents of django newbie, Nicolas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 following latest release. As an example when > > test.clinet.login changed I've been puzzled by the different syntax between > > the docs and te code, no mention in the docs, probably just becouse no > > test.client was present in 0.96 (just guessing). > > We already document changes which break compatibility between releases > (on the wiki because it's easier to keep updated there): > > http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges > > If you're tracking SVN, at the very least you need to watch that page. I know and I read that page regularly. Can I suggest we put an icon in the docs in any places where something that has backword incompatible issues that links to the BackwordIncompatibleChanges page? sandro *:-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 djangoproject's css and maybe more users > > will use local docs. A lot of people don't even know the rst2html > > command... > > 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 a > downloadable "bundle" of docs per version, this could help sort this > problem out > Assuming you've got rst2pdf linked in #4940 and pdftk, you can generate a huge (364 pages!) pdf with those commands: $ for i in $(ls docs); do python rst2pdf.py docs/$i; done $ pdftk docs/*.pdf cat output django_doc.pdf At this point, it could be interesting to decide if we need a specific order, fancy output, etc. David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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. A lot of people don't even know the rst2html > command... 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 a downloadable "bundle" of docs per version, this could help sort this problem out --Simon http://code.djangoproject.com/ticket/528 http://code.djangoproject.com/ticket/4940 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 the experience of seeing people > actually work with Django and its documentation is against you on that > point. > 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 people don't even know the rst2html command... About the release question, before voting can we have an estimation of how far the newforms-admin branch is ready for the trunk? (did we speak about days or weeks or months?) David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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've been puzzled by the different syntax between > the docs and te code, no mention in the docs, probably just becouse no > test.client was present in 0.96 (just guessing). We already document changes which break compatibility between releases (on the wiki because it's easier to keep updated there): http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges If you're tracking SVN, at the very least you need to watch that page. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
> 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 that positive effect on as many users as possible. > Hence, we point people by default at the very latest versions of the > docs, because they have the latest and greatest stuff. > > 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 development > version. Traditionally, we've been marking these with the text "New in > Django development version" -- as long as we remember to do this. This > has worked well, IMHO, except in the case of the recent "max_length" > vs "maxlength" change, in which the documentation *was* uniformly > updated to use "max_length" but didn't actually mention anything about > the fact that it had only changed in trunk! > > I should stress that, if we continue down this path of pointing people > at the trunk documentation by default, all documentation changes that > refer to new trunk features *must* be written in a way that users of > 0.96 will understand the change does not apply to them. We need to do > a better job of telling contributors and documentation writers that > this is how we do things. 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've been puzzled by the different syntax between the docs and te code, no mention in the docs, probably just becouse no test.client was present in 0.96 (just guessing). Even those who try to follow trunk have to stop on a release for a while but being informed on the development of the syntax may also be a real incentive to update. Sometimes just an icon that warns you about diffrences between releases would be sufficent, better would be the link to the explanation. I think in any case that even people that stick to latest stable release should read svn docs: sooner or later they will need to update, better to be aware of new syntax! sandro *:-) PS: A last note related to docs but not really on this specific issue: it'd be nice to have a rss feed on changes in docs. I know it's very easy to make a script to have that using svn diff. I just mean that it's probably a general interest thing. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 here: 0.96, 0.95. """ The current wording suggests that the <0.96 are old and out of date, and they ARE, but no-one's going to want to use the old versions, unless they have to. We now have an admonition in tutorial1 (thanks Adrian), which should kill a lot of these, but I think we can help this if we re-word the note slightly. I suggest something like: """ Warning: These examples are from Django's SVN release (the development version), which can be significantly different to previous releases. Please use the appropriate docs version for your django installation. If you have downloaded the 0.96-release of Django, use . """ -Simon G. On Aug 26, 5:11 pm, "Adrian Holovaty" <[EMAIL PROTECTED]> 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. > > Adrian > > -- > Adrian Holovaty > holovaty.com | djangoproject.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 work. You cannot really get people to use the trunk docs, but > in many places say: "Oh, by the way, this little thing changed, please > refer to the *right* release docs, but do come back when you're done, thank > you." again and again. Which isn't really what anyone's trying, so that's a bit of a red herring. The problem we've been having is people who download the 0.96 release and then try to follow the SVN version of the tutorial. This simply will not work; there is no possibility of "do this part from 0.96 and then come back", because the SVN tutorial is going to use techniques (max_length instead of maxlength, __unicode__ instead of __str__, named URL patterns, etc.) which simply cannot be made to work on 0.96 in any fashion. 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, because (speaking from experience of reading django-users and hanging out on IRC) many users never realize that the documentation is bundled with the download in *any* format (just as many users probably never realize that they get a free copy of "Dive Into Python" on most Debian-based Linux distributions, and so ask where they can find a good Python tutorial online). These are the same users who never find their way to the release-specific docs on the website. Which is why it's been proposed that the default landing page for the documentation should be the version for the latest release of Django, not the SVN docs; this would solve the problem of people downloading the release tarball (or installing a package on a Linux distro -- the distros track releases, not SVN) and ending up at the SVN docs. > 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 the experience of seeing people actually work with Django and its documentation is against you on that point. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 development version. > > It does not work. You cannot really get people to use the trunk docs, but > in many places say: "Oh, by the way, this little thing changed, please > refer to the *right* release docs, but do come back when you're done, thank > you." again and again. > > It's confusing, and annoying: it's not worth it. You've picked only one use-case. On the other hand we also get quite a bit of feedback where people indicate that the improvements to the docs have clarified things for them, so clearly some people are reading the improvements and getting benefit from them, even if they're not using the subversion code. There's a lot more to the docs than just the "new in latest release features". > Come on, you made a release, accept it for what it is, with its code, *and* > its docs. Anyone wanting better code, *or* better docs, should just use the > trunk. That (upgrading to trunk code) isn't always possible, as you know. It's simply not practical to always track the latest subversion code if you have a production product built on one codebase or if there are multiple people working on a project in an organisation. Please accept that people are already using the docs in the way Adrian mentioned (this is clear from the mailing lists and ticket reports). Claims that it doesn't work would seem to be tempered somewhat by the existing evidence. I appreciate your position is that we shouldn't bother, but you need to at least acknowledge it's not a one-sided argument. Malcolm -- I've got a mind like a... a... what's that thing called? http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
> 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 explained why in another message. > Shipping an extra HTML copy of the documentation would be equivalent to > pointing the website copy to the 0.96 release documentation. Not entirely equivalente, but yes, that's what should be done, *after* shipping usable docs with each release. :-) > Adrian explained why he thinks even people using 0.96 should generally > be reading the subversion docs and his logic make a lot of sense. Well, no, actually it's not worth it. > Shipping documentation in the release doesn't mean people magically get > updated documentation when we check fixes into subversion. In this case, you cannot have your cake and eat it too (stupid phrase, as Joe Jackson points out ;-) ). You should not try to make users ping-pong between two different doc sets. Just accept that each release docs are what they are (as code is!), and move along. See my other message for further details. -- Nicola Larosa - http://www.tekNico.net/ Itamar Shtull-Trauring: reactor.stop() is the way to go, yes. Call it when you want the program to start. Nicola Larosa: To be able to do that you would have to recall John and George from heaven, reform the Beatles, pay them a lot to compose "Stop Me Down", and use that as the sound theme. -- April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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. :-) > 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 that positive effect on as many users as possible. Hence, we point > people by default at the very latest versions of the docs, because they > have the latest and greatest stuff. The cost/benefit ratio is not there. > 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 development version. It does not work. You cannot really get people to use the trunk docs, but in many places say: "Oh, by the way, this little thing changed, please refer to the *right* release docs, but do come back when you're done, thank you." again and again. It's confusing, and annoying: it's not worth it. Come on, you made a release, accept it for what it is, with its code, *and* its docs. Anyone wanting better code, *or* better docs, should just use the trunk. That way you may include usable docs with the release, which is what people expect anyway (see my other message). (Otherwise, by the way, why let those django/docs/*.txt files slip inside each release?) > I should stress that, if we continue down this path of pointing people > at the trunk documentation by default, all documentation changes that > refer to new trunk features *must* be written in a way that users of > 0.96 will understand the change does not apply to them. We need to do a > better job of telling contributors and documentation writers that this > is how we do things. That's a laudable and worthy goal, but it does not allow to err on the side of safety. Better to accept that each release docs are what they are, and move forward. > As Matt McClanahan and some others pointed out, we could instead point > to the latest *release* docs by default. The trunk docs would be at > another URL, and presumably if you're sophisticated enough to use trunk, > you're sophisticated enough to know to go to that other URL. Right. > The advantage of this is that in the common case of a new user > downloading the latest release and going to the main documentation page, > he/she won't get confused. 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). > The disadvantage is that those release-specific docs won't have the > dozens of documentation improvements that come in every week, Just accept it, it's not worth the effort. > unless we fork the docs and apply every improvement to *both* the > latest-release docs and the trunk docs (which isn't worth the overhead). Exactly. > 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. Again, see my other message. -- Nicola Larosa - http://www.tekNico.net/ Itamar Shtull-Trauring: reactor.stop() is the way to go, yes. Call it when you want the program to start. Nicola Larosa: To be able to do that you would have to recall John and George from heaven, reform the Beatles, pay them a lot to compose "Stop Me Down", and use that as the sound theme. -- April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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 get the right documentation in the hands of > those who use a release: > > include the documentation in the frigging release, and make it usable! You've completely misunderstood the question. Shipping an extra HTML copy of the documentation would be equivalent to pointing the website copy to the 0.96 release documentationl. Adrian explained why he thinks even people using 0.96 should generally be reading the subversion docs and his logic make a lot of sense. Shipping documentation in the release doesn't mean people magically get updated documentation when we check fixes into subversion. Malcolm -- Plan to be spontaneous - tomorrow. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Time for a new release?
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: include the documentation in the frigging release, and make it usable! Current situation - The doc ReST source files are included in the release, but not the HTML, generated ones. The HTML doc index is not included. Users have to install docutils, run buildhtml on django/docs, manually point the browser to that directory, and they get unstyled paged, with no images, and whose links among them do not work. How to do it Use something like the django-documentation app by SmileyChris: http://smileychris.tactful.co.nz/ramblings/django-documentation/ Let users access the docs from both without and within the admin interface. The HTML generated files should be included in the release, so that users do not need to have docutils installed. Pros The users can easily access the right documentation locally, without needing access to the web site. The users do not risk getting to the wrong version of the docs. The load on djangoproject.com lessens considerably. Cons None that I can see. It's a no-brainer to me! :-) -- Nicola Larosa - http://www.tekNico.net/ Itamar Shtull-Trauring: reactor.stop() is the way to go, yes. Call it when you want the program to start. Nicola Larosa: To be able to do that you would have to recall John and George from heaven, reform the Beatles, pay them a lot to compose "Stop Me Down", and use that as the sound theme. -- April 2007 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
