subject:"\[Python\-Dev\] Community buildbots"

Today on planetpython.org, Doug Hellman announced the June issue of 
Python magazine.  The cover story this month is about Pybots, the 
fantastic automation system that has been put in place to make sure new 
releases of Python software are as robust and stable as possible.


Last week, there was a beta release of Python which, according to the 
community buildbots, cannot run any existing python software.  Normally 
I'd be complaining here about Twisted, but in fact Twisted is doing 
relatively well right now; only 80 failing tests.  Django apparently 
cannot even be imported.


The community buildbots have been in a broken state for months now[1]. 
I've been restraining myself from whinging about this, but now that it's 
getting close to release, it's time to get these into shape, or it's 
time to get rid of them.


There are a few separate issues here.  One is, to what extent should 
Python actually be compatible between releases?  There's not much point 
in saying this release is compatible with python 2.5 if all python 2.5 
programs need to be modified in order to run on python 2.6.  Of course, 
it's quite likely that there are some 3rd-party Python programs that 
continue to work, but python.org provides links to 2 projects that don't 
and none that do.


Another way to phrase this question is, whose responsibility is it to 
make Python 2.5 programs run on Python 2.6?  Or, what happens when the 
core team finds out that a change they have made has broken some python 
software 'in the wild'?


Here are a couple of ways to answer these questions:

 1) It's the python core team's responsibility.  There should be Python 
buildbots for lots of different projects and they should all be green 
before the code can be considered [one of: allowed in trunk, alpha, 
beta, RC].
 2) It's the python core team's responsibility as long as the major 
projects are using public APIs.  The code should not be considered 
[alpha, beta, RC] if there are any known breakages in public APIs.
 3) It's only the python core team's responsibility to notify projects 
of incompatible changes of which they are aware, which may occur in 
public or private APIs.  Major projects with breakages will be given a 
grace period before a [beta, RC, final] to release a forward-compatible 
version.
 4) The status quo: every new Python release can (and will, at least 
speaking in terms of 2.6) break lots of popular software, with no 
warning aside from the beta period.  There are no guarantees.


For obvious reasons, I'd prefer #1, but any of the above is better than 
#4.  I don't think #4 is an intentional choice, either; I think it's the 
result of there being no clear consequence for community buildbots 
failing.  Or, for that matter, of core buildbots failing.  Investigating 
the history is tricky (I see a bunch of emails from Barry here, but I'm 
not sure which is the final state) but I believe the beta went out with 
a bunch of buildbots offline or failing.


A related but independent issue is: should the community buildbots 
continue to exist?  An automated test is only as good as the 
consequences of its failure.  As it stands, the community buildbots seem 
to be nothing but an embarrassment.  I don't mean this to slam Grig, or 
the Python team - I mean, literally, if there is no consequence of their 
failure then the only use I can see for the data the buildbots currently 
provide (i.e. months and months of failures) is to embarrass the Python 
core developers.  python.org's purpose should not be to provide negative 
press for Python ;), so if this continues to be the case, they probably 
shouldn't be linked.  This isn't just an issue with changes to Python 
breaking stuff; the pybots' configuration is apparently not well 
maintained, since the buildbots which say 2.5 aren't passing either, 
and that's not a problem with the code, it's just that the slaves are 
actually running against [EMAIL PROTECTED]


Ultimately these tools only exist to ensure the quality of Python 
releases.  The really critical question here is, what does it mean to 
have a Python release that is high-quality?  There are some obvious 
things: it shouldn't crash, it should conform to its own documentation. 
Personally I think it passes all of its own tests and it runs 
existing Python code are important metrics too, but the most important 
thing I'm trying to get across here is that there should be a clear 
understanding of which goals the release / QA / buildbot / test process 
is trying to accomplish.  For me, personally, it really needs to be 
clear when I can say you guys screwed up and broke stuff, and when I 
just have to suck it up and deal with the consequences of a new version 
of Python in Twisted.


It's definitely bad for all of us if the result is that new releases of 
Python just break everything.  Users don't care where the responsibility 
lies, they just know that stuff doesn't work, so we should decide on a 
process which allows Twisted (and

Re: [Python-Dev] Community buildbots and Python release quality metrics

Too verbose, Glyph. :-)

It needs to be decided case-by-case. The beta is called beta because,
well, it may break stuff and we may want to fix it. But there are also
likely many frameworks that use undefined behavior. I'm not
particularly impressed by statistics like all tests are red -- this
may all be caused by a single issue. For example, I'd much rather read
an explanation about *why* Django cannot even be imported than a
blanket complaint that this is a disgrace. So why is it?

--Guido

On Thu, Jun 26, 2008 at 8:18 AM,  [EMAIL PROTECTED] wrote:
 Today on planetpython.org, Doug Hellman announced the June issue of Python
 magazine.  The cover story this month is about Pybots, the fantastic
 automation system that has been put in place to make sure new releases of
 Python software are as robust and stable as possible.

 Last week, there was a beta release of Python which, according to the
 community buildbots, cannot run any existing python software.  Normally I'd
 be complaining here about Twisted, but in fact Twisted is doing relatively
 well right now; only 80 failing tests.  Django apparently cannot even be
 imported.

 The community buildbots have been in a broken state for months now[1]. I've
 been restraining myself from whinging about this, but now that it's getting
 close to release, it's time to get these into shape, or it's time to get rid
 of them.

 There are a few separate issues here.  One is, to what extent should Python
 actually be compatible between releases?  There's not much point in saying
 this release is compatible with python 2.5 if all python 2.5 programs need
 to be modified in order to run on python 2.6.  Of course, it's quite likely
 that there are some 3rd-party Python programs that continue to work, but
 python.org provides links to 2 projects that don't and none that do.

 Another way to phrase this question is, whose responsibility is it to make
 Python 2.5 programs run on Python 2.6?  Or, what happens when the core
 team finds out that a change they have made has broken some python software
 'in the wild'?

 Here are a couple of ways to answer these questions:

  1) It's the python core team's responsibility.  There should be Python
 buildbots for lots of different projects and they should all be green before
 the code can be considered [one of: allowed in trunk, alpha, beta, RC].
  2) It's the python core team's responsibility as long as the major projects
 are using public APIs.  The code should not be considered [alpha, beta, RC]
 if there are any known breakages in public APIs.
  3) It's only the python core team's responsibility to notify projects of
 incompatible changes of which they are aware, which may occur in public or
 private APIs.  Major projects with breakages will be given a grace period
 before a [beta, RC, final] to release a forward-compatible version.
  4) The status quo: every new Python release can (and will, at least
 speaking in terms of 2.6) break lots of popular software, with no warning
 aside from the beta period.  There are no guarantees.

 For obvious reasons, I'd prefer #1, but any of the above is better than #4.
  I don't think #4 is an intentional choice, either; I think it's the result
 of there being no clear consequence for community buildbots failing.  Or,
 for that matter, of core buildbots failing.  Investigating the history is
 tricky (I see a bunch of emails from Barry here, but I'm not sure which is
 the final state) but I believe the beta went out with a bunch of buildbots
 offline or failing.

 A related but independent issue is: should the community buildbots continue
 to exist?  An automated test is only as good as the consequences of its
 failure.  As it stands, the community buildbots seem to be nothing but an
 embarrassment.  I don't mean this to slam Grig, or the Python team - I mean,
 literally, if there is no consequence of their failure then the only use I
 can see for the data the buildbots currently provide (i.e. months and months
 of failures) is to embarrass the Python core developers.  python.org's
 purpose should not be to provide negative press for Python ;), so if this
 continues to be the case, they probably shouldn't be linked.  This isn't
 just an issue with changes to Python breaking stuff; the pybots'
 configuration is apparently not well maintained, since the buildbots which
 say 2.5 aren't passing either, and that's not a problem with the code,
 it's just that the slaves are actually running against [EMAIL PROTECTED]

 Ultimately these tools only exist to ensure the quality of Python releases.
  The really critical question here is, what does it mean to have a Python
 release that is high-quality?  There are some obvious things: it shouldn't
 crash, it should conform to its own documentation. Personally I think it
 passes all of its own tests and it runs existing Python code are
 important metrics too, but the most important thing I'm trying to get across
 here is that there should be a clear

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Nick Coghlan


[EMAIL PROTECTED] wrote:
Today on planetpython.org, Doug Hellman announced the June issue of 
Python magazine.  The cover story this month is about Pybots, the 
fantastic automation system that has been put in place to make sure new 
releases of Python software are as robust and stable as possible.


Last week, there was a beta release of Python which, according to the 
community buildbots, cannot run any existing python software.  Normally 
I'd be complaining here about Twisted, but in fact Twisted is doing 
relatively well right now; only 80 failing tests.  Django apparently 
cannot even be imported.


beta 1 has some trouble running *our* test suite - I'd be fairly 
surprised if the community buildbots were in significantly better shape.



The community buildbots have been in a broken state for months now[1].


Continuously running community buildbots on the maintenance trees makes 
sense, since those trees should always be in a releasable state. For the 
trunk, they're really only interesting when the Python core buildbots 
are reporting all green, but some of the community buildbots are 
reporting red.


One of the problems is what the term beta means to different groups - 
for us, this first beta was really about saying zero new features from 
here on, focus on making what we have now work properly. The relatively 
late landing of a couple of major PEPs (371, 3108) also didn't do any 
favours for trunk stability.


If the community buildbots aren't largely green by the time beta 2 comes 
out, that's when I'll agree we have a problem - they should definitely 
be green by the time first release candidate comes out.


Cheers,
Nick.

--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


On 03:33 pm, [EMAIL PROTECTED] wrote:

Too verbose, Glyph. :-)


Mea culpa.  Glyph might be a less appropriate moniker than Altogether 
too many glyphs.

It needs to be decided case-by-case.


If certain tests are to be ignored on a case-by-case basis, why not 
record that decision by disabling the test in the code?  Otherwise, the 
decision inevitably gets boiled down to it's okay to release the code 
with a bunch of tests failing, but I don't know which ones.  As it was 
on Twisted when we used to make case-by-case decisions about failures, 
and as it is here now.
The beta is called beta because, well, it may break stuff and we may 
want to fix it.


That's also why the alpha is called an alpha.  My informal understanding 
is that a beta should have no (or at least very few) known issues, with 
a medium level of confidence that no further ones will be found.  An RC 
would have absolutely no known issues with a fairly high level of 
confidence that no further ones will be found.  This would include the 
community buildbots basically working for the most part; I would not be 
surprised if there were a few tests that still had issues.


But clearly the reality does not meet my informal expectations, so it 
would be nice to have something written down to check against.  Still, 
I'm bringing this up now because it _is_ a beta, and I think it will be 
too late to talk about dealing with persistent test failures after the 
RCs start coming out.


(Of course, I'm just being sneaky.  I don't actually care if it's 
clearly documented, I just care that I stop having problems with 
incompatibility.  But I believe having it clearly spelled out would 
actually prevent a lot of the problems that I've been having, since I 
don't think anyone would *intentionally* select a policy where every 
release breaks at least one major dependent project.)
I'm not particularly impressed by statistics like all tests are red 
-- this

may all be caused by a single issue.


The issue, for me, is not specifically that tests are red.  It's that 
there's no clear policy about what to do about that.  Can a release go 
out with some of the tests being red?  If so, what are the extenuating 
circumstances?  Does this have to be fixed?  If not, why not?  Why are 
we talking about this now?  Shouldn't the change which caused Django to 
become unimportable have been examined at the time, rather than months 
later?  (In other words, if it *is* a single issue, great, it's easy to 
fix: revert that single issue.)  If not, then shouldn't someone in 
Django-land have been notified so they could cope with the change?


Sorry that there are so many questions here; if I had fewer, I'd use 
fewer words to ask them.
For example, I'd much rather read an explanation about *why* Django 
cannot even be imported than a blanket complaint that this is a 
disgrace. So why is it?


I don't know.  JP is already addressing the issues affecting Twisted in 
another thread (incompatible changes in the private-but-necessary-to- 
get-any-testing-done API of the warnings module).  But I really think 
that whoever made the change which broke it should be the one 
investigating it, not me.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


