On 23 Apr 2006, at 01:11, Robert Collins wrote:
On Sun, 2006-04-23 at 00:58 +1200, Reuben Farrelly wrote:
On 23/04/2006 12:41 a.m., Robert Collins wrote:
Asking adrian on irc - '
22:34 < adrian__> Enough people using it as a traditional forward
cache
22:34 < adrian__> and saying there aren't any strange problems
22:34 < adrian__> Because its got a bad name
'
So, what is required. How can we engage the community in making
squid-3
stable ? There seems to be non-trivial interest in making it
happen, but
whats the actual benchmark ?
I'll start using it again and pushing forward with bug reports if
there's
someone there to work on them...last time I tried squid-3 I was
seeing some odd
stuff with client side connections being closed randomly and
requiring frequent
refreshing with my end browser, but at the time I didn't gather
anything useful.
There are definately people doing things around the source - I think
harnessing the energy is the issue. I only have a small amount of
time,
and I'll probably be using it on toolchain support to make it
easier for
others to fix bugs - because thats something effective I can do in the
timeframes I have available.
I've added some missing files - I could swear I had added them. Is
that
better?
Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
As one such person who's joined the list recently with a view to
pushing for 3.0-STABLE, I've got a few observations.
When someone new joins the squid-dev list, it's unclear what the
drive of the group is. New members are invited to say what they're
interested in (http://www.squid-cache.org/mailing-lists.html#squid-
dev) but it's not easy to see (a) who else is there or (b) where
we're going.
I think the website is too static and so gives the impression of a
stale project... there needs to be a frequently updated and visible
section (the homepage?) that tells everyone what has happened
recently, and where we're headed next. E.g. Drive for 3.0-PRE4. This
would rally people immediately.
Next thing to do is to use Bugzilla properly to drive and control
that effort. Define a policy which says "If there are no Confirmed
bugs of Severity 'normal' or worse for Target Milestone 3.0 (http://
tinyurl.com/fnkv9), then we've got a candidate for PRE4". We need to
make sure that list contains ONLY the bugs that are stopping a PRE4.
All others for 3.0 should either be reassigned to a future release,
or have their severity adjusted downwards.
Getting a 3.0-STABLE out of the door will inevitably mean deferring
some features to a subsequent target release (3.1?), and people
having confidence that they won't be forgotten forever.
However, once there is a reliable task list for each release, people
can volunteer in the knowledge they are helping towards a well
defined goal, rather than one they're not sure will ever be finished
- a fear that now seems well-founded given the gap since PRE3.
If this makes sense, I think the current hard-core who know the code
best (and so are qualified to make these judgements) should bite the
bullet and spend half a day making Bugzilla reflect the both the
state and goals of the project. From then on, all bugs should start
off Unconfirmed, and only core dudes should be able to confirm them.
This will keep the buglist reliable and its meaning re: release
readiness intact.
Of course what I'm suggesting requires consensus, and if it's agreed,
some slightly boring admin work. But I think that's what we need to
move forward with a release and also to attract people to the cause.
Cheers
Doug
