Re: [Python-checkins] CVS: python/nondist/sandbox/Lib README,NONE,1.1 davlib.py,NONE,1.1 httpx.py,NONE,1.1
I've now created nondist/sandbox/Lib as a place where people can (cooperatively) develop modules intended for inclusion into the core's Lib directory. Of course, at your discretion, you can also create sandbox/big-project, but the sandbox/Lib directory could be handy for more people. I've checked in a non-working httpx, and the current davlib. These will get worked on over the next few weeks to prep them for the next release. Review and commentary are welcome! Cheers, -g On Mon, Sep 10, 2001 at 06:27:40PM -0700, Greg Stein wrote:
Update of /cvsroot/python/python/nondist/sandbox/Lib In directory usw-pr-cvs1:/tmp/cvs-serv17467
Added Files: README davlib.py httpx.py Log Message: Initial checkin of some files:
* README: describe this directory and its contents
* davlib.py: current, published davlib (only tweaked the header)
* httpx.py: initial draft from some coding over the weekend (incomplete, untested, and it doesn't even load :-)
--- NEW FILE: README --- This directory is for modules that are intended to go into the main Lib directory of Python. They can be developed here until they are ready for evaluation for inclusion into Python itself.
(this prevents iteration of development within the core, yet also provides for public development of (new) modules)
Note: a module's presence here does not mean it *will* go into Lib, but merely that (should it be accepted) the appropriate place is Lib. ...
-- Greg Stein, http://www.lyra.org/
I've now created nondist/sandbox/Lib as a place where people can (cooperatively) develop modules intended for inclusion into the core's Lib directory. Of course, at your discretion, you can also create sandbox/big-project, but the sandbox/Lib directory could be handy for more people.
I've checked in a non-working httpx, and the current davlib. These will get worked on over the next few weeks to prep them for the next release. Review and commentary are welcome!
Excellent, Greg! I encourage Eric Raymond to check in his ccframe code. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 11 Sep 2001, Greg Stein wrote:
I've now created nondist/sandbox/Lib as a place where people can (cooperatively) develop modules intended for inclusion into the core's Lib directory. Of course, at your discretion, you can also create sandbox/big-project, but the sandbox/Lib directory could be handy for more people.
As mostly a bystander in the python development process, i have a question about an alternative approach. I believe we (zope dev) use branches for this kind of thing, and wonder whether you've considered using that? I gather that this is for things that have not yet gotten approval for inclusion in the distribution, but that doesn't disqualify the branch approach - branches need not ever be merged. The two drawbacks i see with using branches this way: - More risk that configuration mistakes can lead to disruption, eg if someone thinks they've established their checkout in the branch. That said, mistakes using the version control system are generally painful, so care is needed in any event. - Pollution of the branch namespace. This can be mitigated by a good system for choosing names. The advantage is that the subject files are developed where they're used, instead of some arbitrary other place. This is easier on developers, and means that the initial development history is included in the version control history, rather than being in some separate (nondist/sandbox/...) place. Is it worth considering using branches for this kind of thing? Ken klm@zope.com
As mostly a bystander in the python development process, i have a question about an alternative approach. I believe we (zope dev) use branches for this kind of thing, and wonder whether you've considered using that? I gather that this is for things that have not yet gotten approval for inclusion in the distribution, but that doesn't disqualify the branch approach - branches need not ever be merged.
The two drawbacks i see with using branches this way:
- More risk that configuration mistakes can lead to disruption, eg if someone thinks they've established their checkout in the branch.
That said, mistakes using the version control system are generally painful, so care is needed in any event.
- Pollution of the branch namespace.
This can be mitigated by a good system for choosing names.
The advantage is that the subject files are developed where they're used, instead of some arbitrary other place. This is easier on developers, and means that the initial development history is included in the version control history, rather than being in some separate (nondist/sandbox/...) place.
Is it worth considering using branches for this kind of thing?
I believe the sandbox is for an earlier stage in development. My experiences so far with branches is that they present many surprises and sources of confusion. How many times in Zope have you run into a bug that was already fixed on a branch -- or on a trunk? Just recently I reported a ZEO bug to Jeremy and he said "Oh yeah, that's fixed on branch so-and-so; I haven't looked at the trunk for ages". :-( I like using short-lived branches for things like releases, but doing the types/class unification on a branch probably caused more grief than light. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 11 Sep 2001, Guido van Rossum wrote:
I believe the sandbox is for an earlier stage in development. My experiences so far with branches is that they present many surprises and sources of confusion. How many times in Zope have you run into a bug that was already fixed on a branch -- or on a trunk? Just recently I reported a ZEO bug to Jeremy and he said "Oh yeah, that's fixed on branch so-and-so; I haven't looked at the trunk for ages". :-(
I like using short-lived branches for things like releases, but doing the types/class unification on a branch probably caused more grief than light.
Merge problems certainly increase the longer the developing code is isolated from the trunk - whether or not you're using a branch for the developing code. (When the project is big enough, that code skew is inevitable - at least when using a branch you have the option to occasionally merge form the trunk into the in-process branch. I didn't follow the types/class unification very carefully, but have the impression that you and tim did some of that - perhaps later in the process than you would have, in retrospect, preferred.) I'm not the CVS practices maven here - brian lloyd has that pleasure;-) and in any case realize the cost/benefits balance is complicated. CVS branching does offer some real advantages, but the complication of realizing them can be an added burden, and CVS' foibles can muddy cost/benefit balance a good bit, as well - so i don't mean to suggest there's a clear-cut win here, one way or the other... Ken klm@zope.com
Merge problems certainly increase the longer the developing code is isolated from the trunk - whether or not you're using a branch for the developing code.
Ah, but we're talking new module/package development here, not modifications to existing code. At least that's what the sandbox is for. --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 11 Sep 2001, Guido van Rossum wrote:
Merge problems certainly increase the longer the developing code is isolated from the trunk - whether or not you're using a branch for the developing code.
Ah, but we're talking new module/package development here, not modifications to existing code. At least that's what the sandbox is for.
So drift (like you were mentioning for the type/class development) is hardly an issue for or against using branches here. I suppose the more relevant issue is polluting the repository with stuff that winds up never being accepted for incorporation to the distribution - forlorn files that live forever in the Attics, and directories that show up empty until you do a 'cvs up' with the "-P" option... Again, i don't mean to insist on using branches instead of the sandbox. I guess my concern is that branches do offer wins in some cases, particularly for stuff that is clearly on track to be incorporated... Ken
"KM" == Ken Manheimer <klm@zope.com> writes:
KM> Again, i don't mean to insist on using branches instead of the KM> sandbox. I guess my concern is that branches do offer wins in KM> some cases, particularly for stuff that is clearly on track to KM> be incorporated... The other problem with branches is that they get much less testing than the trunk. I think people in general don't check out branches unless they have to <wink>. Using the sandbox is great for small, single modules. I'd prefer to see larger candidates use something like SF to prototype. -Barry
There's a third possibility, too. It might not be necessary to mention, because I think it's a typical case. It's good to be sure that everyone considers it, though. I think it's best if a module can be developed as a standalone module, first, and incorporated into the standard library after its matured. It's not unusual for substantial user experience to influence the design and implementation of the module. So it's better to wait until after that experience has been achieved to include it in the standard library. A few examples come to mind. I'm sure there are others: asyncore & asynchat, unittest, and xmlrpclib. One possible result of that user experience is that the module isn't right. The problem needs to be solved in a different way, or there are very few people who use the module. In those cases, we're not saddled with a module that we don't want. One example here might by linuxaudiodev. After using this module and doing some maintenance, I'd prefer to see a pure Python version that provided a clearer API to the OSS interface. And the name is bad, too :-). It works on platforms other than Linux. I don't object to using the sandbox, particularly if other resources aren't available. But I'd also be happy to have new modules developed in their own homes. Jeremy
participants (5)
-
barry＠zope.com -
Greg Stein -
Guido van Rossum -
Jeremy Hylton -
Ken Manheimer