On 03:42 pm, [EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:


beta 1 has some trouble running *our* test suite - I'd be fairly 
surprised if the community buildbots were in significantly better 
shape.


That's another problem, yes :)

The community buildbots have been in a broken state for months now[1].


If the community buildbots aren't largely green by the time beta 2 
comes out, that's when I'll agree we have a problem - they should 
definitely be green by the time first release candidate comes out.


I have mixed feelings about this: on the one hand, if this were a matter 
of public record, I would have known that this was too early to start 
complaining, and we could have saved everyone a lot of time reading 
these messages.  That would be good; I would prefer to just let everyone 
work without bothering about process.


On the other hand, it's much easier to deal with test failures as they 
arise than in one giant chunk of work at the end of the development 
process.  I spoke to a few core developers at PyCon who thought that the 
buildbots should always be green and any change that broke them should 
be reverted.  They may remain nameless unless they wish to raise their 
hands :-) but that's definitely how I feel about it.
Continuously running community buildbots on the maintenance trees makes 
sense, since those trees should always be in a releasable state. For 
the trunk, they're really only interesting when the Python core 
buildbots are reporting all green, but some of the community buildbots 
are reporting red.


(... which should be all the time ...)
One of the problems is what the term beta means to different groups - 
for us, this first beta was really about saying zero new features from 
here on, focus on making what we have now work properly. The 
relatively late landing of a couple of major PEPs (371, 3108) also 
didn't do any favours for trunk stability.


A big part of why I wrote this message is that I wanted a clear 
understanding of the relationship between the definition of  alpha, 
beta and RC and the state of various buildbots.  If that 
relationship exists already, just linking to it from 
http://python.org/download/releases/2.6/ would be good.  By the way, 
that page still says these are alpha releases.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum [EMAIL PROTECTED] wrote:

 an explanation about *why* Django cannot even be imported than a
 blanket complaint that this is a disgrace. So why is it?



  File /home/ralf/pediapress/appserver/django/db/models/options.py,
line 198, in _many_to_many
self._fill_m2m_cache()
  File /home/ralf/pediapress/appserver/django/db/models/options.py,
line 221, in _fill_m2m_cache
cache[field] = None
  File /home/ralf/pediapress/appserver/django/utils/datastructures.py,
line 75, in __setitem__
super(SortedDict, self).__setitem__(key, value)
TypeError: unhashable type: 'ManyToManyField'


same for sqlalchemy:
egg/sqlalchemy/schema.py, line 113, in __call__
return type.__call__(self, name, metadata, *args, **kwargs)
  File 
/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py,
line 207, in __init__
self.primary_key = PrimaryKeyConstraint()
  File 
/home/ralf/py26/lib/python2.6/site-packages/SQLAlchemy-0.5.0beta1-py2.6.egg/sqlalchemy/schema.py,
line 294, in _set_primary_key
self.constraints.add(pk)
TypeError: unhashable type: 'PrimaryKeyConstraint'


and already discussed:
http://mail.python.org/pipermail/python-dev/2008-April/078421.html

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Scott Dial


Ralf Schmitt wrote:

TypeError: unhashable type: 'ManyToManyField'
TypeError: unhashable type: 'PrimaryKeyConstraint'

and already discussed:
http://mail.python.org/pipermail/python-dev/2008-April/078421.html


Following the discussion to it's conclusions leads one to a tracker 
issue [1] that was supposed to be a blocker for the beta but (I assume) 
was forgotten about. Clearly this should be promoted to being a blocker 
again and some decision made.


[1] http://bugs.python.org/issue2235

--
Scott Dial
[EMAIL PROTECTED]
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


On 04:42 pm, [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum [EMAIL PROTECTED] 
wrote:

an explanation about *why* Django cannot even be imported than a
blanket complaint that this is a disgrace. So why is it?



and already discussed:
http://mail.python.org/pipermail/python-dev/2008-April/078421.html


Following that trail of breadcrumbs, I ended up here:

   http://bugs.python.org/issue2235

with a message from some guy named Barry Warsaw (anyone know him?) 
that says:


 
 Guido, can you comment on Amaury's latest patch?  I'm going to bump 
this
 back to critical so as not to hold up 2.6 alpha, but it should be 
marked

 as a release blocker for the first beta.
 

I don't know if this Barry guy has the appropriate permissions on the 
bugtracker to increase priorities, so I've taken the liberty of 
upgrading it as a release blocker for the _second_ beta ... ;-).  So, at 
least there's been one productive consequence of this discussion.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

And just to make my position perfectly clear, I've unassigned it,
since I don't foresee to be able to give this issue the quality time
it clearly needs. Mind you, I agree it's a release blocker. But I
don't have time to personally investigate it. Sorry.

On Thu, Jun 26, 2008 at 9:54 AM,  [EMAIL PROTECTED] wrote:
 On 04:42 pm, [EMAIL PROTECTED] wrote:

 On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum [EMAIL PROTECTED]
 wrote:

 an explanation about *why* Django cannot even be imported than a
 blanket complaint that this is a disgrace. So why is it?

 and already discussed:
 http://mail.python.org/pipermail/python-dev/2008-April/078421.html

 Following that trail of breadcrumbs, I ended up here:

   http://bugs.python.org/issue2235

 with a message from some guy named Barry Warsaw (anyone know him?) that
 says:

  
  Guido, can you comment on Amaury's latest patch?  I'm going to bump this
  back to critical so as not to hold up 2.6 alpha, but it should be marked
  as a release blocker for the first beta.
  

 I don't know if this Barry guy has the appropriate permissions on the
 bugtracker to increase priorities, so I've taken the liberty of upgrading it
 as a release blocker for the _second_ beta ... ;-).  So, at least there's
 been one productive consequence of this discussion.
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/guido%40python.org




-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 That's also why the alpha is called an alpha.  My informal understanding
 is that a beta should have no (or at least very few) known issues

No, that's not the purpose. Instead, it is a promise that no further
features will be added, i.e. that the code is stable from a feature
point of view.

It certainly will contain bugs. The final release will certainly contain
bugs, just look at the long list of open bug reports.

 The issue, for me, is not specifically that tests are red.  It's that
 there's no clear policy about what to do about that.  Can a release go
 out with some of the tests being red?  If so, what are the extenuating
 circumstances?

The final release, no. The beta release: sure (in particular if it's the
first beta release).

Also make a difference between the Python buildbots, and the community
buildbots. I think few if any core committers ever look at the status
of the community buildbots - the community has to bring breakage to
our attention (as you just did).

 Does this have to be fixed?  If not, why not?

Here, I'm confused what specifically you talk about. That Django doesn't
import? It is certainly not part of the release procedure to verify that
Django can still be imported.

 Why are
 we talking about this now?  Shouldn't the change which caused Django to
 become unimportable have been examined at the time, rather than months
 later?

Somebody should have pointed it out when it happened. Unfortunately,
nobody did, so apparently, the community doesn't really care.

 I don't know.  JP is already addressing the issues affecting Twisted in
 another thread (incompatible changes in the private-but-necessary-to-
 get-any-testing-done API of the warnings module).  But I really think
 that whoever made the change which broke it should be the one
 investigating it, not me.

How could they have known that they broke it?

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 A big part of why I wrote this message is that I wanted a clear
 understanding of the relationship between the definition of  alpha,
 beta and RC and the state of various buildbots.  If that
 relationship exists already, just linking to it from
 http://python.org/download/releases/2.6/ would be good.  By the way,
 that page still says these are alpha releases.

I think its significantly simpler to answer specific questions on the
mailing list, to educate the specific set of people who have this
question, than to put an official answer on the web page.

So I'm skeptical that anybody will change the web page - just continue
asking questions as you encounter them.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 6:54 PM,  [EMAIL PROTECTED] wrote:
 On 04:42 pm, [EMAIL PROTECTED] wrote:

 On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum [EMAIL PROTECTED]
 wrote:

 an explanation about *why* Django cannot even be imported than a
 blanket complaint that this is a disgrace. So why is it?

 and already discussed:
 http://mail.python.org/pipermail/python-dev/2008-April/078421.html

 Following that trail of breadcrumbs, I ended up here:

   http://bugs.python.org/issue2235

 with a message from some guy named Barry Warsaw (anyone know him?) that
 says:

  
  Guido, can you comment on Amaury's latest patch?  I'm going to bump this
  back to critical so as not to hold up 2.6 alpha, but it should be marked
  as a release blocker for the first beta.
  

 I don't know if this Barry guy has the appropriate permissions on the
 bugtracker to increase priorities, so I've taken the liberty of upgrading it
 as a release blocker for the _second_ beta ... ;-).  So, at least there's
 been one productive consequence of this discussion.

this patch even make things worse for me. now py.test also dies.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt [EMAIL PROTECTED] wrote:
 this patch even make things worse for me. now py.test also dies.

Please add details to the tracker.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 7:55 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
 On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt [EMAIL PROTECTED] wrote:
 this patch even make things worse for me. now py.test also dies.

 Please add details to the tracker.


Well, I think most probably the patch is correct and it just catches
another class which defines __eq__ but does not define __hash__. So
nothing to add there.
The question is if this behaviour should be kept or not. I guess
there's no bug tracking that...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 11:07 AM, Ralf Schmitt [EMAIL PROTECTED] wrote:
 On Thu, Jun 26, 2008 at 7:55 PM, Guido van Rossum [EMAIL PROTECTED] wrote:
 On Thu, Jun 26, 2008 at 10:40 AM, Ralf Schmitt [EMAIL PROTECTED] wrote:
 this patch even make things worse for me. now py.test also dies.

 Please add details to the tracker.

 Well, I think most probably the patch is correct and it just catches
 another class which defines __eq__ but does not define __hash__. So
 nothing to add there.

So you're saying py.test needs to be fixed? Fine with me, but then I
don't understand why you bothered bringing it up here instead of
fixing it (or reporting to the py.test maintainers, I don't know if
you're one or not).

 The question is if this behaviour should be kept or not. I guess
 there's no bug tracking that...

The best place is that very same issue. If this feature is really too
annoying something needs to be done. Detailed reports about real code
that gets broken without a good cause help making that case.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics



I do tend to ramble on, so here's an executive summary of my response:

I want python developers to pay attention to the community buildbots and 
to treat breakages of existing projects as a serious issue.  However, I 
don't think that maintaining those projects is the core team's job, so 
all I'm asking for is for core developers to:


 * treat breakages of 3rd party packages as a potentially serious issue,
 * if possible (i.e. if they find out about the breakage soon enough, 
which should be the case in any pybots failure) revert the change that 
caused the problem until the problem can be fixed, and
 * notify 3rd party maintainers when it's decided that the breakage will 
not be fixed.


This only applies to breakages that the core developers find out about, 
which for all practical purposes means the ones on the community 
builders page.


Those of you looking for point-by-point responses and some repetition of 
the above points, enjoy :).


On 05:03 pm, [EMAIL PROTECTED] wrote:

On Thu, Jun 26, 2008 at 9:21 AM,  [EMAIL PROTECTED] wrote:

On 03:33 pm, [EMAIL PROTECTED] wrote:

It needs to be decided case-by-case.

(misunderstanding)

No, I just meant that we need to figure out for each 3rd party test
that fails whether the failure is our fault (too incompatibile) or
theirs (relied on undefined behavior) and what the best fix is (change
our code or theirs -- note that even if it's there fault there are
cases where the best fix is to change our code.


This is basically fine, as far as I'm concerned.

I would like to suggest, however, that these issues be dealt with as 
soon as possible, rather than waiting for the release process to begin. 
A lot of decisions are made on this mailing list about the supposed 
properties of average python code, without any actual survey of said 
code.  Sometimes the results of that survey can be really surprising. 
The end goal of any particular compatibility policy, of a distinction 
between public and private APIs, and so on, is to keep code working.

I'm sorry if your interpretation of the terminology is different, but
this is mine and this is what we've always used, and it's not likely
to change. (At least not for the 2.6/3.0 release.)


I have no problem with your definitions of these terms.  I think that 
they should probably be in PEP 101 though.  Would you accept a patch 
that added an edited / expanded version of this paragraph?

Still, I'm bringing this up now because it _is_ a beta,



Absolutely correct. The RCs are hoped to be as good as the final
release. *Now* is the time to bring up issue.


Well, that's good, at least :)

But please bring up specific issues -- I don't want to have an
extended discussion about process or quality or expectations. I just
want the code to be fixed.


Well, one specific issue has been bumped in priority as a result of this 
thread, and others are under discussion.  The code is getting fixed.

(I just care that I stop having problems with incompatibility.)


And here we seem to be parting our ways. We have a large amount of
process already. I don't want more.


Looking at it from my perspective, I'm proposing a reduction in process. 
Under the current process, if a buildbot goes red, the developer makes a 
judgment call, the release manager makes a judgment call, there's 
discussion on a ticket, a ticket gets filed, it gets promoted, it gets 
demoted, the RM forgets to re-promote it...


My suggestion is that the process be, simply: if a buildbot (community 
or otherwise) goes red, the change that broke it gets reverted.  No 
questions asked!  It's still there in the revision history, ready to be 
re-applied once the issues get worked out.  Discussion can then take 
place and case-by-case judgments can be applied.

If you're talking about community buildbots (which I presume are
testing 3rd party packages against the core release) being red, that's
out of scope for the core developers.


