Re: [Visualpython-users] first patch towards transparency

[Bruce S. <ba...@an...>]

--On Saturday, January 12, 2002 22:47 +0000 Do...@ao... wrote:

> OK, I'll be a good straight man.  What do you want me to do with this
> transparency patch.  (Phrase your answer as something anatomically
> possible  for an intellectually challenged physicist)
>
> Wayne Keen

The short answer is, "You don't have to do anything!" Here's the long 
answer:

What dman was doing was proposing new C++ code for the Visual module. 
Here's a very brief sketch of the way open-source development works, using 
Visual as an example.

SourceForge (sf.net) is a repository for open-source development projects, 
one of which is VPython. You can see this by going to sf.net and typing 
"vpython" into the search box. Housed there is a "CVS" repository 
("Concurrent Versions System") which holds not only the most recent version 
of each and every C++ file in the Visual project, but all previous versions 
as well. There exist (freeware) CVS programs for checking out any or all 
files from the CVS repository. Having checked them out (which does not lock 
out anyone else from checking them out), you make changes in one or more 
files, recompile Visual (the files include project compilation files for 
Microsoft Visual Studio and makefiles for Linux), and test your changes.

When you're satisfied, you run a "diff" program whose input is a current 
CVS file and your changed version, and whose output is a "patch" file of 
the kind that dman posted, listing all of the differences between the two 
files in a standardized form.

Next a "gatekeeper" (one of the small number of people responsible for 
maintaining the integrity of the project) can use a "patch manager" program 
to apply the patch file to the current CVS version to produce a new version 
of the file. There may be other patches to the file, from other people. 
With all patches applied, the gatekeeper tests the changes. If the 
gatekeeper agrees that the new version should become part of the project, 
the new version is checked into the CVS repository, using a CVS program 
that leaves the previous version in place. With all previous versions kept 
in CVS, it is possible to backtrack when something goes awry, retreating to 
a point when some feature worked. (Actually, I believe the multiple 
versions are themselves stored as something like incremental patch files 
based on previous versions, and these patch files take up little space.)

As you can see, these mechanisms make it possible for many people to work 
together. However, there does need to be good communication among 
contributors to avoid duplication and collisions of certain kinds. CVS 
doesn't automatically resolve conflicts involving overlapping patches; that 
has to be done by a knowledgeable human.

One other mechanism provided by CVS is a "branch", where someone starts a 
major project that will take a long time and doesn't want to interfere with 
ongoing work. When the branched version is ready, that person has the 
responsibility to merge the side branch into the main branch.

Python itself is a big open source development project that works in this 
way. However, it is so big that it has fairly elaborate additional 
mechanisms for planning, documenting changes, etc.

Bruce