[Zope] - Requirements for a project development system

Christopher G. Petrilli petrilli@amber.org
Wed, 30 Dec 1998 14:27:48 -0500


On Wed, Dec 30, 1998 at 09:45:09AM -0800, Curtis Galloway wrote:
> I realize that my previous message was slightly inflammatory.  In an effort to
> be constructive, here is my minimum set of requirements for any project
> development system:

I'll say this up front, which is that if you have hard and fast rules
about how things must behave to be "usable" and a system doesn't mean
those rules, why don't you just move on, rather than trying to spin the
world into your own orbit?  THis isn't an attack, just an observation...
many people have their own views and they're all equally valid, but that
doesn't mean there's only one...

> 1. The source code should be represented as plain ASCII files.

I'd modify this to: "The source code must be accessible as plain ASCII".

> 2. All required actions must be automatable.

This is very vague... I could write a program today that used HTTP to do
all the things you need to do through it... but I agree that Zope needs
lots of work in this area

> Corollaries to requirement 1: you can edit source files with your favorite
> editor, diff them, and store them in your favorite source code control
> package.  

This will probably NEVER be doable, even Emacs stumbles over various VC
models... I don't want to end up supporting RCS, CVS, SCCS, CodeSafe,
SourceSafe, and about 20 others that I've used/seen... 

> By "source code" I mean all the information you create for your
> project: C, Python, HTML, documentation, whatever.  If there is meta-data that
> is required to make your project work, it should be stored in a human-readable
> form as well.  An example of this might be permissions on files, which would
> be stored in the form of a Makefile rule that sets the permissions..

Um, is it me or are you generalizing Zope out to full version control
and project management for everything known to mankind?  It's intended
to manage objects, period, some objects are DTML, some are Python, some
are all kinds of things... but I've never seen one for C.

> Corollaries to requirement 2: you must be able to build and maintain your
> project with command-line tools.  Being able to use a GUI or a web page to do
> things is great, but there is no substitute for the UNIX way.  Windows NT is a
> good counter-example to this rule.

I agree that there need to be CLI interfaces to shoving thigns into the
object database, and getting them out.  BUT, there's nothing saything
that the following options aren't 100% valid and workable, if you're
willing to make slight compromises:

	1. FTP access
	2. Theoretically you could build a VFS interface and MOUNT
	   the object database.  I did this once with Versant, it is
	   possible.

> Here are some examples of project tasks that are facilitated by these basic
> two requirements:
> 
> - I want to be able to take a snapshot of my whole project that I can roll
> back to at a future date.

This is doable currently, though perhaps not well documented.

> - I want one team of people to work on part of the project independently
> without clobbering what another team is doing.

How do the current draft and session management tools fail at this?

> - I need to look at the diffs between yesterday's version of the project and
> today's version to figure out what person X did.

This needs to be available, it's just a matter of grabbing the revs and
diffing them.

> - I want to set up an automated task to check out the latest version of the
> project from source control and build it on a test machine.

Um, what does this have to do with Zope?

I'm confused, all this seems more concerned with software development
than website, and while there some of the former in the latter, they're
not fully inclusive of their requirements.  I don't expect one widget to
do everything for me.  I do my Product development in RCS, even though
the website uses the Zope databse to storee things in.

I'm just affraid you've made this a MUCH larger issue than it is.

Chris
-- 
| Christopher Petrilli
| petrilli@amber.org