I don't necessarily think that keeping the community buildbots red is 
the core developers' responsibility, but I don't think it should be 
entirely out of scope, either.  The python test suite is, frankly, poor 
- and I hope I'm not surprising you by saying that.  It's full of race 
conditions, tends to fail intermittently, and is frequently ignored. 
Not only that, but it is quite often changed, so tests for issues that 
affect real code are quite often removed.  So, the community buildbots 
are not just making sure that 3rd-party code still works, they are an 
expanded, independently developed test suite to make sure that *python 
itself* still works.  Sometimes they will not fill that role 
particularly well, but they are worth paying attention to.


If python had a good, exhaustive regression test suite that was 
immutable between major versions, I'd probably feel differently.  But 
that's not the world we live in.


Right now, apparently, the *default* policy is that if the community 
buildbots go red, later, before a release, someone

Re: [Python-Dev] Community buildbots and Python release quality metrics



On 05:14 pm, [EMAIL PROTECTED] wrote:
I don't know.  JP is already addressing the issues affecting Twisted 
in

another thread (incompatible changes in the private-but-necessary-to-
get-any-testing-done API of the warnings module).  But I really think
that whoever made the change which broke it should be the one
investigating it, not me.


How could they have known that they broke it?


Because the relevant community buildbot turned red with that revision of 
trunk.  Keep in mind I'm not talking about every piece of Python code in 
the universe; just the ones selected for the community buildbots.  It 
would be nice if there were a dozen or so projects on there, but paying 
attention to the two builders that do actually run right now would be a 
good start.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


[EMAIL PROTECTED] schrieb:

Another way to phrase this question is, whose responsibility is it to 
make Python 2.5 programs run on Python 2.6?  Or, what happens when the 
core team finds out that a change they have made has broken some python 
software 'in the wild'?


Here are a couple of ways to answer these questions:

  1) It's the python core team's responsibility.  There should be Python 
buildbots for lots of different projects and they should all be green 
before the code can be considered [one of: allowed in trunk, alpha, 
beta, RC].
  2) It's the python core team's responsibility as long as the major 
projects are using public APIs.  The code should not be considered 
[alpha, beta, RC] if there are any known breakages in public APIs.


  3) It's only the python core team's responsibility to notify projects 
of incompatible changes of which they are aware, which may occur in 
public or private APIs.  Major projects with breakages will be given a 
grace period before a [beta, RC, final] to release a forward-compatible 
version.
  4) The status quo: every new Python release can (and will, at least 
speaking in terms of 2.6) break lots of popular software, with no 
warning aside from the beta period.  There are no guarantees.


Python's backwards compatibility has never extended to non-public APIs.
That rules out 1). 2) would be nice, but to be honest, 2) and 3) are
unrealistic given the number of Python core developers and the tasks
already at hand. 4) is not acceptable either.

However, you seem to be overlooking that there's a 3.5) in there: it's
the Python core team's responsibility as long as the major projects are
using public APIs; but to reduce the workload every project should watch
its own buildbots and notify the core team using the issue tracker in
order to get the issue resolved.

At no time will a policy the community buildbots must be green be
useful: the tests that run on these buildbots are not under our control,
so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


[EMAIL PROTECTED] schrieb:

On 03:42 pm, [EMAIL PROTECTED] wrote:

[EMAIL PROTECTED] wrote:


beta 1 has some trouble running *our* test suite - I'd be fairly 
surprised if the community buildbots were in significantly better 
shape.


That's another problem, yes :)

The community buildbots have been in a broken state for months now[1].


If the community buildbots aren't largely green by the time beta 2 
comes out, that's when I'll agree we have a problem - they should 
definitely be green by the time first release candidate comes out.


I have mixed feelings about this: on the one hand, if this were a matter 
of public record, I would have known that this was too early to start 
complaining, and we could have saved everyone a lot of time reading 
these messages.  That would be good; I would prefer to just let everyone 
work without bothering about process.


The problem is that not enough people care about the community buildbots,
and this isn't likely to improve since we have not enough manpower to do
it.

On the other hand, it's much easier to deal with test failures as they 
arise than in one giant chunk of work at the end of the development 
process.  I spoke to a few core developers at PyCon who thought that the 
buildbots should always be green and any change that broke them should 
be reverted.  They may remain nameless unless they wish to raise their 
hands :-) but that's definitely how I feel about it.


I think no core developer will not tell you that the (core) buildbots should be
green all the time. As for reverting changes that break, I'd support this
only for changes that break *all* of them. For example, I only use one
platform to develop on (and I guess it's the same for many others), having
the buildbots go red on another platform means I can try to fix the issue.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Jeff Hall

To me (and I'm an outsider not a direct developer), it's Python developers
responsibility to handle the Python problems and the Python build bots. The
community build bots are the responsibility of their authors. If JP is
handling the Twisted one then great. It's got a gatekeeper. If no one is
handling the Django build bot that's not the Python Dev Team's problem but
is a problem on the Django side and someone involved in that should be
tasked with monitoring.

Having said all that, I agree that the community bots ought to at least be
looked at. If I check in a patch in and I notice that a community bot went
from green to red then I probably should double check my code. The problem
is that, as you said, the community bots haven't been well maintained...
They've been red for awhile. So asking the developers to then go do the leg
work to find the original error, fix it and then back check everything
between then and now that might have ALSO caused a problem is alot of
effort.

It's not the Bank's responsibility to balance my check book. They give me
the tools to do it and then I have to check. A similar principle applies
here, I believe.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Jean-Paul Calderone


On Thu, 26 Jun 2008 21:46:48 +0200, Georg Brandl [EMAIL PROTECTED] wrote:

[snip]

As for reverting changes that break, I'd support this
only for changes that break *all* of them. For example, I only use one
platform to develop on (and I guess it's the same for many others), having
the buildbots go red on another platform means I can try to fix the issue.


BuildBot has two ways to let you run your code on all builders before you
commit it to trunk.  You can force a build on a branch or you can try a
build with a patch.  I don't know if these options are enabled on Python's
buildmaster.  If they are, then if you want, you can use them to make sure
your code works on all platforms before you put it into trunk, where it may
cause problems for someone else.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 I want python developers to pay attention to the community buildbots

I don't think that goal is realistic. Instead, somebody who has actual
interest in this matter should pay this attention, and then bring it up
on python-dev when something breaks.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Terry Reedy




[EMAIL PROTECTED] wrote:


to what extent should Python actually be compatible between releases?


As I understand things from years of observation, the following are fair 
game to changed in ways possibly backward-incompatible for specific 
code: bugs, detailed float behavior (which may be system-specific 
anyway), error messages, private interfaces, non-enforcement of 
documented rules, and defined implementation-dependent behavior.  But 
Guido has been somewhat conservative about this (least so for bug fixes, 
I think) and sometimes put off changes even when the fault lies with 
questionable usages.


One fly in the ointment is that bugs (a discrepancy between doc and 
code) may be fixed either by changing the doc or the code, according to 
which embodies the design intention.  So neither can be taken as gospel.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

2008-06-26 Thread Steve Holden


Georg Brandl wrote:

[EMAIL PROTECTED] schrieb:

Another way to phrase this question is, whose responsibility is it to 
make Python 2.5 programs run on Python 2.6?  Or, what happens when 
the core team finds out that a change they have made has broken some 
python software 'in the wild'?


Here are a couple of ways to answer these questions:

  1) It's the python core team's responsibility.  There should be 
Python buildbots for lots of different projects and they should all be 
green before the code can be considered [one of: allowed in trunk, 
alpha, beta, RC].
  2) It's the python core team's responsibility as long as the major 
projects are using public APIs.  The code should not be considered 
[alpha, beta, RC] if there are any known breakages in public APIs.

 
  3) It's only the python core team's responsibility to notify 
projects of incompatible changes of which they are aware, which may 
occur in public or private APIs.  Major projects with breakages will 
be given a grace period before a [beta, RC, final] to release a 
forward-compatible version.
  4) The status quo: every new Python release can (and will, at least 
speaking in terms of 2.6) break lots of popular software, with no 
warning aside from the beta period.  There are no guarantees.


Python's backwards compatibility has never extended to non-public APIs.
That rules out 1). 2) would be nice, but to be honest, 2) and 3) are
unrealistic given the number of Python core developers and the tasks
already at hand. 4) is not acceptable either.

However, you seem to be overlooking that there's a 3.5) in there: it's
the Python core team's responsibility as long as the major projects are
using public APIs; but to reduce the workload every project should watch
its own buildbots and notify the core team using the issue tracker in
order to get the issue resolved.

At no time will a policy the community buildbots must be green be
useful: the tests that run on these buildbots are not under our control,
so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)

If, however, the community buildbot goes red because of a regression or 
backwards incompatibility the developers should, when notified, at least 
undertake to verify that the breakage is intentional.


Unfortunately having a buildbot is like installing a firewall. Some 
people assume that the very presence of the buildbot is a guard against 
version incompatibilities, whereas in truth there is always the messy 
business of communication required to ensure the information gets to 
where it is useful.


The bottom line, of course, is that if project X can't be bothered to 
tell the core development team when changes break their build it's 
nobody's fault but their own. If the report it and the core developers 
ignore the reports, that's something that should be rectified.


regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 BuildBot has two ways to let you run your code on all builders before you
 commit it to trunk.  You can force a build on a branch or you can try a
 build with a patch.  I don't know if these options are enabled on Python's
 buildmaster.  If they are, then if you want, you can use them to make sure
 your code works on all platforms before you put it into trunk, where it may
 cause problems for someone else.

Even if that's possible, it adds a burden. As likely not all people
agree that such a procedure would be a good thing, it's necessary that
somebody establishes a policy. Guido has already indicated that he is
not interested in further policies; Barry (the canonical other person
to set policies) has indicated in the past that he would like such a
policy, but deems it unrealistic at this point. He gives other
procedural changes higher priority, so that realistically, such a policy
might not be established within the next two years.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


On 07:44 pm, [EMAIL PROTECTED] wrote:

At no time will a policy the community buildbots must be green be
useful: the tests that run on these buildbots are not under our 
control,

so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)


That's not what I'm suggesting.

If there is a legitimate disagreement between Python developers and 
developers of a project about whether an API should continue to be 
supported, then clearly, the Python developers get to win.  Welcome to 
open source.


However, I believe that the core team is not paying attention to other 
projects breaking.  I'm not saying that you want to make breaking 
changes, or that bug reports are not dealt with, but the problem is that 
dealing with these problems after the fact makes it _much_ more painful. 
When you get to the release, and you have 30 bug reports due to other 
projects breaking, they get triaged, some get left in, and some features 
of lots of different projects are left broken.  And many projects do not 
bother to test with the beta.


If developers were simply presented with the results of their changes 
immediately (you broke twisted, django doesn't import, zope segfaults 
and mercurial destroys your repository) then perhaps they would weigh 
the benefits of compatibility differently, and do the trivial, obvious 
fix immediately, rather than waiting 6 months and having to figure out 
what the heck change caused the bug.  I accept the fact that python core 
development is done differently than i.e. Java development, and some 
backward compatibility may simply be broken.


