Re: RFC: delayed Logdaemon port merge

On Wed, Jun 25, 2008 at 10:54 AM, Henrik Nordstrom
<henrik_at_henriknordstrom.net> wrote:
> 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.

I agree.

> 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.

I agree.

> 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.

Sounds fine. Using version numbers is also fine IMO, with the specific
caveat that it's perfectly fine to shuffle things across releases as
development of each feature progresses.

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

This is IMO the most important thing (the way everyone does it now is great).
IMO we can afford not to be very structured, as long as everyone is
kept uptodate and aligned.

-- 
    /kinkie