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 t
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 feat
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 warr
[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
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
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
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
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
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 t
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 f
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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 almos
Christopher Armstrong wrote:
> I'm at least willing to set up the buildbots for projects I care about
> (Twisted, pydoctor, whatever), and perhaps help out with the setting
> up the buildmaster.
If you need trigger calls from subversion's post-commit hooks, please
let me know, and I can set them u
On 7/14/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
> > (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
On Thu, 13 Jul 2006 23:39:06 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote:
>On 7/13/06, Fredrik Lundh <[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 exter
On Fri, 14 Jul 2006 06:46:55 -0500, [EMAIL PROTECTED] wrote:
>
>Neal> How often is the python build broken or otherwise unusable?
>
>Not very often.
I have to agree. The effort I'm talking about is not in fixing large numbers
of problems, but simply gearing up to properly test to see if there
Jeremy Hylton wrote:
>> 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
>
On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote:
> (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
>
[EMAIL PROTECTED] wrote:
> 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
On 7/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> 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. Pyth
On 7/14/06, Anthony Baxter <[EMAIL PROTECTED]> 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
>> 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?
Fredrik> because they don't want to waste time and effort on testing
Fredrik> against releases that a
Neal> How often is the python build broken or otherwise unusable?
Not very often. I use the head branch of the repository as the source of
the interpreter I run on my laptop. It generally takes just a couple
minutes on my now-aging PowerBook to svn up and reinstall. I can only
recall one
"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, thou
>> 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 abou
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
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 wai
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
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
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 prac
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 rel
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
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
>
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 mis
On 7/13/06, Christopher Armstrong <[EMAIL PROTECTED]> wrote:
> On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote:
> >
> > >There's been some recent discussion in the PSF wondering where it would
> > >make sense to throw s
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Fred> It feels like the release cycle from alpha1 to final has gotten
> Fred> increasingly rushed.
I think that's just because you are getting older and time goes by
faster the less time you've got left. :-) It seems to be going
On Friday 14 July 2006 06:05, Barry Warsaw wrote:
> This really is an excellent point and makes me think that we may
> want to consider elaborating on the Python release cycle to include
> a gamma phase or a longer release candidate cycle. OT1H I think
> there will always be people or projects tha
On Friday 14 July 2006 01:45, Fredrik Lundh wrote:
> I'd prefer something like 90 days.
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mai
Fred L. Drake, Jr. wrote:
> It feels like the release cycle from alpha1 to final has gotten increasingly
> rushed.
python 2.2: ~5 months
python 2.3: ~7 months
python 2.4: ~5 months
python 2.5: ~4 months
I think the biggest problem is the time between "basically stable beta"
and "final"; it was
On Friday 14 July 2006 00:32, [EMAIL PROTECTED] wrote:
> Same here. I believe there was some shortening of the 2.5 release cycle
> two or three months ago. I don't recall why or by how much, but I think
> the acceleration has resulted in a lot of the "can't we please squeeze
> this one little
Barry Warsaw wrote:
> we may want
> to consider elaborating on the Python release cycle to include a
> gamma phase or a longer release candidate cycle.
Maybe there could be an "unstable" release phase that
lasts for a whole release cycle. So you'd first release
version 2.n as "unstable", and k
Fred> It feels like the release cycle from alpha1 to final has gotten
Fred> increasingly rushed.
Same here. I believe there was some shortening of the 2.5 release cycle two
or three months ago. I don't recall why or by how much, but I think the
acceleration has resulted in a lot of the
FWIW, I tend to run a few project(*) test suites when doing minor
releases (2.x.y), just to make sure I don't break things. For major
releases, it's a fair bit more work - something like Twisted or Zope3
play at such a low level with the Python interfaces that there's
nearly always breakages or
On Thursday 13 July 2006 16:05, Barry Warsaw wrote:
> This really is an excellent point and makes me think that we may want
> to consider elaborating on the Python release cycle to include a
> gamma phase or a longer release candidate cycle. OT1H I think there
...
> "absolutely no changes are
On 7/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote:
>
> >There's been some recent discussion in the PSF wondering where it would
> >make sense to throw some money to remove grit in the wheels; do you think
> >this is a case
On Thu, 13 Jul 2006 11:29:16 -0700, Aahz <[EMAIL PROTECTED]> wrote:
>There's been some recent discussion in the PSF wondering where it would
>make sense to throw some money to remove grit in the wheels; do you think
>this is a case where that would help?
Most likely yes. It's not a huge undert
Barry Warsaw wrote:
> OTOH, a more formal gamma phase would allow us to say
> "absolutely no changes are allowed now unless it's to fix backward
> compatibility". No more sneaking in new sys functions or types
> module constants during the gamma phase.
This is pretty common in project managemen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 13, 2006, at 2:03 PM, [EMAIL PROTECTED] wrote:
> Having been exhorted (or maybe I mean "excoriated") by your
> friendly release
> manager earlier this week to post my comments and criticisms about
> Python here
> rather than vent in random
On Thu, Jul 13, 2006 at 02:03:22PM -0400, [EMAIL PROTECTED] wrote:
> 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.
An excellen
On Thu, Jul 13, 2006, [EMAIL PROTECTED] wrote:
>
> 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 usef
On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman <[EMAIL PROTECTED]> wrote:
>Well here's one I stumbled across the other day. I don't know if it's
>legit, but it's still bad PR:
>
>http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html
Having been exhorted (or maybe I mean "excoriate
50 matches
Mail list logo