Case in point: changes to the warnings module being discussed in a 
separate thread break a significant number of Twisted's tests, because 
they remove functionality which is not public but is required to test 
code that uses the warnings module.  Would Brett have taken this into 
account if he knew about it immediately when revision 62303 was 
committed?  Maybe not, but now that the code is written and done, 
there's significantly less motivation to go back and fix it.  At the 
time it might have only been a few minutes' work to continue supporting 
the use-case which Twisted needs.  Brett wouldn't even have necessarily 
needed to do the work: it would have been easier to convince a Twisted 
developer to do the work it to keep the community buildbot green rather 
than to make it a bit less red.  Now, though, it's much easier to say 
oh well, that's private, you lose.  I don't ascribe this to malice - 
it really *would* be much harder to fix it now, for us as well as for 
him.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 I don't ascribe this to malice -
 it really *would* be much harder to fix it now, for us as well as for him.

I think I disagree. It's easier to fix it now than it was to fix it back
then. Fixing it back then would have meant to constantly observe the
buildbots, and keep them running, so it would be a huge effort to
maintain the infrastructure just to find a the few changes that
unintentially broke something.

Looking at them now is a lot of effort, also. But this effort is
feasible, once the root cause is identified, the patch causing it might
just get backed out. Maintaining the community buildbots has proven
infeasible.

It's unfortunate that many package authors don't understand that not
all breakage is deliberate, and that their only chance to get undesired
breakage reverted is to report bugs NOW.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


[EMAIL PROTECTED] schrieb:

On 07:44 pm, [EMAIL PROTECTED] wrote:

At no time will a policy the community buildbots must be green be
useful: the tests that run on these buildbots are not under our 
control,

so if the tests test things we deem non-public we can't do anything
about it. (And we may have a hard time convincing project authors to
change the tests if we promised to make them run anyway.)


That's not what I'm suggesting.


Sure, but I wanted to say that nevertheless :)

If there is a legitimate disagreement between Python developers and 
developers of a project about whether an API should continue to be 
supported, then clearly, the Python developers get to win.  Welcome to 
open source.


However, I believe that the core team is not paying attention to other 
projects breaking.


Quite true. It is their duty to bring the breakage to our attention, if
they want to see results.

I'm not saying that you want to make breaking 
changes, or that bug reports are not dealt with, but the problem is that 
dealing with these problems after the fact makes it _much_ more painful. 
When you get to the release, and you have 30 bug reports due to other 
projects breaking, they get triaged, some get left in, and some features 
of lots of different projects are left broken.  And many projects do not 
bother to test with the beta.


I thought we're talking about the projects that *do* use the buildbots?

If developers were simply presented with the results of their changes 
immediately (you broke twisted, django doesn't import, zope segfaults 
and mercurial destroys your repository) then perhaps they would weigh 
the benefits of compatibility differently, and do the trivial, obvious 
fix immediately, rather than waiting 6 months and having to figure out 
what the heck change caused the bug. 


This sounds very nice in theory, but it must be implemented in a way that
does not add a burden to the developer, as Martin said.

 Case in point: changes to the warnings module being discussed in a
 separate thread break a significant number of Twisted's tests, because
 they remove functionality which is not public but is required to test
 code that uses the warnings module.  Would Brett have taken this into
 account if he knew about it immediately when revision 62303 was
 committed?  Maybe not, but now that the code is written and done,
 there's significantly less motivation to go back and fix it.  At the
 time it might have only been a few minutes' work to continue supporting
 the use-case which Twisted needs.  Brett wouldn't even have necessarily
 needed to do the work: it would have been easier to convince a Twisted
 developer to do the work it to keep the community buildbot green rather
 than to make it a bit less red.  Now, though, it's much easier to say
 oh well, that's private, you lose.  I don't ascribe this to malice -
 it really *would* be much harder to fix it now, for us as well as for
 him.

I must say that I'm increasingly surprised by this discussion since it seems
that not only the Python core devs neglect the community buildbots.
Shouldn't the project authors have at least the same interest that their
code runs on the next major Python version? And while they don't necessarily
have more time to watch the buildbots than we have, the amount of what they
need to keep an eye on.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


Terry Reedy schrieb:


[EMAIL PROTECTED] wrote:


to what extent should Python actually be compatible between releases?


As I understand things from years of observation, the following are fair 
game to changed in ways possibly backward-incompatible for specific 
code: bugs, detailed float behavior (which may be system-specific 
anyway), error messages, private interfaces, non-enforcement of 
documented rules, and defined implementation-dependent behavior.  But 
Guido has been somewhat conservative about this (least so for bug fixes, 
I think) and sometimes put off changes even when the fault lies with 
questionable usages.


Which is the source of many unresolved open issues in the tracker -- everyone
agrees that it is a bug and should be fixed, perhaps there's even a patch,
but people may be using it this way, so nothing is done forever.

(And these bugs usually are the kind of things we don't want to change in
3.0 either since they are subtle things.)

However, I don't have a solution here, so I won't complain about it anymore.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 26, 2008, at 11:42 AM, Nick Coghlan wrote:

If the community buildbots aren't largely green by the time beta 2  
comes out, that's when I'll agree we have a problem - they should  
definitely be green by the time first release candidate comes out.


Just FTR,

I'll be looking at the Python buildbots and Roundup tracker to decide  
whether I think beta2 is in shape to be released or not.  I definitely  
won't be tracking the non-core buildbots, so if something troublesome  
comes up there, you will have to submit a bug report to the Python  
tracker.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGQEu3EjvBPtnXfVAQIp6QP/bOU+8vImlRkfKCXazYhi3yEXcNwCPpWI
e3AoiOlgKbOhSPraNTyUBjC+OjuqHQttyMJz8TTpexSwhpG/erDIqUjRbkW0Yaas
attvFZBYbJhF3qvHyLzmSp9U3oXY6VyWayL8ZdzIGcukEW7g8DgQNQyoGOE4kEeX
i6+4RIRf+7A=
=X1lh
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 26, 2008, at 12:54 PM, [EMAIL PROTECTED] wrote:


On 04:42 pm, [EMAIL PROTECTED] wrote:
On Thu, Jun 26, 2008 at 5:33 PM, Guido van Rossum  
[EMAIL PROTECTED] wrote:

an explanation about *why* Django cannot even be imported than a
blanket complaint that this is a disgrace. So why is it?



and already discussed:
http://mail.python.org/pipermail/python-dev/2008-April/078421.html


Following that trail of breadcrumbs, I ended up here:

  http://bugs.python.org/issue2235

with a message from some guy named Barry Warsaw (anyone know him?)  
that says:



Guido, can you comment on Amaury's latest patch?  I'm going to bump  
this
back to critical so as not to hold up 2.6 alpha, but it should be  
marked

as a release blocker for the first beta.


I don't know if this Barry guy has the appropriate permissions on  
the bugtracker to increase priorities, so I've taken the liberty of  
upgrading it as a release blocker for the _second_ beta ... ;-).   
So, at least there's been one productive consequence of this  
discussion.


Glyph, you did the right thing.  I wish there was a way of marking a  
bug not-release-blocker-for-now and have it automatically update  
back to blocker at a certain time or after a certain event.


I think it's valid for this issue to block beta2.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGQF0XEjvBPtnXfVAQJwiQP/T9f33lNtAQ9/eooKEyVCDms7NXJE7mIf
QPOQtXuTZdsfUl51OxkxewVj6ERZasHPwIB2c13HYuHRrMrmrE9EYStdbmMxh0BI
7EhsO4SfDI3ZnYFJvAEMrTvgY8Vz4v817LhzWNZ7RWxq/yOHG8C/ZgubPJIa8mnd
EGWUVoLg77E=
=OJHh
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 12:35 PM,  [EMAIL PROTECTED] wrote:

 On 05:14 pm, [EMAIL PROTECTED] wrote:

 I don't know.  JP is already addressing the issues affecting Twisted in
 another thread (incompatible changes in the private-but-necessary-to-
 get-any-testing-done API of the warnings module).  But I really think
 that whoever made the change which broke it should be the one
 investigating it, not me.

 How could they have known that they broke it?

 Because the relevant community buildbot turned red with that revision of
 trunk.  Keep in mind I'm not talking about every piece of Python code in the
 universe; just the ones selected for the community buildbots.  It would be
 nice if there were a dozen or so projects on there, but paying attention to
 the two builders that do actually run right now would be a good start.

Sorry, this is an unacceptable burden on the core developers. The core
developers aren't going to look at the community buildbots (unless
voluntarily) and they aren't going to roll back changes just because
some community buildbot goes red.

In general someone outside the core developer group needs to bring the
issue to the core developers' attention and then a fix will be created
if appropriate. Rollbacks are generally reserved for accidental
checkins or checkins against the process rules (e.g. during a code
freeze). Heck, we don't even roll back if one of our own buildbots
goes red.

I'm fine with requesting that the core developers pay serious
attention to reports about 3rd party code being broken. The community
buildbots are a fine tool to find out about this. But any policy that
requires an automatic rollback because a buildbot (community or core)
goes red is unacceptable.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


Barry Warsaw schrieb:

I don't know if this Barry guy has the appropriate permissions on  
the bugtracker to increase priorities, so I've taken the liberty of  
upgrading it as a release blocker for the _second_ beta ... ;-).   
So, at least there's been one productive consequence of this  
discussion.


Glyph, you did the right thing.  I wish there was a way of marking a  
bug not-release-blocker-for-now and have it automatically update  
back to blocker at a certain time or after a certain event.


I think it's valid for this issue to block beta2.


I just added a deferred blocker priority -- that implements one half
of your wish. Mass issue updating must be done by someone who knows
Roundup better than me, I'm afraid.

Georg

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 1:06 PM,  [EMAIL PROTECTED] wrote:
 On 07:44 pm, [EMAIL PROTECTED] wrote:

 At no time will a policy the community buildbots must be green be
 useful: the tests that run on these buildbots are not under our control,
 so if the tests test things we deem non-public we can't do anything
 about it. (And we may have a hard time convincing project authors to
 change the tests if we promised to make them run anyway.)

 That's not what I'm suggesting.

 If there is a legitimate disagreement between Python developers and
 developers of a project about whether an API should continue to be
 supported, then clearly, the Python developers get to win.  Welcome to open
 source.

 However, I believe that the core team is not paying attention to other
 projects breaking.  I'm not saying that you want to make breaking changes,
 or that bug reports are not dealt with, but the problem is that dealing with
 these problems after the fact makes it _much_ more painful. When you get to
 the release, and you have 30 bug reports due to other projects breaking,
 they get triaged, some get left in, and some features of lots of different
 projects are left broken.  And many projects do not bother to test with the
 beta.

Well, sorry, that's life. We're not going to deal with breakage in 3rd
party code on a drop all other work basis.

You seem to have a different idea about how to do development than the
core developers. Tough luck. You can't tell us how to do our work.
We're doing the best we can, and we're happy to listen to suggestions
you're making, but the set of suggestions you're making in this thread
are an unacceptable burden, and it's not going to happen.

 If developers were simply presented with the results of their changes
 immediately (you broke twisted, django doesn't import, zope segfaults and
 mercurial destroys your repository) then perhaps they would weigh the
 benefits of compatibility differently, and do the trivial, obvious fix
 immediately, rather than waiting 6 months and having to figure out what the
 heck change caused the bug.  I accept the fact that python core development
 is done differently than i.e. Java development, and some backward
 compatibility may simply be broken.

 Case in point: changes to the warnings module being discussed in a separate
 thread break a significant number of Twisted's tests, because they remove
 functionality which is not public but is required to test code that uses the
 warnings module.  Would Brett have taken this into account if he knew about
 it immediately when revision 62303 was committed?  Maybe not, but now that
 the code is written and done, there's significantly less motivation to go
 back and fix it.

I disagree. It's broken and should be fixed. Beta 1 just came out so
this is the perfect time to file a bug.

 At the time it might have only been a few minutes' work to
 continue supporting the use-case which Twisted needs.  Brett wouldn't even
 have necessarily needed to do the work: it would have been easier to
 convince a Twisted developer to do the work it to keep the community
 buildbot green rather than to make it a bit less red.

