Re: [Repast-developer] Evolutionaries and Revolutionaries

[Mark R. D. <mdi...@la...>]

Tom Howe wrote:

> Well, I agree.  We've branched the tree before.  Merging is a nightmare,
> but that's just the way it is.  However, one fundamental difference is
> that the previous branch (the scheduler) was completely backwards
> compatible.  

I just want to clarify, the branching is usually used to manage "small 
changes" on a release that are bug fixes anf the like. Usually the idea 
is that these will also be applied back into the main trunk if they are 
still relevant there. Yes branching, making allot of changes in a 
branch, and then trying to merge back in is ultimately a nightmare. I 
wouldn't advise do such an action, usually one would merge changes back 
into the truck at the same time or just after they are committing to the 
branch, then you end up with something that looks more like a "ladder" 
visually

    ____________________________  Release Branch
   /|\       |   |   |    |
    |        |   |   |    |
___|_______\|/_\|/_\|/__\|/____  Main Trunk

Initial        Incremental merges
Tag and        back to trunk on
Branch for     commit changes
a release      to the branch


First off, we should just get rid of space2.  It was a
> brief playground I was using.  

I've been working your demo model package, replacing space2 with space 
in it to see how well my changes work with your current strategy. It 
almost works, accept for some of the "Type" issues I pointed out to in 
my last email.

Secondly, I'm not convinced that we
> should make any of the topology stuff backwards compatible (particularly
> not the display stuff. Mark, we should discuss a game plan towards
> this).  

Ok, this may be reasonable, but we should be concerned about where the 
display stuff for rendering the spaces does go into as a location.

So, as such, I think that we should branch off the topology
> stuff, with the long term plan of removing the space and network
> packages all together.  

What I'm actually describing would be the opposite. Because the 
topology.space is what we want all future spaces to be, then its current 
implementation stays on the trunk (independent of where we want to place 
it in the directory hierarchy).

Because the old spaces are in the last version of RePast, we still might 
want to perform any bug fixes on them that users encounter. Lets say 
that in the last discussion on the user list about neighborhoods turned 
up a bug, then it could be fixed in the branch and a release could still 
be cut using a checkout of that branch. With this in mind, "Tagging" the 
trunk and starting a branch provides a route for these minor 
fixes/releases while giving us revolutionaries the trunk to refactor for 
the next version of RePasts space library.

So with this in mind, one might tag the current trunk and start that 
branch now for the last version of RePast.

I would also like to replace the current gui
> package with a renderer package. I suppose all of this stuff could go in
> the packages as the stand now (put your space stuff in the space package
> as opposed to a topology package), but I think the meaning is better
> with the new package names.  

This could very well be the case. I don't mind the current naming. But 
I'm noticing that there are allot of "little packages" in the RePast 
tree. Some consolidation and organization has to occur at some point. If 
your considering a "rendering" package for displays, would this also 
contain the rendering bridges you guys have talked about doing with 
geotools as well? Would this mean that there may be multiple 
implementations of renders for an Object2DGrid? Possibly for different 
rendering engines (RePast vs. GeoTools)?

> I'm not saying this so that we maintain
> multiple implementations of space (I think we will want to get rid of
> the old ones eventually), but I think the new package names are more
> semantically meaningful.  

Yes, lets say we decide at some point that in restructuring the 
directories that we want to remove the u.s.space package from the HEAD 
of the CVS, this is a point where a branch become very useful for 
maintaining any fixes on the removed package for the older versions of 
RePast where it may still exist. Ideally, it becomes the case that such 
a banch may never really get used if no bugs are ever encountered. But 
that is usually quite seldom the situation.

> We can deprecate the old ones.

yes.

> Oh, as an addendum, I should have done space2 as a branch. 

Its a tough call, I could have done my implementation as a branch as 
well. But, since we know we want to improve the core implementation of 
the space library its realistic to do it on the trunk. My opinion is 
that doing core development on a branch is difficult to merge into the 
trunk, whereas minor bug fixes usually do not effect very many files and 
can be merged more readily.

-Mark

