Re: RFC: delayed Logdaemon port merge

Adrian Chadd wrote:
> 2008/6/25 Henrik Nordstrom <henrik_at_henriknordstrom.net>:
>
>> 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 completely agree. Thats one of the things which Squid hasn't been
> doing and I've been pushing in Cacheboy.
>
>> 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
>
> [snip]
>
> Priorities are fine, but having some actual long-term directions to
> fit these features into a roadmap will make much more sense.
>
> Personally, I think you guys should consider fixing or reverting
> whatever stuff is in Squid-3.HEAD right this second which causes
> instability and release Squid-3.1.

:-) Oh I'd love too...

There's nothing in there right now thats inherently unstable (excepting
ESI and COSS from 3.0). Just a few bugs on the high-priority track.

The holdup is us still sticking with the deadline-based management we
implemented in the last round of Adrian-negotiations if you recall.

Amos

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