Why? That sounds like it's a problem with the psychology of the
Twisted developers.

 Now, though, it's
 much easier to say oh well, that's private, you lose.  I don't ascribe
 this to malice - it really *would* be much harder to fix it now, for us as
 well as for him.

I don't believe this.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 26, 2008, at 5:20 PM, Georg Brandl wrote:


Barry Warsaw schrieb:

I don't know if this Barry guy has the appropriate permissions  
on  the bugtracker to increase priorities, so I've taken the  
liberty of  upgrading it as a release blocker for the _second_  
beta ... ;-).   So, at least there's been one productive  
consequence of this  discussion.
Glyph, you did the right thing.  I wish there was a way of marking  
a  bug not-release-blocker-for-now and have it automatically  
update  back to blocker at a certain time or after a certain event.

I think it's valid for this issue to block beta2.


I just added a deferred blocker priority -- that implements one half
of your wish. Mass issue updating must be done by someone who knows
Roundup better than me, I'm afraid.


Cool, thanks!  I should have thought of that before.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGQNm3EjvBPtnXfVAQIy1wP/QPFwklmnay8VPPovHA6H4XA6tW+ziWPV
hbeyAZX/MMxEYv/98Z4nOQU7M4AczlXHZks80UvDdKLwPe2wTwfOIgmCTeb+vciI
20GpxrHpWQNHy/XKeawEBxyLHJZ4qNGIAFmHwoiUusM6erTeVb9kWa0czG31En6r
Z4MV0YKfu+A=
=Zxh4
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

 I just added a deferred blocker priority -- that implements one half
 of your wish. Mass issue updating must be done by someone who knows
 Roundup better than me, I'm afraid.

I doubt true mass update will be necessary. If you remind me that I
should convert all deferred blocker issues to some other priority,
I'll do that manually in a matter of minutes (using a query to find
all issues with that priority).

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics

On Thu, Jun 26, 2008 at 8:45 PM, Guido van Rossum [EMAIL PROTECTED] wrote:

 So you're saying py.test needs to be fixed? Fine with me, but then I
 don't understand why you bothered bringing it up here instead of
 fixing it (or reporting to the py.test maintainers, I don't know if
 you're one or not).


no, I'm not. Just wanted to point out, that this ticket/patch does not
solve the django issue.
(this is what I first thought it would do).

- Ralf
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Jun 26, 2008, at 5:54 PM, Martin v. Löwis wrote:

I just added a deferred blocker priority -- that implements one  
half

of your wish. Mass issue updating must be done by someone who knows
Roundup better than me, I'm afraid.


I doubt true mass update will be necessary. If you remind me that I
should convert all deferred blocker issues to some other priority,
I'll do that manually in a matter of minutes (using a query to find
all issues with that priority).


Martin, I think that will work great.  The idea being that after each  
release, we always bump deferred blockers back to release blocker.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSGQZbHEjvBPtnXfVAQIwWQQAqWoIoqV0S0O8ZpkXpWd3LO4Fo7MBfjRT
LL5QgIPBWdQdZ4RR68LSfdAhiHGnZCZorpNksGaeIxP55qgS1z31fy3JF39UUbVR
3ojymtF6Is0qCB5lmkJIx9Na/2RUEOUWTQoQP3dG851oRRuSVTXb4uRaBlNlQErY
oN9JxG5xQR0=
=z9nN
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics



On 09:17 pm, [EMAIL PROTECTED] wrote:

On Thu, Jun 26, 2008 at 12:35 PM,  [EMAIL PROTECTED] wrote:


Because the relevant community buildbot turned red with that revision 
of
trunk.  Keep in mind I'm not talking about every piece of Python code 
in the
universe; just the ones selected for the community buildbots.  It 
would be
nice if there were a dozen or so projects on there, but paying 
attention to

the two builders that do actually run right now would be a good start.


Sorry, this is an unacceptable burden on the core developers. The core
developers aren't going to look at the community buildbots (unless
voluntarily) and they aren't going to roll back changes just because
some community buildbot goes red.


OK, fair enough.  Taking a step back, I was pushing this really hard 
because to *me*, it seems like dealing with the influx of bug reports 
after the fact is an unreasonable amount of additional work, whereas 
immediate reverts are just an occasional, temporary inconvenience. 
Based on my experience, We'll deal with the reports as they come in 
sounds like no.

In general someone outside the core developer group needs to bring the
issue to the core developers' attention and then a fix will be created
if appropriate. Rollbacks are generally reserved for accidental
checkins or checkins against the process rules (e.g. during a code
freeze). Heck, we don't even roll back if one of our own buildbots
goes red.


I think since the last time we had a similar conversation, other Twisted 
developers have been fairly diligent in reporting bugs.  (In the time 
they've been reporting Python bugs, I've mostly been planning a wedding. 
Others who have survived it tell me that eventually, this process 
ends... and then I should be participating more directly.)  I'll try to 
step up that feeback loop and get other projects involved.  I hope I am 
wrong about generating an unreasonable amount of work.

I'm fine with requesting that the core developers pay serious
attention to reports about 3rd party code being broken. The community
buildbots are a fine tool to find out about this. But any policy that
requires an automatic rollback because a buildbot (community or core)
goes red is unacceptable.


Thanks.  I appreciate it; an increased emphasis on 3rd party code being 
broken is really what I was looking for.  This is fine with me.  I mean, 
whatever your decision is, I'm going to have to live with it :), but in 
either case, we have to be looking for bugs and helping to investigate 
them.  On my end of things I guess it's not going to make much 
difference.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots and Python release quality metrics


On 26 Jun, 09:24 pm, [EMAIL PROTECTED] wrote:

On Thu, Jun 26, 2008 at 1:06 PM,  [EMAIL PROTECTED] wrote:

On 07:44 pm, [EMAIL PROTECTED] wrote:



Well, sorry, that's life. We're not going to deal with breakage in 3rd
party code on a drop all other work basis.


For the record, automatic revert does not mean drop all other work. 
The changeset's still there.  It's still in the revision history.  It 
can easily be applied to anybody's working copy.  It can easily be put 
into a branch.  It can be automatically re-merged later.  I do all of 
these things all the time, and I was *not* intending to suggest that any 
3rd-party breakage should cause a code freeze or anything even remotely 
like that.

Case in point: changes to the warnings module



I disagree. It's broken and should be fixed. Beta 1 just came out so
this is the perfect time to file a bug.


I'll go back over the recent conversation and work out the specifics of 
the bug (if JP doesn't, or hasn't already beaten me to it).

(...) it would have been easier to
convince a Twisted developer to do the work it to keep the community
buildbot green rather than to make it a bit less red.


Why? That sounds like it's a problem with the psychology of the
Twisted developers.


I hardly think it's unique to us.  TDD test runners typically only know 
2 colors and 2 states: passed and fails.  Once you're in the fail 
state, you tend to accumulate more failures; there's a much bigger bang 
for your buck.  Better tools with nicer interfaces would let you easily 
mark individual tests as usually intermittent or something and make it 
a slightly dirty green or something, but we don't have those.  The 
move from red to green is much more psychologically significant to 
just about anyone I know than the move from red but 14 failures to 
red but 12 failures.


Despite the idea's origins in a now-highly-controversial book on 
criminology, this is often referred to in XP discussion circles (wikis 
and the like) as the fix broken windows collaboration pattern.  I 
notice this in lots of other areas of my life; a little pile of papers 
tends to become a big pile of papers, the first dent in a car makes the 
driver a little less careful, and so on.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Community buildbots

2008-05-07 Thread Jean-Paul Calderone


Hi,

I just wanted to point out a few things:

Community 2.5 bots, 6 out of 8 offline, of the remaining two (which are both
red), one is actually using Python 2.6, not Python 2.5:

 http://python.org/dev/buildbot/community/2.5/

Community 2.6 bots, 6 out of 8 offline, but at least the remaining two (both
of which are red) seem to be using the correct Python version:

 http://python.org/dev/buildbot/community/trunk/

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Grig Gheorghiu

Hi,

This message is in response to Glyph's plea
(http://mail.python.org/pipermail/python-dev/2006-July/067366.html).

Here's what Glyph said:

I would like to propose, although I certainly don't have time to
implement, a program by which Python-using projects could contribute
buildslaves which would run their projects' tests with the latest
Python trunk.  This would provide two useful incentives: Python code
would gain a reputation as generally well-tested (since there is a
direct incentive to write tests for your project: get notified when
core python changes might break it), and the core developers would have
instant feedback when a small change breaks more code than it was
expected to.


I'm volunteering to organize this effort, is there is enough interest
on this list. In fact, I've done some prep work already:

 * got a domain name: pybots.org
 * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root access
and everything); it's available at master.pybots.org, and it's ready to
be configured as a buildmaster for the pybots
 * got a mailing list: [EMAIL PROTECTED]

I can start configuring the Ubuntu machine as a buildmaster, and I can
also add a buildslave on the same machine that will check out the
latest Python trunk code, build it, then run the automated tests for a
sample project -- let's say for Twisted, since Glyph was the one
requesting this. This will also serve as a sample buildslave for other
people who will be interested in running buildslaves for their own
projects.

Apart from the goals stated by Glyph, I see this as a very valuable
effort in convincing people of the value of automated tests,
Python-related or not. A secondary effect I'd like to see would be for
these suites of tests to be invoked in a standard fashion -- maybe
'python setup.py test'.

If PSF can contribute some $$$ towards the hosting of the master
server, that would be appreciated, but not required. All that's
required is enough interest from the community.

Please let me know if you're interested.

Grig


http://agiletesting.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Neal Norwitz

If you want I can send you the build master cfg I setup on python.org
and some simple instructions for how to connect to it.  I don't have
time to focus on this at the moment and probably won't until 2.5 is
out.

n
--

On 7/20/06, Grig Gheorghiu [EMAIL PROTECTED] wrote:
 Hi,

 This message is in response to Glyph's plea
 (http://mail.python.org/pipermail/python-dev/2006-July/067366.html).

 Here's what Glyph said:

 I would like to propose, although I certainly don't have time to
 implement, a program by which Python-using projects could contribute
 buildslaves which would run their projects' tests with the latest
 Python trunk.  This would provide two useful incentives: Python code
 would gain a reputation as generally well-tested (since there is a
 direct incentive to write tests for your project: get notified when
 core python changes might break it), and the core developers would have
 instant feedback when a small change breaks more code than it was
 expected to.


 I'm volunteering to organize this effort, is there is enough interest
 on this list. In fact, I've done some prep work already:

  * got a domain name: pybots.org
  * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root access
 and everything); it's available at master.pybots.org, and it's ready to
 be configured as a buildmaster for the pybots
  * got a mailing list: [EMAIL PROTECTED]

 I can start configuring the Ubuntu machine as a buildmaster, and I can
 also add a buildslave on the same machine that will check out the
 latest Python trunk code, build it, then run the automated tests for a
 sample project -- let's say for Twisted, since Glyph was the one
 requesting this. This will also serve as a sample buildslave for other
 people who will be interested in running buildslaves for their own
 projects.

 Apart from the goals stated by Glyph, I see this as a very valuable
 effort in convincing people of the value of automated tests,
 Python-related or not. A secondary effect I'd like to see would be for
 these suites of tests to be invoked in a standard fashion -- maybe
 'python setup.py test'.

 If PSF can contribute some $$$ towards the hosting of the master
 server, that would be appreciated, but not required. All that's
 required is enough interest from the community.

 Please let me know if you're interested.

 Grig

 
 http://agiletesting.blogspot.com
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-25 Thread Grig Gheorghiu

On 7/25/06, Neal Norwitz [EMAIL PROTECTED] wrote:
If you want I can send you the build master cfg I setup on python.organd some simple instructions for how to connect to it.I don't havetime to focus on this at the moment and probably won't until 
2.5 isout.n--Sure. I'm still a bit unclear on whether you want me to coordinate this
by adding buildslaves to the build master cfg, adding build steps etc.
I'll gladly do it if you need help. I'll need access to the server and
proper permissions of course.

Grig
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-22 Thread Martin v. Löwis

Grig Gheorghiu wrote:
 Please let me know if you're interested.

As I said earlier: If you need some kind of post-commit
trigger on the python repository to trigger a build, just
let me know. We currently use a more-or-less plain
svn_buildbot.py to trigger our own builds.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-22 Thread Grig Gheorghiu

