DISCUSS: Moving CVS repository
At IPC8, I asked what we could do to better "work in a fishbowl". One of the suggestions was to break the code into modules, which could selectively include outside developers. I have a decision point that I'd like your reaction on related to this: "Should Digital Creations move the Zope CVS repository to SourceForge?" Background: We do CVS by rdist-ing an internal repository to cvs.zope.org for most projects. Things like PTK have write access by external people, but can't do branches as long as the repository housekeeping files are inside Digital Creations. More importantly, we find we can't devote the time necessary to staying ahead of CVS, SSH, etc. A proposal has been floated here to move our repository to a facility such as SourceForge. We would also use it as an opportunity to break the Zope code into separately-released packages such as zope-dtml, zope-zodb, etc. The mailing lists might be re-organized accordingly. At select points we might wrap everything together as a Zope release. There are strong benefits. Sites like Sourceforge are on a fast link, presumably with fast machines behind it. They have a system where people can get their SSH accounts setup and module owners can include developers, all without a sysadmin getting involved. The major discussed downside is brand. We'd be turning part of our developer community brand over to another entity. Some have argued that this would reflect poorly. Let me know what you think, both pros and cons. --Paul
Perhaps you could work with SourceForge to develop an effective co-branding strategy. SourceForge's GUI is very rigid. If they could make it more flexible so that it could adapt to the needs of the featured products as well as to the needs of the user, then the transition between Zope main site and the Zope/SourceForge site could be made less abrupt. For exampe, if I go from the Zope main site to Zope/SourceForge, I'm probably a Zope developer; therefore I would appreciate having the navigation around the content begin to reflect my needs as a Zope developer -- namely, Python documentation, Python debugging tools, WWW specifications, related Zope resources, databases, etc. -- Loren ----- Original Message ----- From: Paul Everitt <paul@digicool.com> To: <zope-dev@zope.org> Sent: February 24, 2000 03:23 PM Subject: [Zope-dev] DISCUSS: Moving CVS repository
At IPC8, I asked what we could do to better "work in a fishbowl". One of the suggestions was to break the code into modules, which could selectively include outside developers.
I have a decision point that I'd like your reaction on related to this:
"Should Digital Creations move the Zope CVS repository to SourceForge?"
Background: We do CVS by rdist-ing an internal repository to cvs.zope.org for most projects. Things like PTK have write access by external people, but can't do branches as long as the repository housekeeping files are inside Digital Creations. More importantly, we find we can't devote the time necessary to staying ahead of CVS, SSH, etc.
A proposal has been floated here to move our repository to a facility such as SourceForge. We would also use it as an opportunity to break the Zope code into separately-released packages such as zope-dtml, zope-zodb, etc. The mailing lists might be re-organized accordingly. At select points we might wrap everything together as a Zope release.
There are strong benefits. Sites like Sourceforge are on a fast link, presumably with fast machines behind it. They have a system where people can get their SSH accounts setup and module owners can include developers, all without a sysadmin getting involved.
The major discussed downside is brand. We'd be turning part of our developer community brand over to another entity. Some have argued that this would reflect poorly.
Let me know what you think, both pros and cons.
--Paul
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
<Pual muses about openig zope access up more, and the concept of moving it to sourceforge.> Loren Stafford wrote:
Perhaps you could work with SourceForge to develop an effective co-branding strategy.
SourceForge's GUI is very rigid. If they could make it more flexible so that it could adapt to the needs of the featured products as well as to the needs of the user, then the transition between Zope main site and the Zope/SourceForge site could be made less abrupt. For exampe, if I go from the Zope main site to Zope/SourceForge, I'm probably a Zope developer; therefore I would appreciate having the navigation around the content begin to reflect my needs as a Zope developer -- namely, Python documentation, Python debugging tools, WWW specifications, related Zope resources, databases, etc.
-- Loren
I do agree with the community image aspect, it would look less-than-favorably upon Zope. That said, why not take the sourceforge code (which is freely available), and turn cvs.zope.or ginto, for example, sourceforge.zope.org or developer.zope.org? This way, you get the benefit of the server setup, with the benefit of keeping the community aspect more intact. mmmm-sourceforge-as-a-zope-portal-ly y'rs Bill -- In flying I have learned that carelessness and overconfidence are usually far more dangerous than deliberately accepted risks. -- Wilbur Wright in a letter to his father, September 1900
<Pual muses about openig zope access up more, and the concept of moving it to sourceforge.>
... Sourceforge seems to be a victim of its own success. It's often too slow to use from this side of the ocean as timeouts occur somewhere along the line and shut me down. I guess that must be due to the heavy load. -- Robin Becker
[Robin Becker, on Sun, 27 Feb 2000] :: ><Pual muses about openig zope access up more, and the concept of moving :: >it to sourceforge.> :: > :: ... :: Sourceforge seems to be a victim of its own success. It's often too slow :: to use from this side of the ocean as timeouts occur somewhere along the :: line and shut me down. I guess that must be due to the heavy load. Sourceforge crawled for me today too (West Coast USA). Worse, it appears their server denies PASV FTP requests, which pretty much locks out people behind NAT and masqueraded firewall situations.
participants (5)
-
Bill Anderson -
Loren Stafford -
Patrick Phalen -
Paul Everitt -
Robin Becker