[dev] RE: [imp] Help with attachments

[Eric Rostetter]

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

> A roadmap may say as little as "there is a minor release every six months
> and a major release every two years,"

I hate that kind of schedule.  Basically "We'll release a version every
<X time units> whether it is ready or not!"  This is what RedHat has
gone to (a release every 6 months) and they are all the worse for it.
This has to be the worse scheme ever invented for a release schedule.

> and may on the other hand be as
> inward-facing as the Squirrelmail roadmap which goes into great pains to
> talk about what subsystems will be reimplemented how for each release but
> does nothing to tell a prospective user when a feature might show up.

We could probably publish something like that for Horde...  So far, no one
has put any effort into it though (we only have the project's changelog).

> A release content list, or feature list, describes a roadmap in terms of
> which user-visible features show up when.

This would be harder to do for Horde, but could be done to some extent.
But this would be hard to keep up to date I would think, and take a lot
of time away from development just to document this kind of stuff.

I'd agree that we should do these kinds of docs, but I'm not sure anyone
in Horde really wants to take on the burden, myself included.

> By the way: without release plans, how do you decide what should be released
> now and what later?

The following is my take on things, and not an official Horde Policy. :)

For Horde itself, once it is well tested and stable and no one has any pressing
features they feel are a must-include, then a new release is cut.

For all the other Horde apps, it is simple.  If the changes are
backwards compatible, well tested, and stable then it should be in the
next release.  If it fails one of those checks, then it has to wait.

Once the release tree has enough changes to justify a release,
or a single change significant enough to justify a release, or any kind of
security fix, then a new release should be cut.

> How do you decide what to work on?

User requests, developer requests, and pet projects. :)

> And how do you know
> when you have something worth the effort of integrating and releasing?

See above.  If it is backwards compatible, well tested, and stable. Or
if it is a security fix.  Or a bug fix that affects a large enough group
that a new release is easier than supporting the broken release.

All of which can be put off by lack of time (darn, where are those new
sork releases I've been trying to get to for months...)

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

Why get even? Get odd!