> -----Original Message-----
> From: rep...@li...
> [mailto:rep...@li...] On Behalf Of Mark
> R. Diggory
> Sent: Monday, July 21, 2003 12:35 PM
> To: repast-developer
> Subject: [Repast-developer] Evolutionaries and Revolutionaries
> 
> 
> In the process of versioning any software development project there will
> 
> always be the challenge of balancing Evolutionary (modifying the current
> 
>   based while maintaining as much backward compatibility) and 
> Revolutionary (creating new and novel approaches to solving a problem 
> that are not necessarily backward compatible). There's always been allot
> 
> of discussion about this process on the Apache lists.
> 
> This comes from a thread of discussion at Apache that has been 
> formalized into a general policy for managing development in Open Source
> 
> groups.
> 
> http://incubator.apache.org/rules-for-revolutionaries.html
> 
> How does this apply to the current RePast source tree? We need to 
> consider how we will move forward with the development of the new space 
> library and its relation to the old space library. Currently, we have 
> taken what amounts to a "revolutionary" path by creating a new space 
> package inside the topology package.
> 
> 1.) Is this truly the location we want to work with new spaces in?
> 
> 2.) Do we really want to support two different space libraries in the 
> next version of RePast?
> 
> 3.) The new space/topology package is starting to encounter limitations 
> in attempting to retain backward compatibility with the old 
> Discrete2DSpace interface. There are methods there that no longer seem 
> ver relevant and can tend to confuse the user in the new api.
> 
> 4.) I retained Backward compatibility against the Discrete2DSpace 
> interface to allow rendering in Object2DDisplay to still work with the 
> new library. But, upon reviewing the code in these displays I'm 
> beginning to think I can even improve and consolidate these display 
> classes in the same fashion as I have the consolidated the space library
> 
> code. It is the case that in all new ObjectSpaces the Location can be 
> used as a "List/Set" over which the Display rendering can occur and 
> quite independent of the actual implementation underlying the 
> Object2DSpace. I'd like to begin improving this code, but I'd like to 
> avoid creating "new" Display classes to do this.
> 
> 
> With these questions in mind, we should discuss the goals and future 
> direction of both the space and the display packages and what we hope to
> 
> improve and what we hope to maintain. I think that it is important to 
> focus on the strategies we can take for approaching these goals in the 
> cvs source tree.
> 
> 1.) Branching vs creating new directories.
> 
> Branching is a means of establishing different "versions" of the source 
> tree based on setting "tags" at appropriate versions in the source tree 
> and then providing "branches" that constitute changes that are 
> maintained only in that branch. The benefit of this approach is best 
> seen at Mozilla.
> 
> http://www.mozilla.org/roadmap/roadmap-05-Jun-2002.html#tree-management
> 
> here mozilla maintains a number of branches that break from the trunk of
> 
> the cvs at version releases, these provide stable positions to apply bug
> 
> fixes and stablization releases for that particular release and 
> constitute a means of keeping backward compatibility across minor 
> changes with a major release branch. Commits to these branches are also 
> applied back into the trunk to capture those changes across the entire 
> project.
> 
> What this strategy provides is room on the main "HEAD" branch of the 
> tree for more aggressive refactoring and modification without 
> compromising the the release of minor improvements to the "release 
> branches" themselves. Eventually, over time, release branches are 
> "abandoned" as new releases are established. On the Mozilla timeline, 
> this can be seen in that after a certain amount of time a branch 
> "dissolves" as all the "bugs" are fixed and the release is stabilized.
> 
> When all the developers on a project are in one room, its allot easier 
> to maintain a cvs tree thats branchless, because theres usually a common
> 
> direction for all those developers. When a project becomes more "Open" 
> to multiple groups and development by multiple groups, its more the case
> 
> that branching is a necessity because developers from different groups 
> are more "apt" to make changes that others in the group may not be 
> prepared for, such changes also have a tendency to occur right after a 
> major release, as the group tends to push individual developers not to 
> make drastic changes until a stable release has been cut. Thus branching
> 
> is critical to establishing stable backward compatible minor versioning 
> while still allowing more aggressive refactoring on the main trunk.
> 
> Creating new directories is often a compromise which is made in smaller 
> development groups with less knowledge of how to manage the cvs tree. As
> 
>   a group grows larger, its often the case that this gives rise to large
> 
> and complex directory structures in the cvs tree. I also think tends to 
> produce packages that are difficult to connect together as "multiple 
> interfaces/implementations can easily arise when developers are given 
> "free reign" over the contents of a particular directory in the tree. 
> For example: we currently have three current versions of spaces:
> 
> u.s.s.space
> u.s.s.topology.space
> u.s.s.topology.space2
> 
> eventually these multiple packages will need to be consolidated. This a 
> benefit of using branching to manage evolution/revolution vs creating 
> new directories for revolutionary development. the separate branches 
> maintain different developmental versions of the project. Merging the 
> branches periodically provides for changes across these various branches
> 
> to be consolidated into the trunk itself. Eventually, when common 
> agreement arises about the implementation, then a release can be cut.
> 
> This is often a process that requires both advanced knowledge of cvs and
> 
> some intensive management by the developers, and is why small groups 
> don't often do such. At some point in the future, if the RePast group 
> continues to grow, some thought should go into converting to this sort 
> of cvs strategy.
> 
> -Mark
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: VM Ware
> With VMware you can run multiple operating systems on a single machine.
> WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
> same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
> _______________________________________________
> Repast-developer mailing list Rep...@li...
> https://lists.sourceforge.net/lists/listinfo/repast-developer
>