> I don't know if it's possible but it would be great if the buildbot
> master could send an email to a buildbot maintainer if it thinks a
> buildbot is down.
I think it should be possible to detect that. I wouldn't recommend
immediate reaction, but rather a delayed reaction (say, 12h). Buildbot
i
exar...@twistedmatrix.com writes:
> It's easy for someone to volunteer to set up a new slave. It's even
> easy to make sure it keeps running for 6 months. But it's not as easy
> to keep it running indefinitely. This isn't about the software
> involved (at least not entirely). It's about someon
>> When I (or somebody else) contacts all the slave operators and asks them
>> to restart the buildbot slaves.
>
> Does this mean you're taking responsibility for this task? Or are you
> looking for a volunteer?
I had been running this buildbot installation ever since I created it,
and will happ
On 24 Sep, 11:27 pm, mar...@v.loewis.de wrote:
Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be
up?
When I (or somebody else) contacts all the slave operators and asks
them
to restart the buildbot slaves.
>> Additionally, I'm very apprehensive about doing any kind of release
>> without the buildbots running. Does anyone know when they might be up?
When I (or somebody else) contacts all the slave operators and asks them
to restart the buildbot slaves.
Regards,
Martin
___
> Do we already have the machines? or do they need to be acquired?
Yes, the machines are all there, see
http://www.python.org/dev/buildbot/all/
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
R. David Murray bitdance.com> writes:
>
> And if Snakebite isn't enough I
> have a well-connected platform I could run Linux buildbots on in
> vserver virthosts, and a less-well-connected platform that could run
> KVM based stuff.
I suppose Snakebite will be enough, but only once it is ready :)
On Thu, 24 Sep 2009 at 13:49, Antoine Pitrou wrote:
Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a ??crit??:
Depends on where the machines are. There are good tools do check all
automatically. Nagios is one.
Anyway, this would suite my work schedule for the next 12 months.
Do we already hav
Le Thu, 24 Sep 2009 00:23:31 -0400, David Lyon a écrit :
>
> Depends on where the machines are. There are good tools do check all
> automatically. Nagios is one.
>
> Anyway, this would suite my work schedule for the next 12 months.
>
> Do we already have the machines? or do they need to be acqui
On Thu, Sep 24, 2009 at 12:23:31AM -0400, David Lyon wrote:
> On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
>
> > I would also personally recommend that this person first (well, after
> > tracking down all the slave operators and convincing them to bring their
> > slaves b
On Wed, 23 Sep 2009 15:13:55 -, exar...@twistedmatrix.com wrote:
> Quite a few years of experience with a distributed team of build slave
> managers has shown me that by far the most reliable way to keep slaves
> online is to have them managed by a dedicated team. This team doesn't
> need t
Eric Smith wrote:
>> From Trent on the snakebite mailing list. Too late for me to look it
>> up though; an exercise I leave to the reader.
>
> http://groups.google.com/group/snakebite-list/browse_thread/thread/d08642261f2cc502
Hmm, I thought I was subscribed to the snakebite list... guess I will
Michael Foord wrote:
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should have expect
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>>
>> 2009/9/23 Michael Foord :
>>
>>>
>>> Isn't that the real compatibility test *anyway* - how successful a new
>>> version of Python is at running all the existing Python code...
>>>
>>
>> Yes, but we should have expect 3rd party code to be de
Benjamin Peterson wrote:
2009/9/23 Michael Foord :
Isn't that the real compatibility test *anyway* - how successful a new
version of Python is at running all the existing Python code...
Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite could
2009/9/23 Michael Foord :
> Isn't that the real compatibility test *anyway* - how successful a new
> version of Python is at running all the existing Python code...
Yes, but we should have expect 3rd party code to be detecting bugs for
us that our test suite could have shown on a platform.
--
R
Raymond Hettinger wrote:
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in
the 2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
That would be my feeling...
Michael
Raymond
--
http://www.ironpythoninaction
[Michael Foord]
Are we definitely decided that 2.7 will be the last major release in the
2.x cycle?
ISTM, that would depend on the uptake for 3.2.
The users get a say in the matter.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Benjamin Peterson wrote:
2009/9/23 Brett Cannon :
On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
As for burn out, I expected 2.7.x, as the last 2.x release, to be
different in that several people would do the maintenance releases
(perhaps on a 6 month schedule or so) for the 5
On Wed, Sep 23, 2009 at 14:19, Michael Foord wrote:
> Benjamin Peterson wrote:
>>
>> 2009/9/23 Brett Cannon :
>>
>>>
>>> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson
>>> wrote:
>>>
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release m
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release, to be
>> different in that several people would do the maintenance releases
>> (perhaps on a 6 month schedule or so) for the 5 year period, so that
>> w
Michael Foord voidspace.org.uk> writes:
>
> Are we definitely decided that 2.7 will be the last major release in the
> 2.x cycle?
I don't think any "definitive" decision was made, but judgeing by Benjamin's and
Brett's answers (and by my own sentiment :-)), it certainly is the expectation
of so
On Wed, Sep 23, 2009 at 13:34, Benjamin Peterson wrote:
> 2009/9/23 Brett Cannon :
>> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
>>> Hi everyone,
>>> I've started plotting the release of 2.7. I'd like to try for a final
>>> release mid next summer. 3.2 should be released, if not at t
2009/9/23 Michael Foord :
> Benjamin Peterson wrote:
>> As for burn out, I expected 2.7.x, as the last 2.x release,
>
> Are we definitely decided that 2.7 will be the last major release in the 2.x
> cycle?
No, but that's what we're planning for atm.
--
Regards,
Benjamin
Benjamin Peterson python.org> writes:
>
> Different RMs would have different times they can do releases,
> so I would worry about there being a release in a slightly different
> stage of a different branch every couple weeks.
Assuming you can do it, +1 for you (Benjamin) being RM for both 2.7 an
Benjamin Peterson wrote:
2009/9/23 Brett Cannon :
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few wee
2009/9/23 Brett Cannon :
> On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, within a few weeks to avoid 2.x having
2009/9/23 Antoine Pitrou :
> Benjamin Peterson python.org> writes:
>>
>> Hi everyone,
>> I've started plotting the release of 2.7. I'd like to try for a final
>> release mid next summer. 3.2 should be released, if not at the same
>> time as 2.7, within a few weeks to avoid 2.x having features whic
On 06:03 pm, br...@python.org wrote:
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson
wrote:
[snip]
Additionally, I'm very apprehensive about doing any kind of release
without the buildbots running. Does anyone know when they might be up?
I don't know the answer, but it might be "never". We
On Wed, Sep 23, 2009 at 07:35, Benjamin Peterson wrote:
> Hi everyone,
> I've started plotting the release of 2.7. I'd like to try for a final
> release mid next summer. 3.2 should be released, if not at the same
> time as 2.7, within a few weeks to avoid 2.x having features which 3.x
> doesn't. I
Benjamin Peterson python.org> writes:
>
> Hi everyone,
> I've started plotting the release of 2.7. I'd like to try for a final
> release mid next summer. 3.2 should be released, if not at the same
> time as 2.7, within a few weeks to avoid 2.x having features which 3.x
> doesn't. If no one has pr
Benjamin Peterson wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will
On 02:35 pm, benja...@python.org wrote:
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems wit
Hi everyone,
I've started plotting the release of 2.7. I'd like to try for a final
release mid next summer. 3.2 should be released, if not at the same
time as 2.7, within a few weeks to avoid 2.x having features which 3.x
doesn't. If no one has problems with this, I will draft a schedule.
Are we s
35 matches
Mail list logo
