[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-idle-dev
Subject:    [Idle-dev] integration process for new UI changes
From:       Mark Roseman <mark () markroseman ! com>
Date:       2015-10-05 15:31:54
Message-ID: EFECE745-D35C-48B8-BE0F-F18BFF4619AF () markroseman ! com
[Download RAW message or body]

Not to put words in Terry's mouth, but I believe he's almost ready to start looking \
at integrating some of the broader UI changes I've been developing into IDLE. I \
thought it would therefore be a good time to raise issues surrounding what that \
process might look like.

While most IDLE changes recently have been in the form of standalone, fairly \
independent patches, some of this work "feels" different, more like new, partially \
                experimental, development. In particular:
	* many interdependent pieces, fairly hard to integrate individually
	* parts likely needing usage feedback before being included/finalized (or revised, \
                or excluded)
	* usage and iteration will bring out other issues not yet known
	* limited automated testing, which even if more extensive would be misleading as to \
"correctness"

As well, it would seem that a "(re-)launch" in one form or another would be \
appropriate to get the word out and generate more interest from potential new \
helpers. :-)

All of this feels more like an alpha-beta-release process (i.e. the whole thing shows \
up at once) rather than incremental improvements over time and possibly spanning \
several Python releases.

From a development point of view, I'd normally approach this as a separate branch in \
the code repository, which would get integrated into the mainline on release. (I've \
kinda been doing that as I work through things myself, via github). What would be the \
best way to approach this for IDLE?

One possibility might be integrate things on the main (i.e. 3.6) branch, which I'm \
presuming won't have an actual release of any kind for quite some time. 

That lets things get added more incrementally and tested by ourselves and others \
without it being inadvertently dropped on unsuspecting folk. It would be ok if at \
various times things were in an incomplete state. 

After a significant amount of integration, refinement and revision we might get to \
the point where as a group we're "satisfied" with the new state of IDLE as a whole, \
and those changes get ported all at once to 3.5.x and 2.7.x where they'd actually \
hitting real people.

I'll throw that out there anyway.  I'm sure others have many different ideas on this. \
Anyone care to share their thoughts?

Mark

_______________________________________________
IDLE-dev mailing list
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev


[prev in list] [next in list] [prev in thread] [next in thread]