[dev] RE: [imp] Help with attachments

Eric Rostetter eric.rostetter at physics.utexas.edu
Mon Jun 9 15:28:04 PDT 2003


Quoting "Roger B.A. Klorese" <rogerk at queernet.org>:

First, this is way off-topic to IMP now.  I'm sending this to the dev
mailing list, and any future messages should go there.  I'll not reply
to any more on the IMP list after this hits the IMP list.

> The point is that I have used the equivalent of CVS HEAD on other projects
> for a few years, some in test and some in production.  In each case, there
> is a different philosophy about (a) whether checkouts are expected to work,

If it is a real-time CVS system, then you can never expect a checkout to
work (since you could checkout the module between another developer's
checkins).  For this reason, we instruct all CVS HEAD users to follow
the cvs at lists.horde.org and dev at lists.horde.org lists, and that when a
CVS HEAD checkout doesn't work, to try updating again.  The same applies
to CVS-based snapshots.

Now, that said, most checkouts do work...  I've personally never had
a bad checkout, though I often find bugs in checkouts (usually weeks or
months after a checkout).

> (b) whether checkins are tested before being exposed to the world

We encourage all commits to be tested before being checked in.  But
sometimes things sneak by, and testing is not perfect.

Sometimes the developer making the changes can't test things themselves.
Horde supports around 20 types of authentication.  I can't test all these
if I make a change there, because I don't run all the authentication backends
(for example, I don't run radius nor ldap, so I can't really test those).
So I test what I can, and ask for help testing the rest from those who
can test them.  But they can't test it until it is checked in (so they
can do an update and test it).  Hence, I have to checkin the code untested
(actually partially tested) so that it can be further tested by others.
This is a made up example, but it serves my point.

> whether or not there is a public release content list, roadmap and
> timetable.

That is a policy decision.  In this case, Horde does differ from most other
projects in that we do not have any release roadmap or timetable.  The Horde
project takes a lot of hits for this, but there are no plans to change it.

I have no idea what a "public release content list" means.

> > So, while it appears the time was wasted, we got an updated
> > FAQ section from it, are talking about automated tests
> > because of it, and maybe, just maybe, made Roger's life a bit
> > better also...
>
> Much, much better, in fact.

Glad to hear it.

--
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!


More information about the dev mailing list