On 7/22/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Grig Gheorghiu wrote: Please let me know if you're interested.As I said earlier: If you need some kind of post-committrigger on the python repository to trigger a build, justlet me know. We currently use a more-or-less plain
svn_buildbot.py to trigger our own builds.Wouldn't that put too much of a burden on the python core build system? It would have to be aware of all the buildslaves running specific projects. 
I was thinking about having a dedicated buildmaster machine, such as the one Neal says he already has, and configure that machine to coordinate a small army of buildslaves which will be contributed for people interested in this effort.
Grig
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-22 Thread Martin v. Löwis

Grig Gheorghiu wrote:
 As I said earlier: If you need some kind of post-commit
 trigger on the python repository to trigger a build, just
 let me know. We currently use a more-or-less plain
 svn_buildbot.py to trigger our own builds.
 
 Wouldn't that put too much of a burden on the python core build system?
 It would have to be aware of all the buildslaves running specific projects.

If there is a single community buildbot, then no. In any case, it's
primarily administrative overhead, not so much cycles. python.org does
so many things simultaneously, making it trigger an additional build
remotely doesn't hurt.

 I was thinking about having a dedicated buildmaster machine, such as the
 one Neal says he already has, and configure that machine to coordinate a
 small army of buildslaves which will be contributed for people
 interested in this effort.

Right. You still need to find out when to rebuild, and getting triggers
from the source repositories is likely the easiest solution.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-22 Thread Grig Gheorghiu

On 7/22/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Grig Gheorghiu wrote: As I said earlier: If you need some kind of post-commit trigger on the python repository to trigger a build, just let me know. We currently use a more-or-less plain
svn_buildbot.py to trigger our own builds. Wouldn't that put too much of a burden on the python core build system? It would have to be aware of all the buildslaves running specific projects.
If there is a single community buildbot, then no. In any case, it'sprimarily administrative overhead, not so much cycles. python.org doesso many things simultaneously, making it trigger an additional build
remotely doesn't hurt. I was thinking about having a dedicated buildmaster machine, such as the one Neal says he already has, and configure that machine to coordinate a small army of buildslaves which will be contributed for people
interested in this effort.Right. You still need to find out when to rebuild, and getting triggersfrom the source repositories is likely the easiest solution.I seeI guess I was thinking about building periodically (every X hours or at time Y) as opposed to getting svn triggers on each check-in. But if, as you're saying, the overhead on
python.org is not too great, we can do what you suggested.Grig-- http://agiletesting.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Grig Gheorghiu

Hi,This message is in response to Glyph's plea(http://mail.python.org/pipermail/python-dev/2006-July/067366.html
).Here's what Glyph said:I would like to propose, although I certainly don't have time toimplement, a program by which Python-using projects could contributebuildslaves which would run their projects' tests with the latest
Python trunk.  This would provide two useful incentives: Python codewould gain a reputation as generally well-tested (since there is adirect incentive to write tests for your project: get notified whencore python changes might break it), and the core developers would have
instant feedback when a small change breaks more code than it wasexpected to.I'm volunteering to organize this effort, is there is enough intereston this list. In fact, I've done some prep work already:
 * got a domain name: pybots.org * got a $47/month Ubuntu-based VPS from JohnCompanies.com (root accessand everything); it's available at 
master.pybots.org, and it's ready tobe configured as a buildmaster for the pybots * got a mailing list: 
[EMAIL PROTECTED]I can start configuring the Ubuntu machine as a buildmaster, and I canalso add a buildslave on the same machine that will check out thelatest Python trunk code, build it, then run the automated tests for a
sample project -- let's say for Twisted, since Glyph was the onerequesting this. This will also serve as a sample buildslave for otherpeople who will be interested in running buildslaves for their ownprojects.
Apart from the goals stated by Glyph, I see this as a very valuableeffort in convincing people of the value of automated tests,Python-related or not. A secondary effect I'd like to see would be forthese suites of tests to be invoked in a standard fashion -- maybe
'python setup.py test'.If PSF can contribute some $$$ towards the hosting of the masterserver, that would be appreciated, but not required. All that'srequired is enough interest from the community.
Please let me know if you're interested.Grig-- 
http://agiletesting.blogspot.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Jean-Paul Calderone

On Fri, 21 Jul 2006 10:04:38 -0700, Grig Gheorghiu [EMAIL PROTECTED] wrote:
Hi,

Apart from the goals stated by Glyph, I see this as a very valuable
effort in convincing people of the value of automated tests,
Python-related or not. A secondary effect I'd like to see would be for
these suites of tests to be invoked in a standard fashion -- maybe
'python setup.py test'.

If PSF can contribute some $$$ towards the hosting of the master
server, that would be appreciated, but not required. All that's
required is enough interest from the community.

Please let me know if you're interested.


This is certainly interesting to me.  If you need any help setting up
the Twisted buildslave, please let me know.

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots -- reprise

2006-07-21 Thread Neal Norwitz

I have a server up and running.  I still need to polish some stuff
off.  I will mail more info when I get a chance.

n
--

On 7/21/06, Jean-Paul Calderone [EMAIL PROTECTED] wrote:
 On Fri, 21 Jul 2006 10:04:38 -0700, Grig Gheorghiu [EMAIL PROTECTED] wrote:
 Hi,
 
 Apart from the goals stated by Glyph, I see this as a very valuable
 effort in convincing people of the value of automated tests,
 Python-related or not. A secondary effect I'd like to see would be for
 these suites of tests to be invoked in a standard fashion -- maybe
 'python setup.py test'.
 
 If PSF can contribute some $$$ towards the hosting of the master
 server, that would be appreciated, but not required. All that's
 required is enough interest from the community.
 
 Please let me know if you're interested.
 

 This is certainly interesting to me.  If you need any help setting up
 the Twisted buildslave, please let me know.

 Jean-Paul
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
 http://mail.python.org/mailman/options/python-dev/nnorwitz%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-17 Thread Anthony Baxter

On Friday 14 July 2006 22:45, Jeremy Hylton wrote:
 Maybe the basic question is right, but the emphasis needs to be
 changed.  If we had a rule that said the final release was 90 days
 after the last submission that wasn't to fix a regression, we'd ask
 Is this feature important enough to warrant delaying the release
 until three months from now?  I'm not sure what I think, but it
 doesn't seem like an implausible policy.

I really really doubt that this would work. There's always pressure 
for just one more feature - and as the release drags on, this would 
increase, not decrease. Note that dragging the release process out 
has it's own costs, as mentioned previously - either the trunk is in 
some sort of near-frozen state for an extended period, or else we end 
up in the double-applying-bugfixes state by forking much earlier. 

This approach would also make it extremely difficult to plan for 
releases. I know that my free time varies across the course of the 
year, and I need _some_ sort of plan for when the release will happen 
so I can make sure I have the time free to spend on it. 

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-17 Thread Andrew MacIntyre

Anthony Baxter wrote:
 On Friday 14 July 2006 22:45, Jeremy Hylton wrote:
 Maybe the basic question is right, but the emphasis needs to be
 changed.  If we had a rule that said the final release was 90 days
 after the last submission that wasn't to fix a regression, we'd ask
 Is this feature important enough to warrant delaying the release
 until three months from now?  I'm not sure what I think, but it
 doesn't seem like an implausible policy.
 
 I really really doubt that this would work. There's always pressure 
 for just one more feature - and as the release drags on, this would 
 increase, not decrease. Note that dragging the release process out 
 has it's own costs, as mentioned previously - either the trunk is in 
 some sort of near-frozen state for an extended period, or else we end 
 up in the double-applying-bugfixes state by forking much earlier. 
 
 This approach would also make it extremely difficult to plan for 
 releases. I know that my free time varies across the course of the 
 year, and I need _some_ sort of plan for when the release will happen 
 so I can make sure I have the time free to spend on it. 

On the face of it, it seems to me that branching a new major release at
the 1st beta would be one way of managing this.  The trunk is not frozen
for an extended period, and any features and bug fixes could probably
be backported from the trunk on clearance from the RE with no more pain
than is currently endured.

One down side would be the possibility of a loss in emphasis in finishing
the job on the release to be.  I'm sure there are others...

-
Andrew I MacIntyre These thoughts are mine alone...
E-mail: [EMAIL PROTECTED]  (pref) | Snail: PO Box 370
[EMAIL PROTECTED] (alt) |Belconnen ACT 2616
Web:http://www.andymac.org/   |Australia
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-17 Thread Anthony Baxter

On Monday 17 July 2006 20:27, Andrew MacIntyre wrote:
 On the face of it, it seems to me that branching a new major
 release at the 1st beta would be one way of managing this.  The
 trunk is not frozen for an extended period, and any features and
 bug fixes could probably be backported from the trunk on clearance
 from the RE with no more pain than is currently endured.

 One down side would be the possibility of a loss in emphasis in
 finishing the job on the release to be.  I'm sure there are
 others...

The major one is the doubling of the workload for bugfixes. SVN is 
better than CVS, but it's still not great when it comes to 
backporting fixes between branches.

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-15 Thread Jeroen Ruigrok van der Werven

On 7/14/06, Anthony Baxter [EMAIL PROTECTED] wrote:
 The community buildbot idea is a good one, although it should just
 be possible to write something for buildbot that checks out and
 builds the latest Python SVN, then installs it to a temporary
 location, then adds that location to the front of the path. Then each
 project could just add a Python SVN buildbot to their exists bbot
 install.

This is what Xenofarm for Pike has done for a long time now. See for
example: http://pike.ida.liu.se/development/pikefarm/7.7.xml

