My preferred planning strategy is to decide on the goals and then try to
work out how to achieve them. The PSF will take direction from its
members and from active developers. But Christian is right about the
absence of a business plan.
Perhaps when the current release phase is over we need to
What would this professionalisation get us that we don't have now? As
far as I can see, the biggest hole at the moment (as always) is with
people to trawl the tracker and triage bug reports and patches.
On Fri, Aug 15, 2008 at 8:35 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Antoine Pitrou w
2008/8/14 Brett Cannon <[EMAIL PROTECTED]>:
> But I honestly think this discussion should wait until after we go
> final with 2.6/3.0. Once that happens and we are all not running
Thanks Brett for this. I started to write some responses... and then I
realized I agree with you here, it's better to
Barry Warsaw wrote:
Let me take this opportunity to explicitly say that I'm not /blaming/
anybody for this. I consider the problems we had with the module an
indication of a systemic, team-wide deficiency. I greatly appreciate
you (and others) working so hard to land it and make it work.
He
Antoine Pitrou wrote:
Ubuntu's sophisticated release plan is certainly justified by its
business model, and the desire to both appeal to the open source people
and the corporate people without creating two different distributions.
I don't think Python has the same business requirements (neither
On Aug 14, 2008, at 6:27 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 6:16 PM, Jesse Noller wrote:
Yup - it went in during alpha, and I underestimated the amount of
work, which won't happen again.
Stunning revelation - gett
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 6:16 PM, Jesse Noller wrote:
Yup - it went in during alpha, and I underestimated the amount of
work, which won't happen again.
Stunning revelation - getting everything right cross platform is hard.
Note, mp was not the only l
On Aug 14, 2008, at 6:00 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 10:33 AM, Christian Heimes wrote:
By the way the guys are totally awesome, dude. :)
I agree wholeheartedly!
That's what branches are for. I really stron
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 12:36 PM, Gustavo Niemeyer wrote:
Hey Barry,
First, let me thank you for taking the energy to express many
interesting
points in that discussion.
Hi Gustavo!
We're actually adopting a PQM-based approach *precisely* because
Le jeudi 14 août 2008 à 16:33 +0200, Christian Heimes a écrit :
> Perhaps we could adopt a release plan similar to Ubuntu. They have
> releases with cool, new and bleeding edge stuff followed by a release
> that focuses on stability and long term support.
Ubuntu's sophisticated release plan is c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 10:33 AM, Christian Heimes wrote:
By the way the guys are totally awesome, dude. :)
I agree wholeheartedly!
That's what branches are for. I really strongly feel that the
mainlines (by which I mean the branches we cut releas
Hey Martin,
>> What exactly is the "doesnt' scale" issue in this case?
>
> I don't actually know PQM, but from what I hear, it appears that
> PQM can't run tests for a single patch on all of Solaris, Linux,
> Windows, and OS X before accepting it. Instead, PQM will run the
> tests on the same mach
Hey Brett,
> There is also the PQM suggestion to make sure we always at least
> have some general sanity in the code base. But a PQM system would
> probably only work once the test suite is not flaky anymore as
> having some typo in a comment be rejected because test_kqueue failed
> again is not g
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 2:06 PM, Brett Cannon wrote:
But I honestly think this discussion should wait until after we go
final with 2.6/3.0. Once that happens and we are all not running
around trying to get a release out, then we should start from the
gr
The thread on PQM has now grown multiple points and it becoming a
little hard to follow since it is pulling in a bunch of ideas not
directly related to a PQM system, so I am going to attempt to
summarize the points brought up here. SUMMARY: it's great we are
talking about this, but I think this wou
> What exactly is the "doesnt' scale" issue in this case?
I don't actually know PQM, but from what I hear, it appears that
PQM can't run tests for a single patch on all of Solaris, Linux,
Windows, and OS X before accepting it. Instead, PQM will run the
tests on the same machine it runs on itself,
Hey Barry,
First, let me thank you for taking the energy to express many interesting
points in that discussion.
>> I don't have experience with PQM or something like it, but I suspect
>> it doesn't scale, and the buildbots are a better approach, because
>> they handle multiple platforms.
(...)
>
> > What platform would it run the test suite on? Presumably the same one
> > I tested on before I submitted the patch :-).
>
> I think we'd just have to pick one. It would probably be a *nix based
> system.
So everyone who wanted to work on the system would effectively have to
go out and get
Barry Warsaw wrote:
Unfortunately, they're not being solved without PQM either! Really,
we've had to delay releases several times because the branches were
broken across multiple operating systems. Pleading on the mailing lists
doesn't help. Hanging out on irc doesn't help. Having Benjamin,
Christian Heimes schrieb:
>
> I suggest that we should use branches to a greater extend. New
> features or updates of existing code should happen on a branch.
+1
> A branch must not be merged until it's tested on all major platforms
> (Linux i386, Linux AMD64, Mac OS X and Win32) and peer revi
Guido van Rossum wrote:
[Hey Christian, welcome back! (It seems we hadn't heard much from you
for a while...)]
Yeah, I had an acute case of burnout syndrome. I tried to do far too
many things in parallel. I prescribed myself to focus on the most
important tasks like my new apartment and my jo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 9:51 AM, Christian Heimes wrote:
During my time as a Zope and Plone developer and at various XP
sprints I've utilized the branch development and peer reviewing
workflow with great success. I assume the majority of Python
dev
Barry Warsaw wrote:
I think this is a case where PQM might have helped. Assuming the
build/test would uncover these subtle bugs, the multiprocessing code
would not have landed. You would then probably publish a branch with d t
those (failing) changes and rally the help you needed to fix those
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 5:27 AM, Antoine Pitrou wrote:
It would be a change in culture for us, that's for sure. The question
becomes whether the drop in patch throughput is justified by an
increase of patch quality and stability in the code?
Well, l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 14, 2008, at 2:54 AM, Martin v. Löwis wrote:
As long as we're touting tools or processes that we have experience
with, Google uses a combination of tools. One tool is similar to the
buildbots, running tests *after* stuff has been checked in.
2008/8/14 Barry Warsaw <[EMAIL PROTECTED]>:
> it would be the developer who committed the broken change. The problem of
> not having access to all the platforms, or not being able to debug problems
> on those platforms is a different issue.
I want to grab a little attention on this issue. It hap
On 2008-08-14 10:37, Brett Cannon wrote:
On Wed, Aug 13, 2008 at 11:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
[SNIP]
Anyway, if we're going to change policies around submitting code, I
would much rather see peer review become a habit than adopt a tool
like PQM.
The part where I'm skep
> It would be a change in culture for us, that's for sure. The question
> becomes whether the drop in patch throughput is justified by an
> increase of patch quality and stability in the code?
Well, let's take the multiprocessing example. The question is:
- would an a priori review have been able
On Wed, Aug 13, 2008 at 11:54 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
[SNIP]
>> Anyway, if we're going to change policies around submitting code, I
>> would much rather see peer review become a habit than adopt a tool
>> like PQM.
>
> The part where I'm skeptical about such a policy is tha
Le jeudi 14 août 2008 à 08:54 +0200, "Martin v. Löwis" a écrit :
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
> a reviewer for a month or so? Many patches in the tracker sit there
> for years without a
>> Anyway, if we're going to change policies around submitting code, I
>> would much rather see peer review become a habit than adopt a tool
>> like PQM.
>
> The part where I'm skeptical about such a policy is that there might
> be a shortage of reviewers. What if a patch on Rietvield doesn't find
[forgot to CC list]
Le jeudi 14 août 2008 à 00:16 -0400, Barry Warsaw a écrit :
> It would still solve a problem we have today, which is that the
> release branch is very often broken when the time comes to cut a
> release. We've had to delay several releases because of red buildbots
> or
32 matches
Mail list logo
