[Idle-dev] IDLE dev FAQ

[Terry Reedy]

On 2/11/2014 3:44 PM, phil jones wrote:

> On 11 February 2014 16:52, Terry Reedy <tjreedy at udel.edu> wrote:
>
>>> Q : Where can I check-out the current state of IDLE development?
>> What does 'current state of Idle development' mean to you.
>
> Well, I'd assume it's like this. Suppose there were two people (the
> infamous Alice and Bob) working with you on the software. Each of them
> is fixing bugs and submitting patches to you.
>
> But you'd ideally want them both to be as much in sync with each other
> as possible. So that Alice isn't doing things that are incompatible
> with the changes that Bob is making.

Incompatibility of patches for different issues is generally not a 
problem. The 122 Idle issues are spread across nearly 70 modules, for 
less than two issues per module. On an issues per code line basis, I 
suspect that Idle is comparable to the stdlib as a whole. I know of one 
module, tokenize, that has 8 open issues.

Incompatibility between patches on duplicate issues is a problem. So we 
close duplicates when we notice them.

(Particularly if there's
> refactoring going on, like you've been talking about with
> consolidating many small files into fewer larger ones.)

(But this is not now ;-)

> So on the one hand you would want Alice and Bob to be pulling each
> other's changes as frequently as possible.

They should both be pulling from the repository. That is what their 
patches will be tested against before acceptance.

> On the other, you might
> want to have some role as a gatekeeper in case Bob starts making
> changes that you think the community wouldn't agree with.

Having the sense to do that is part of evaluating candidates for commit 
privileges.

> Finally, the changes that Alice and Bob are making are not yet fully
> tested on all platforms and so not necessarily accepted into the main
> Python release yet.

Most patches do not interact with the OS. While multiplatform testing is 
nice, it is not then required. If tests were included with patches, then 
there would be post-commit tests on the buildbots, which cover many systems.

> So I'd assume there's a repo somewhere which is a kind of reference
> point for "current development release", it's something you gatekeep
> enough that Alice and Bob know that what's been accepted to it is part
> of the plan for what will go into the final release, and they can keep
> pulling from it to keep their development environments up-to-date.
>
> If you don't have something like this, then Bob has to wait until
> Alice's patch has gone all the way through acceptance into the release
> (which may take years) before he can see it and work against it.

If both upload their patches, they can each see them and discuss 
conflicts. But it is rare for two people to be actively working on the 
same module.

> So that's the question. Where is the equivalent of  *that* repository
> for IDLE? Is it just http://hg.python.org/cpython ?

bugs.python.org
>
> Or is that main cpython repo for patches that have undergone the full
> testing on all platforms, and are ready for release? If so, how can
> multiple contributors co-ordinate with each other?

If you were working on a patch for EditorWindow.py, you could search 
with 'EditorWindow' in the 'All text' box. This returns 18 issues, some 
of which are not about the EditorWindow.


>> Only if the PSF Code of Conduct applies to this list and personal attacks
>> are not tolerated.
>
> I assume you mean that if you aren't prepared to to follow the code of
> conduct you aren't welcome on this list?

Yes.

> On this note, I was looking at http://bugs.python.org/issue17390 and I
> saw you wrote this :
>
> Edmond: please fill in, sign, and send by your preferred method a PSF
> Contributor Agreement
> http://www.python.org/psf/contrib/contrib-form/ (back up a level for
> more explanation)
>
> For a patch more complicated than this, the CA would now be required
> before applying a patch of yours.
>
> What does this mean exactly?

Back when signing the CLA meant printing it, signing it with ink, and 
faxing or mailing it, we did not always insist on it. Now that we easy 
electroninc signing and cases like MS Sockpuppet versus Linux, et al 
have happened, we are much more serious about the matter.

In the particular case above, the patch was two lines and I might have 
applied it without the CLA. As it was, Edmond replied 6 minutes later 
that he had already signed it. And I did apply it 22 minutes later. If 
the patch had effected too many more lines, I would have waited for the 
* indicator to appear.

-- 
Terry Jan Reedy