This is also what Bitten (http://bitten.cmlenz.net/) has implemented
for Trac (which is one of the bug/incident trackers for Python's call
for trackers).

-- 
Jeroen Ruigrok van der Werven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Terry Reedy wrote:
 That is the goal, but when I watched the buildbot results last spring, the 
 degree of stability (greenness) appeared to vary.  Is it possible to tag 
 particular versions as a 'green' version, or the 'most recent green 
 version' worth playing with?

Don't get confused by these colors. The tree compiled nearly all of the
time, even if some tests were failing for an extended period of time on
some platforms.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Jeroen Ruigrok van der Werven wrote:
 This is what Xenofarm for Pike has done for a long time now. See for
 example: http://pike.ida.liu.se/development/pikefarm/7.7.xml
 
 This is also what Bitten (http://bitten.cmlenz.net/) has implemented
 for Trac (which is one of the bug/incident trackers for Python's call
 for trackers).

Are you aware of http://www.python.org/dev/buildbot/ ?
We are not just talking about buildbots here (which the links you refer
to seem to be); we are talking about buildbots that don't test Python,
but test Python applications. We do know how to run a buildbot.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

[EMAIL PROTECTED] wrote:
 python -U is a failure for obvious reasons and a
 __future__ import is clearly better.
 I disagree.
 
 I am surprised that you do, since I thought that Chris's conclusion was 
 pretty obvious.  Python -U doesn't work, even on the standard library.

Sure, it doesn't work. That doesn't mean it's a failure. It just
hasn't been completed yet.

 A __future__ import would allow these behaviors to be upgraded 
 module-by-module.
 Right now, all -U provides is an option that can't be used on any 
 realistically
 sized program, so I don't see what the utility is.

People can use it to improve the Unicode support in the Python standard
library. When they find that something doesn't work, they can study the
problem, and ponder possible solutions. Then, they can contribute
patches. -U has worked fine for me in the past, I contributed various
patches to make it work better. It hasn't failed for me at all.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-15 Thread Jeroen Ruigrok van der Werven

On 7/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Are you aware of http://www.python.org/dev/buildbot/ ?

Yes. And it does not seem to be open for all, but then again, any
documentation with regard to it seems to be very sparse or hidden so I
can very well be wrong here. Ah, hidden away on the wiki:
http://wiki.python.org/moin/BuildBot

 We are not just talking about buildbots here (which the links you refer
 to seem to be); we are talking about buildbots that don't test Python,
 but test Python applications.

Then I would dare to say you haven't fully investigated the links
fully, Bitten, for example, also runs the unit-tests for any target
you configure, saves all the outputs and provides quick overviews as
well as coverage statistics. So that would fall perfectly into that
category. See http://bitten.cmlenz.net/build/0.5.x/762 for an example.

 We do know how to run a buildbot.

How relevant was this comment in the entire? I am merely trying to
help out here pointing out other similar projects when the community
participating building issue was raised.

-- 
Jeroen Ruigrok van der Werven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

Jeroen Ruigrok van der Werven wrote:
 Are you aware of http://www.python.org/dev/buildbot/ ?
 
 Yes. And it does not seem to be open for all

Ah, ok. It indeed isn't open for anonymous participation; the test
results are open for all, though.

 
 We are not just talking about buildbots here (which the links you refer
 to seem to be); we are talking about buildbots that don't test Python,
 but test Python applications.
 
 Then I would dare to say you haven't fully investigated the links
 fully, Bitten, for example, also runs the unit-tests for any target
 you configure

I don't understand that comment. Bitten seems to be a software package,
similar to buildbot. It doesn't do anything useful until I install and
configure it, unlike, say, SourceForge, which is not (just) a soft
package, but a running installation of it also. Right?

The effort is in installing and configuring it, given that many such
packages are already written. Distributed testing frameworks typically
support running arbitrary target comments, so Bitten is not really
special here (buildbot can also run about anything if you configure
it to).

 We do know how to run a buildbot.
 
 How relevant was this comment in the entire? I am merely trying to
 help out here pointing out other similar projects when the community
 participating building issue was raised.

It would have been helpful if you had stated *why* you think these
URLs are relevant in the context of the discussion. To me, it seemed
you are pointing to the existence of distributed testing frameworks.
I was pointing out that we (at least, I) am aware of the existence
of such frameworks, and that we were doing it for quite some time
now also, just like Pike.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread Aahz

On Thu, Jul 13, 2006, Talin wrote:

 Actually - can we make new-style classes the default, but allow a
 way to switch to old-style classes if needed? Perhaps a command-line
 argument to set the default back to old-style?

Nope.  Python 3.0 will have new-style classes as the default, but there
will probably not be any way to use old-style classes.  As has been said
before, if you want to make new-style classes the default for any module,
just put

__metaclass__ = type

at the top.

Please, just drop this subject.  Guido has long since Pronounced.
-- 
Aahz ([EMAIL PROTECTED])   * http://www.pythoncraft.com/

Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.  --Brian W. Kernighan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread glyph



On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy [EMAIL PROTECTED] wrote:

Is the following something like what you are suggesting?

Something like it, but...

A Python Application Testing (PAT) machine is set up with buildbot and any
needed custom scripts.  Sometime after that and after 2.5 is released, when
you have a version of, for instance, Twisted that passes its automated test
suite when run on 2.5, you send it (or a URL) and an email address to PAT.
Other developers do the same.  Periodically (once a week?), when PAT is
  ^
 once per checkin to Python trunk
free and a new green development version of either the 2.5.x or 2.6
branches is available, PAT runs the test suites against that version.  An
email is sent for any that fail, perhaps accompanied by the concatenation
of the relevant checkin message.  Some possible options are to select just
one of the branches for testing, to have more than one stable version being
tested, and to receive pass emails.

Sending email also isn't really necessary; I would just like a web page I can
look at (and draw the attention of the python core developers to).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread glyph

On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
A __future__ import would allow these behaviors to be upgraded module-by- 
module.

No it wouldn't.

Yes it would! :)

__future__ works solely on the semantics of different pieces of syntax, 
because any syntax changes are purely local to the current module.
...
Changing all the literals in a module to be unicode instances instead of str 
instances is merely scratching the surface of the problem - such a module 
would still cause severe problems for any non-Unicode aware applications 
that expected it to return strings.

A module with the given __future__ import could be written to expect that
literals are unicode instances instead of str, and encode them appropriately
when passing to modules that expect str.  This doesn't solve the problem, but
unlike -U, you can make fixes which will work persistently without having to
treat the type of every string literal as unknown.

The obvious way to write code that works under -U and still works in normal
Python is to .encode('charmap') every value intended to be an octet, and put
'u' in front of every string intended to be unicode.  That would seem to
defeat the purpose of changing the default literal type.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread glyph

On Sat, 15 Jul 2006 10:43:22 +0200, \Martin v. Löwis\ [EMAIL PROTECTED] 
wrote:

People can use [-U] to improve the Unicode support in the Python standard
library. When they find that something doesn't work, they can study the
problem, and ponder possible solutions. Then, they can contribute
patches. -U has worked fine for me in the past, I contributed various
patches to make it work better. It hasn't failed for me at all.

I guess it makes more sense as a development tool to work on zero-dependency
tools like the standard library.  Still, -Q has both a __future__ import and
a command-line option, why not -U?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread James Y Knight

On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
 Note that it also helps setting the default encoding
 to 'unknown'. That way you disable the coercion of strings
 to Unicode and all the places where this implicit conversion
 takes place crop up, allowing you to take proper action (i.e.
 explicit conversion or changing of the string to Unicode
 as appropriate).

I've tried that before to verify no such conversion issues occurred  
in Twisted, but, as the python stdlib isn't usable like that, it's  
hard to use it to find bugs in any other libraries. (in particular,  
the re module is badly broken, some other stuff was too).

James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread M.-A. Lemburg

James Y Knight wrote:
 On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
 Note that it also helps setting the default encoding
 to 'unknown'. That way you disable the coercion of strings
 to Unicode and all the places where this implicit conversion
 takes place crop up, allowing you to take proper action (i.e.
 explicit conversion or changing of the string to Unicode
 as appropriate).
 
 I've tried that before to verify no such conversion issues occurred in
 Twisted, but, as the python stdlib isn't usable like that, it's hard to
 use it to find bugs in any other libraries. (in particular, the re
 module is badly broken, some other stuff was too).

True: it breaks a lot of code that was written to work
with both strings and Unicode (or does so by accident ;-).

The stdlib isn't too well prepared for Unicode yet, so
if your code relies a lot on it, then the above may not
be the right strategy for you.

Perhaps a new ASCII codec that issues warnings for all these
cases would help ?! (one that still converts to Unicode
assuming ASCII, but issues a warning pointing to the location
in the code where the conversion happend)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jul 15 2006)
 Python/Zope Consulting and Support ...http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

[EMAIL PROTECTED] wrote:
 A module with the given __future__ import could be written to expect that
 literals are unicode instances instead of str, and encode them appropriately
 when passing to modules that expect str.

Such changes might have to be reverted in Python 3, since the module
might then expect character strings instead of byte strings, and then
might complain when it gets byte strings (which .encode will produce).
So declaring that all string literals are Unicode objects might not
help in the future, contrary to what the future import suggests.

 The obvious way to write code that works under -U and still works in normal
 Python is to .encode('charmap') every value intended to be an octet, and put
 'u' in front of every string intended to be unicode.  That would seem to
 defeat the purpose of changing the default literal type.

The not so obvious way is to change the modules/methods receiving these
strings to work with either string type if that is reasonable.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-15 Thread Neal Norwitz

On 7/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
 Terry Reedy wrote:
  That is the goal, but when I watched the buildbot results last spring, the
  degree of stability (greenness) appeared to vary.  Is it possible to tag
  particular versions as a 'green' version, or the 'most recent green
  version' worth playing with?

 Don't get confused by these colors. The tree compiled nearly all of the
 time, even if some tests were failing for an extended period of time on
 some platforms.

Right.  It's very rare that the interpreter or stdlib is broken.
There are 19 buildbots currently.  7 are not green.  5 of those are
offline, most with known (to me and the person that donated the
machines) hardware issues ranging from lack of air conditioning, to a
bad router, to no power.  1 is cygwin which is running an old version.
 I just (an hour or so ago) got an account on a cygwin box to help
diagnose the status and figure out if anything within Python or the
tests are broken.  That leaves 1 unexplained failure on a Windows bot.
 This started happening recently after being down for a while.  I
haven't had time to investigate.

The reason why it was not very green in spring was because that's when
we were getting it set up!  The master looks like it was installed at
the end of 2005/beginning of 2006.  It took several months to get rid
of many testing issues.  Tests that couldn't be run in a particular
order, tests that couldn't be run simultaneously (socket), bad
compilation of sqlite/bsddb modules (not in python), misconfigured
systems, tests verifying something that was system dependent, signed
addresses, etc.

