Re: RFC: delayed Logdaemon port merge

On ons, 2008-06-25 at 16:34 +1200, Amos Jeffries wrote:

> I definitely need to see it operating in some 3.1 release (for
> commercial reasons). If there are no objections I'd like to move it from
> the initial release list, but reserve the commit to a later release of
> 3.1. So that its no longer considered a blocking feature.

It's a fairly big change and certainly not something I would consider a
bugfix. It adds both squid.conf directives and a new daemon, which means
it has considerable impact for both users and packagers.

We should be using "release often" strategy, which means making a new
release whenever sufficient amount of new features or stable
restructuring of code is completed. In such strategy road maps is merely
a wish list, what actually gets into the release is a matter of what
really gets done, not whats on the roadmap. I am fine with seeing 3.2
released when the log daemon stuff is done, even if it means a lot of
the things currently on the roadmap for 3.2 gets pushed to 3.3.

It's not a good idea to hold up releases or commits of other tested
features unless one is waiting for a change which is in the very final
stages of testing.

Assigning version numbers to not yet ready features is really no more
than stating an intended priority. May I propose that we use priorities
instead of release numbers in the road map, resulting in a roadmap which
looks more like

- Things that have been completed.

- Things currently being worked on. Including things which have been
contracted to get done but not yet started.

- Estimated date of the next release currently being worked on.

- A general rule of thumb that new releases is normally done in N-M
months after the previous release, but depends on the development being
done.

- Priority sorted list of things we'd like to see get done.

Each item in these lists with their own wiki feature page..

Regards
Henrik