Re: RFC: delayed Logdaemon port merge

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

Kinkie: can we sort a list based on the number pulled from a regex line
match?

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

I agree there. The deadline method showed a lot of promise in theory.
Still does, but as has been demonstrated now, its not working well enough.

A Priority: field in the wiki sounds like a good alternative. Version:
only being used when its actually merged.

Under your proposal; we have only those few major and blocker bugs, and
may as well go to PRE1 now while they get tracked down. Same way 2.7
just got branched off 2-HEAD.

Alex, as the one responsible for the majority of the slipped features
can we have your opinion on this?

Amos

-- 
Please use Squid 2.7.STABLE3 or 3.0.STABLE7