Re: FastCGI + Lighttpd documentation

[Stephen Wolff]

Jyrki Pulliainen wrote:
> Hi,
>
> is there a particular reason why Lighttpd documentation advices user
> to create a separate script (for example, an init script) to create
> the socket with manage.py? Why not let the Lighttpd take care of
> spawning processes as needed?
>
> If no-one is against it, I could file a ticket about this and write
> the new documentation
>
> - Jyrki
>   
We use Lighttpd to serve a number of Django based projects, and I think 
we tend to use a restart script to spawn sprockets for development and 
staging sites, but let Lighttpd spawn sockets for live sites. We found 
that we needed to kill processes of non-production sites in order to see 
the effect of code changes. A server restart wasn't an option at the 
time as we were mixing live and staging sites on the same box (though 
we've moved away from this!)

Another point to consider is whether a site will start automatically 
when the server starts if it relies on a user created script.

- Stephen


--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Proposal: Tutorial Refresh

[Stephen Wolff]

> The tutorial is extremely important.  It will be the first part of the 
> docs read by 98% of new users.  Don't complicate it by tying it to 
> DjangoCon.  This thread has already seen requests for features that 
> will be great for real use, but would probably be too much to put into 
> a tutorial.  While it would be very cool to have the two sites be just 
> one site, I think it will either create an overgrown underexplained 
> tutorial as DjangoCon adds features needed for a real-world conference 
> site, or a simplistic toy DjangoCon site because the tutorial needs to 
> ensure that everything is clean, understandable, and accompanied by 
> clear prose.
>
> Why not serve just one master well, and have the tutorial be purely 
> about exposition and pedagogy?
>
> Am I being too pessimistic?
>
> --Ned.
>
I like the ideas for the tutorial so far, and whether the tutorial site 
is actually used for the actual DjangoCon or not, I like the idea of it 
being a conference site.

I wonder if mechanize (http://wwwsearch.sourceforge.net/mechanize/) can 
be included in the testing side of the tutorial. I noticed the module on 
Jacob's top ten, and hadn't come across it before. It sounds useful 
compared with (or in addition to) asserting that a particular 
HttpResponse code is returned.

Stephen

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: 404 debug pages should show the name of the tried urlpattern - #9310

[Stephen Wolff]

On 25/02/2010 20:05, SmileyChris wrote:

Just two small points I'd like to highlight:

On Feb 26, 3:50 am, Russell Keith-Magee
wrote:
   

I'm not casting blame here. Those doing triage work are doing a great
job. I'm just pointing out that we have a problem.  Despite the best
efforts of our volunteer triage team, they haven't been able to keep
up with the backlog. We either need more volunteers to do triage, or
we need to accept as a community that progress isn't going to be as
fast as we may like.
 

More volunteers! Come one people! *SmileyChris blows his triage
trumpet*

   
I've been reading this list for a while, and just read the 'Ticket 
Triage' part of the documentation 
[http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#ticket-triage 
/ 
http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#triage-by-the-general-community]


What do trusted ticket triagers do in addition to the 'triage by the 
general community' tasks? The docs are a bit vague on that. Anyhow - i'm 
going to do my best to find some time to do work on general tasks.


Stephen

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django's testing infrastructure

[Stephen Wolff]

We'd like to offer a CentOS 5 machine with Python 2.6 / MySQL 5.0 
(InnoDB and MyISAM) for testing (with Lighttpd 1.4.23 - if that is used 
in any tests). We'll try and set it up over the next week.


Stephen

On 26/02/2010 06:56, Russell Keith-Magee wrote:

On Fri, Feb 26, 2010 at 11:54 AM, Eric Holscher  wrote:
   

Hey everyone,

During the sprints, I worked to set up a hudson instance for Django. This is
hopefully going to be the way that we are going to go forward for now with
doing continuous integration for Django. I have a pretty good setup going
currently, and want make it really fantastic. At this point in time, what we
really need now is some more hardware to be able to run tests on.
 

Great work Eric!

   

So I'm looking for people who can offer other boxes that they would like to
see tested. Currently the big ones we aren't covering are Windows boxes, and
the Oracle backends. There are lots of other permutations that we could be
testing against (Different python runtimes being a good example).
 

Two others to put on this list of unusual platforms that need testing
(in case they aren't on your radar already):

  * MySQL has two configurations that require testing: MyISAM and InnoDB.

  * We also need testing for GIS configurations.

Russ %-)

   


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django's testing infrastructure

[Stephen Wolff]

btw - Simon and I work together - so the identical specs were actually 
one machine... anyhow, we're really pleased to be involved, and to see 
how this all goes. We've been toying with CI for a while - including 
trying out the Trac Bitten plugin (http://bitten.edgewall.org/) - which 
could be another possibility which would tie in with Django's Trac 
instance. I don't think it's quite as mature as Hudson though.


Stephen

On 26/02/2010 20:21, Eric Holscher wrote:

Awesome response!

Thanks for the offering of support everyone. Luckily, with hudson, 
it's pretty simple to get this all set up. We basically just need to 
figure out what the infrastructure looks like.


I don't know if it's going to make more sense to try and set up 
dedicated Database servers, or try and set up each client to have the 
necessary databases running on each one.


Currently, all I need for a slave machine is a box with a publically 
accessable IP, with an account with the Django Testmaster's key on it. 
Hudson will take care of everything from there, at least on the Django 
side.


Hudson will ssh in and pull down Java if necessary, then run itself as 
a client. It seems we will need to have some kind of standard setup 
for the databases, with either local connections being let through 
without auth, or with a standard username and password (maybe 
django/django), so that we can do the database operations.


If anyone has much experience here, I'll probably be doing some 
benchmarking to figure out what kind of app to database server ratio 
we need, and what makes sense in that regard.


I'll give this some more thought this weekend, and try and email 
everyone who has offered support. I know there is a django-buildbots 
mailing list that never got used last time we did this, i dunno if we 
want to keep the conversation here and more public, or put it over 
there and keep the archives around for setting stuff up.


Thanks again for all the offers, it's really great, now we just need 
to figure out how to scale this up without using lots of human hours 
in the process.


Cheers,
Eric


On Fri, Feb 26, 2010 at 1:08 PM, Mikhail Korobov 
mailto:kmik...@googlemail.com>> wrote:


That's great news, thanks!

A very minor issue: web server returns 'Content-Type:text/
html;charset=ISO-8859-1' header for this page:
http://hudson.djangoproject.com/monitor/?
but the actual page encoding is utf-8 so there are strange symbols
instead of translated strings.

--
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
django-developers+unsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.




--
Eric Holscher
Web Developer at The World Company in Lawrence, Ks
http://ericholscher.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-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: High Level Discussion about the Future of Django

[Stephen Wolff]

I feel quite sad reading this thread. Good luck completing 1.2. I only wish
I had time and energy to contribute. I suggest the core team ignore the
thread for now if at all possible.

On 17 Apr 2010 14:47, "Russell Keith-Magee"  wrote:

On Sat, Apr 17, 2010 at 7:14 PM, George Sakkis 
wrote:
> On Apr 17, 5:35 am...
For the record, there are 62 tickets marked ready for checkin, not 400
[1]. 29 of those are documentation and translation patches (5 of which
are specifically marked for inclusion in 1.2).

[1]
http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&order=priority&stage=Ready+for+checkin

On top of that, the Ready For Checkin status doesn't mean that a
member of the core team has reviewed a patch. It means that someone --
anyone -- thinks the patch is ready for checkin. There's no guarantee
that a Ready For Checkin patch is *actually* ready for checkin. If you
do a survey of the Ready For Checkin patches, you'll find tickets that
don't have test cases, or add features that aren't documented, or make
a significant changes that haven't been discussed on django-dev. If I
were to sit down and work through that list, I guarantee I wouldn't
end up making 62 commits to trunk using the material that has been
provided on those tickets.

I would also point out the folly of looking at raw ticket counts.
Python (the language) has 1078 tickets in the "having patch" status,
and 96 in the "needing review" status. Does this mean that Python is a
project in crisis?

Yes, there is a ticket backlog. Yes, this means there is a lot of work
that needs to be done. What we need is people volunteering to actually
do that work. However, as I've already indicated in this thread, much
of that work could be done without any change in current project
policy - we just needs people to actually do the work.

My dream outcome would to be in the situation where I don't *ever*
have to spend time on Trac trying to work out if the ticket that has
been marked Ready For Checkin is *actually* ready for checkin. Give me
a rich vein of trunk ready tickets that has been reviewed by someone
whose reputation I know and trust, and believe me -- I will use it.


> Healthy projects don't need a separately maintained fork/branch on
> github or bitbucket just to ...
The flipside of this is that too many cooks spoil the broth. If we
want to maintain a high quality product, we can't just add a dozen new
developers to the core team.

I would also point out that even in projects that do have large teams
with the commit bit, access to the "core trunk" is generally only made
available to a restricted subset of the entire team. Alternatively,
some sort of code review process is used to ensure that multiple team
members (occasionally, specially blessed team members) check patches
before they are committed. There's a lot more to commit policies in
open source than raw team size.

Yours,
Russ Magee %-)


-- 
You received this message because you are subscribed to the Google Groups
"Django developers" g...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Trac workflow assistance (commiter feedback needed)

[Stephen Wolff]

5-10: The most useful of the lot for me personally. An automated
process that applies patches and runs tests would be nice; if it can
autocheck the appropriate flags ("patch needs improvement", "needs
tests" etc) that would be even better.
 

I recognize running tests w/ regressions pass would be useful, but
it's getting into CI-land -- once we have some CI infrastructure in
place, I'd be happy to use that.

   
In case you missed it, there already is some CI infrastructure a 
bunch of servers made available to django for testing via Hudson:


http://hudson.djangoproject.com/

Stephen

--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Django t-shirt

[Stephen Wolff]

Hi there,

A few Django versions ago (1.7 and maybe 1.8?!), t-shirts were produced and 
sold (i guess for fundraising purposes?).

Just wondering given the forthcoming LTS is 4.2, which has similarities to 
Douglas Adams's answer to the life, universe and everything, whether a new 
t-shirt could be produced?

Yours hopefully,

Stephen

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7570a944-3822-4493-acf0-4510c24e7b8bn%40googlegroups.com.

Re: Django t-shirt

[Stephen Wolff]

Awesome thanksSent from a mobile device!On 15 Jan 2023, at 08:03, 'Adam Johnson' via Django developers  (Contributions to Django itself)  wrote:There is a Django Threadless store where you can buy T-Shirts and other merchandise, which all supports the DSF: https://django.threadless.com/It’s linked from the fundraising page: https://www.djangoproject.com/fundraising/I have a Django phone case from there!On Fri, Jan 13, 2023 at 11:44 AM Stephen Wolff <stephen.wo...@gmail.com> wrote:Hi there,A few Django versions ago (1.7 and maybe 1.8?!), t-shirts were produced and sold (i guess for fundraising purposes?).Just wondering given the forthcoming LTS is 4.2, which has similarities to Douglas Adams's answer to the life, universe and everything, whether a new t-shirt could be produced?Yours hopefully,Stephen



-- 
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7570a944-3822-4493-acf0-4510c24e7b8bn%40googlegroups.com.




-- 
You received this message because you are subscribed to a topic in the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/eM5LaDD8NCQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQx2RTyDktvi%2BTCMa%3D4PR43SXPpwxv7V9A8bL-z-hEA%40mail.gmail.com.




-- 
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/645AD2FF-F08E-4208-99DE-EAFC69E9495B%40gmail.com.

Re: Global name 'table' not defined

[Stephen Wolff]

The only time i've seen this sort of thing happening was when i had an  
app name that got in the way of something in the core/python namespace  
('collections'). Do you have any apps that could be getting in the  
way? Does the error occur with all your projects?


Stephen

On 30 Aug 2010, at 17:35, Tim wrote:


I'm on the latest trunk (updated this morning), and I'm getting a
Python NameError in django.core.cache.backends.db .  Line 127 (http://
code.djangoproject.com/browser/django/trunk/django/core/cache/ 
backends/

db.py#L127) references a variable 'table', but it's not locally
defined.  All other methods in the CacheClass first do the following
line before such use:

table = connections[db].ops.quote_name(self._table)

Has anybody else run into this problem in runtime?  I was surprised
that the error was legitimately happening in the core code.

--
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 django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en 
.




--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: a new template algorithm

[Stephen Wolff]

Yep, and encourage new people to the list to actively contribute!

One thing springs to mind, an agile / crystal process 'game', which  
encourages all parties to contribute ideas within a time frame  
(usually half an hour to a hour), without prejudice or discouragement.  
This gets lots of good and bad ideas out into the open, which can then  
be whittled down. Without the openness, contributors are put off, no  
ideas flow...


Just my 2 pennies (yep, i'm in the UK :-))


On 31 Aug 2010, at 18:24, stefanw wrote:


Hello,

I guess the most interesting point in this discussion is:


After a while that I spent time to develop new tags and filters
especially for
new projects, I began to think a way to implement a template engine
that
would let me no more write sort of "plugins" like tags and filters, a
thing that
really bother me.


The template language is great, it's design decisions are sensible,
but writing filters and tags is too complex and time-consuming.
Unnecessarily so, as wrappers around creating template tags have shown
(e.g. django-templatetag-sugar by Alex Gaynor). If people don't see a
documented way of easily bringing features to their templates, they
may switch the template engine or, well, start patching the template
engine.
Bottom line: we need to improve the template tag creation.

Cheers
Stefan

--
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 django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en 
.




--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A prompt 1.2.3 release

[Stephen Wolff]

Hi Eric,

Does this mean that the account we set up on our server is no longer  
necessary?


Stephen

On 11 Sep 2010, at 01:09, Eric Holscher wrote:



There was a hudson server running IIRC, but
http://hudson.djangoproject.com/ is not responding to me.


I took the hudson instance down because nobody was using it and it  
was costing me a decent amount of money to run per month. I still  
have the images around on Rackspace Cloud if the DSF or anyone  
actually wants to pay to have good CI.


Just as a data point, I took it down about a month ago, and people  
only just noticed during the sprints. I don't know how to fix that  
particular problem.


Cheers,
Eric


--
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 django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en 
.


--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.