Re: RFC: delayed Logdaemon port merge

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.

This is one of the reasons I asked for the Vary stuff to be reverted
in Squid-2.HEAD. The real problem that you'll face is where people
build stuff on top of half-working code, which then makes it even more
of a pain in the ass to both fix -or- remove.

If my cacheboy-related changes were folded back into Squid-2.8 we
could probably justify pushing out a Squid-2.8 in the next 8 weeks or
so. The Squid-2.7 release timeline was way, way longer than I expected
it to take. Squid-2.7 also ended up being held up because of a couple
of last-minute additions which caused issues. Heck, I'd even be happy
reverting my store reference stuff and go back to storeClientCopy()
based -purely- on the structural changes that have gone on.

Adrian
Received on Wed Jun 25 2008 - 12:13:02 MDT