Of all the problems there were, I only remember a single problem in
Python.  (There were probably more, I just remember one.)  That was in
test code (xxmodule or something like that.  There were a bunch of
problems with ctypes and/or sqlite when they got integrated having to
deal with these new platforms.  That may be what you are recalling.
Right before alpha 2 was a particularly bad time.

What we mean by stable is that at any time/any stage of development,
if a change goes in that breaks the tests, it is likely to be fixed or
reverted within hours.  The amount of time the build or tests are
broken on the majority of platforms is quite small.  It took a while
to get to this point due to a bunch of flaky tests, but those have
mostly been fixed.  The only known problems are mentioned on the wiki.

When the buildbots fail, we get mail to python-checkins.
Unfortunately, that's mostly spam at this point.  I hope to fix that
at some point.  I also hope to change the main page to give more info
in less space.

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-15 Thread Tim Peters

[Neal Norwitz]
 ...
 That leaves 1 unexplained failure on a Windows bot.

It wasn't my Windows bot, but I believe test_profile has failed
(rarely) on several of the bots, and in the same (or very similar)
way.  Note that the failure went away on the Windows bot in question
the next time the tests were run on it.  That's typical of
test_profile failures.

Unfortunately, because test_profile works by comparing stdout against
a canned expected-output file under Lib/test/output/, when we re-run
the test in verbose mode at the end, that comparison isn't done, so
there's isn't a simple way to know whether the test passed or failed
during its second run.  I _bet_ it actually passed, but don't know.

This problem is obscured because when you run regrtest.py by hand
with -v, you get this message at the end:


CAUTION:  stdout isn't compared in verbose mode:
a test that passes in verbose mode may fail without it.


which is intended to alert you to the possible problem.

But when we re-run failing tests in verbose mode by magic (via
passing -w), that warning isn't produced.

BTW, the best solution to this is to convert all the tests away from
regrtest's original compare stdout against a canned output/TEST_NAME
file scheme.  That won't fix test_profile, but would make it less of
a puzzle to figure out what's wrong with it.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-15 Thread Terry Reedy


[EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]


 On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy [EMAIL PROTECTED] wrote:
Other developers do the same.  Periodically (once a week?), when PAT is
  ^
 once per checkin to Python trunk

If the average rate of checkins is equal to or greater than the maximum 
rate of test runs then that is physically impossible.  (Indeed, queueing 
theory suggests that  keeping the queue size small requires that the 
checkin be more like half the test rate.)  This appears to be currently 
true for the Python trunk buildbot and I would expect running the test of 
numerous large applications would take even longer, making the test rate 
even lower.  If you want something like twisted run against multiple Python 
versions a day, I suspect you will have to do so on a system you control.

Terry Jan Reedy



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Fredrik Lundh

Neal Norwitz wrote:

 Given that several people here think we should lengthen the schedule
 in some way, I suspect we will do something.  I'm not really against
 it, but I don't think it will provide much benefit either.  A few more
 bugs will be fixed since we have more time.

you're still missing the point of this thread: it isn't bugs in the core 
Python distribution that's the problem, it's compatibility with third-
party modules and applications.

I'm quite sure that we could ship the current beta2 as 2.5 final and 
have a Python release that, in itself, is more stable than all the ones 
before it, but since 2.5 introduces lots of new stuff, that stability 
doesn't necessarily translate to a better experience for people who 
wants to use their existing applications and libraries.

a longer beta period gives *external* developers more time to catch up, 
and results in less work for the end users.

/F

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Neal Norwitz

On 7/13/06, Fredrik Lundh [EMAIL PROTECTED] wrote:
 Neal Norwitz wrote:

  Given that several people here think we should lengthen the schedule
  in some way, I suspect we will do something.  I'm not really against
  it, but I don't think it will provide much benefit either.  A few more
  bugs will be fixed since we have more time.

 you're still missing the point of this thread: it isn't bugs in the core
 Python distribution that's the problem, it's compatibility with third-
 party modules and applications.

...

 a longer beta period gives *external* developers more time to catch up,
 and results in less work for the end users.

This is the part I don't get.  For the external developers, if they
care about compatibility, why aren't they testing periodically,
regardless of alpha/beta releases?  How often is the python build
broken or otherwise unusable?  On Unix there's no more or less work to
grab a tarball whether it's a nightly or a release.  For Windows it's
definitely easier to wait for a release.  If there was an installable
windows version made by the buildbots, would that mean there would be
more testing?

Is part of your point that these developers only care about something
called release and they won't start testing before then?  If that's
the case why don't we start making (semi-)automated alpha releases
every month?  That will give people lots more time.  Somehow I don't
think it will make a difference.  People mostly work on schedules or
should I say avoid schedules.  Give them 5 months and they will still
wait to the last minute.

Remember I also tried to push for more features to go in early?  That
would have given more time for external testing.  Still features are
coming in.  Python developers weren't happy about having to get things
in earlier.  I don't see a practical way to implement what you propose
(see Anthony's comments).

n
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Fredrik Lundh

Neal Norwitz wrote:

 This is the part I don't get.  For the external developers, if they
 care about compatibility, why aren't they testing periodically,
 regardless of alpha/beta releases?

because they don't want to waste time and effort on testing against 
releases that are not necessarily a close approximation of the full
release?  testing takes time, and time can be used for many different 
things.

/F

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Anthony Baxter

On Friday 14 July 2006 17:00, Fredrik Lundh wrote:
 because they don't want to waste time and effort on testing against
 releases that are not necessarily a close approximation of the full
 release?  testing takes time, and time can be used for many
 different things.

Oddly enough, so does release management.

Anthony

-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Anthony Baxter

On Friday 14 July 2006 16:39, Neal Norwitz wrote:
 Remember I also tried to push for more features to go in early? 
 That would have given more time for external testing.  Still
 features are coming in.  Python developers weren't happy about
 having to get things in earlier.  I don't see a practical way to
 implement what you propose (see Anthony's comments).

Following up on this point: 
Given the number of just-this-one-more-thing-please we've _already_ 
had since the b1 feature freeze, do you really except that 90 days of 
feature freeze is feasible? And if there's not going to be a feature 
freeze, there's hardly any point to people doing testing until there 
_is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. 
Oops. 2.5b9 added a new feature that broke my code, but I didn't test 
with that. 

Anthony
-- 
Anthony Baxter [EMAIL PROTECTED]
It's never too late to have a happy childhood.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-14 Thread Giovanni Bajo

Greg Ewing [EMAIL PROTECTED] wrote:

 from __future__ import new_classes exists, but the syntax is
 different:
 
 __metaclass__ = type
 
 Although it's not a very obvious spelling,
 particularly to the casual reader who may not be
 familiar with the intricacies of classes and
 metaclasses. I don't think it would hurt to have
 it available as a __future__ import as well.
 
 There's also the advantage that all of a
 module's future assumptions could then be
 documented uniformly in one place, i.e. in
 a __future__ import at the top.

+1.

Giovanni Bajo

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots

2006-07-14 Thread Michael Hudson

[EMAIL PROTECTED] writes:

 I just would have appreciated the opportunity to participate in the
 discussion before the betas were out and the featureset frozen.

I think something that has happened to some extent with this release
is that there was a long-ish period where stuff got discussed and
implemented (PEPs 343 and 344, new-style exceptions, the new compiler,
the ssize_t branch) and then suddenly we went crap!  we have to
release this! and then the whole alpha/beta/release part has happened
much more quickly.  Maybe we should have had a more explicit
discussion on what was going to be in 2.5 before beta1, but that kind
of thing is difficult to make happen (it's entirely possible that it
did happen and I just missed it by being snowed under, but I don't
think so).

Cheers,
mwh

-- 
 Have you considered downgrading your arrogance to a reasonable level?
-- Erik Naggum, comp.lang.lisp, to yet another C++-using troll
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Giovanni Bajo

Neal Norwitz [EMAIL PROTECTED] wrote:

 a longer beta period gives *external* developers more time to catch
 up, and results in less work for the end users.

 This is the part I don't get.  For the external developers, if they
 care about compatibility, why aren't they testing periodically,
 regardless of alpha/beta releases?

Because it is a cost, and I don't want to waste my time if the trunk is
unstable or whatnot. There is no official statement of the kind all the real
development is done in branches, the trunk is always very stable, feel free to
grab it. Thus, we (external developers) assume that it's better to wait for
the first alpha or beta before starting doing any testing. Personally, I won't
touch something before the first beta: there are already enough known bugs when
the alphas are shipped that I prefer to wait a little bit more.

In my case, the beta period is too short. It's already a great luck if, during
the beta cycle, I'm not deep into some milestone or release cycle for my own
software. It might well happen that I have barely time to notice a Python beta
is out, but I can't afford spending any time on it because of time constraint.
By the time I'm done with my own deadlines, Python final is already out. But
for the sake of the argument and the rest of this mail, let's assume I have
tons of spare time to dedicate to Python 2.5 beta testing.

My applications have several external dependencies (I wouldn't classify those
as many, but still around 6-7 libraries in average). For each of those
libraries, there won't be Py2.5-ready RPM or Windows installer to grab and
build. Most of the time, I have to download the source package, and try to
build it. This also means hunting down and fixing Py2.5-related bugs in all
those libraries *before* I can even boot my own application (which is what I
would care about). Then I occasionally hit a core Python bug while doing so,
which is good, but I have to sit and wait. Some libraries have very complex
build process which are still distutils-based, but might require many other
external C/C++ libraries, which need to be fetched and compiled just to setup
the build environment.

Alternatively, I could cross my fingers and wait for all the maintainers of the
external libraries to have spare time, and dedicate to Python 2.5 upgrading. If
I'm lucky, by the time RC1 is out, most of them might have binary packages
available for download, or at least have their (unstable) CVS/SVN trunk fixed
for Python 2.5 (which means that I'll have to fetch that unstable version and
basically perform a forced upgrade of the library, which might trigger another
class of compatibility/feature/regression bugs in my application, not related
at all to Python 2.5 by itself, but still needed to be dealt).

So I think it's useless to ask people to rush testing beta releases: it takes
months to get the community synched, and will always take. It's also useless to
point the finger to external developers if they don't test Python and there is
a bug in a .0 release. Bugs happen. It's software that evolves. My own
suggestion is that it's useless to stall a release for months to give external
developers time to fix things. I think it's much better to release early -
release often, and just get the damn release out of the door. Usually, it's at
that point that the whole community start working on it, and discover bugs. And
so what? For production usage, .0 releases of libraries (let alone the
interpreter of the language) are a no-go for all software, and I know that for
a long time already. I don't ship an application of mine with a Python .0
release no matter what, no matter even if the whole testsuite passes and
everything seems to work. I don't have enough benefits for the risks, so I'll
wait for .1 or .2 release anyway. It's *very* fine by me if .0 release is
actually the first official beta release for the community, when the core
developers say we're done and external developers really start get things
going.

If you really care about .0 stability from a purely commercial point-of-view
(it's bad advertisement if many people complain if a major release is broken,
etc. etc.), I might suggest you to coordinate with a small group of selected
external developers maintaing the larger external packages (Twisted and
others). You could put a list of those packages in the release PEP as
showstoppers for the release: you should not get a .0 out if those packages are
broken. I think this could help smooth out the process. If important external
libraries work, many applications relying on it will *mostly* work as well. I
personally don't think it's such a big problem if one has to fix a couple of
things in a 100K-line application to adjust it to the new .0 release, even if
it's actually because of a bug in Python itself.

Giovanni Bajo

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Nick Coghlan

Anthony Baxter wrote:
 On Friday 14 July 2006 16:39, Neal Norwitz wrote:
 Remember I also tried to push for more features to go in early? 
 That would have given more time for external testing.  Still
 features are coming in.  Python developers weren't happy about
 having to get things in earlier.  I don't see a practical way to
 implement what you propose (see Anthony's comments).
 
 Following up on this point: 
 Given the number of just-this-one-more-thing-please we've _already_ 
 had since the b1 feature freeze, do you really except that 90 days of 
 feature freeze is feasible? And if there's not going to be a feature 
 freeze, there's hardly any point to people doing testing until there 
 _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. 
 Oops. 2.5b9 added a new feature that broke my code, but I didn't test 
 with that. 

I think this is where release candidates can come into their own - the beta's 
can flush out the just-one-more-thing pleases, the maintenance branch is 
forked for rc1, and then any changes on the branch are purely to fix 
regressions.

As far as the idea of a suite of buildbots running the unit tests of large 
Python applications against the current SVN trunk goes, one problem is that 
failures in those buildbots will come from two sources:
   - Python itself fails (broken checkin)
   - the application unit tests fail (backwards incompatibility)

To weed out the false alarms, the slaves will need to be set up to run the 
Python unit tests first and then the application unit tests only if the Python 
test run is successful.

When the slave suffers a real failure due to a backwards incompatibility, it 
will take a developer of the application to figure out what it was that broke 
the application's tests.

So while I think it's a great idea, I also think it will need significant 
support from the application developers in debugging any buildbot failures to 
really make it work.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
 http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread A.M. Kuchling

On Fri, Jul 14, 2006 at 12:00:07PM +0200, Giovanni Bajo wrote:
 unstable or whatnot. There is no official statement of the kind all
 the real development is done in branches, the trunk is always very
 stable, feel free to grab it. Thus, we (external developers) assume
 that it's better to wait for the first alpha or beta before starting
 doing any testing. 

Where could we put such a statement?
http://www.python.org/dev/tools/, in a discussion of checkin policies,
does say:  

The Python source tree is managed for stability, meaning that
if you make a checkout at a random point in time the tree will almost
always compile and be quite stable. Large sets of changes, such as the
2.2 type/class rewrite, are usually tested on a branch first and
merged into the main stream of development once they're believed to be
complete.

but this is buried pretty deeply.  Maybe some text should be added to
the release announcements about this.

 I'm lucky, by the time RC1 is out, most of them might have binary packages
 available for download, or at least have their (unstable) CVS/SVN trunk fixed
 for Python 2.5 (which means that I'll have to fetch that unstable version and

And many people won't make binary packages until 2.5 is final, so
you're probably not often lucky.

--amk
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots


 If you're concerned about noticing when a new release train is
 pulling out of the station ...

glyph I am aware of when new releases come out :).  What I'm not aware
glyph of is what features (may) have broken my code, and why.  

Hmmm...  Well, you could subscribe to the python-checkins mailing list.
Most of the time you'd probably decide rather quickly to delete the
messages, but the stuff you care about should be in the checkin comments.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)


Greg Maybe there could be an unstable release phase that lasts for a
Greg whole release cycle. So you'd first release version 2.n as
Greg unstable, and keep 2.(n-1) as the current stable release. Then
Greg when 2.(n+1) is ready, 2.n would become stable and 2.(n+1) would
Greg become the new unstable.

In GCC don't they do an odd (stable)/even (unstable) release schedule?  Same
for Linux kernels?  Would that help?

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)


 I believe there was some shortening of the 2.5 release cycle two or
 three months ago.

Fred The squeezing of the releases isn't where the problem is, I think.

Had we been in alpha a bit longer (officially before feature freeze) I think
there'd have been less back-and-forth about a couple otherwise
noncontroversial checkins.

Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)

2006-07-14 Thread Fredrik Lundh

A.M. Kuchling wrote:
 While the new python.org is very nice, I do note that there's no blogs
 entry on the front page, something which has become a fixture on almost
 every other website I visit regularly.

 A 'Blogs' link could be trivially added by linking to
 planet.python.org, though the blogs collected there are not in any way
 'the Python developers', but a jumble of developers and users.  I
 don't think enough core developers have weblogs (or write about
 Python) to make a 'python-dev only' planet very useful.

on the other hand, the material you're producing for the what's new document
would be a rather excellent development blog in itself.  just post new sections 
to
the blog when they're ready...

(add PEP announcements and python-dev summary items to the mix, and you
have a high-quality development blog generated entirely from existing content)

(hmm.  maybe this could be put together by a robot?  time to start hacking on
The Daily URL 2.0 Beta, I suppose...)

/F 



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Community buildbots (was Re: User's complaints)