Re: Strategy

"only focus" should really have been "our main focus at that short
period of time", not "the only thing we care about."

Sheesh. :P

Adrian

2008/9/22 Alex Rousskov <rousskov_at_measurement-factory.com>:
> On Mon, 2008-09-22 at 10:36 +0800, Adrian Chadd wrote:
>> Put this stuff on hold, get Squid-3.1 out of the way, sort out the
>> issues surrounding that before you start throwing more code into
>> Squid-3 trunk, and -then- have this discussion.
>
> If "this stuff" is WordList, then "put this stuff on hold" is my
> suggestion as well.
>
> If "this stuff" is String, then I think the basic design choices can be
> discussed now, but waiting is even better for me, so I am happy to
> follow your suggestion :-).
>
> If "this stuff" is how we improve "teamwork", then I am happy to
> continue any _constructive_ discussions since releasing 3.1 can benefit
> from teamwork as well.
>
>> We can sort this stuff out in a short period of time if its our only focus.
>
> The only focus? You must be dreaming :-).
>
> Alex.
>
>
>> 2008/9/22 Amos Jeffries <squid3_at_treenet.co.nz>:
>> >> On Sun, 2008-09-21 at 23:36 +1200, Amos Jeffries wrote:
>> >>> Alex Rousskov wrote:
>> >>>
>> >>> > * Look for simpler warts with localized impact. We have plenty of them
>> >>> > and your energy would be well spent there. If you have a choice, do
>> >>> not
>> >>> > try to improve something as fundamental and as critical as String.
>> >>> > Localized single-use code should receive a lot less scrutiny than
>> >>> > fundamental classes.
>> >>> >
>> >>>
>> >>> Agreed, but that said. If you kinkie, picking oe of the hard ones causes
>> >>> a thorough discussion, as String has, and comes up with a good API. That
>> >>> not just a step in the rght direction but a giant leap. And worth doing
>> >>> if you can spare the time (months in some cases).
>> >>> The follow on effects will be better and easier code in other areas
>> >>> depending on it.
>> >>
>> >> Amos,
>> >>
>> >> I think the above work-long-enough-and-you-will-make-it analysis and
>> >> a few other related comments do not account for one important factor:
>> >> cost (and the limited resources this project has). Please compare the
>> >> following estimates (all numbers are very approximate, of course):
>> >>
>> >> Kinkie's time to draft a String class: 2 weeks
>> >> Kinkie's time to fix the String class: 6 weeks
>> >> Reviewers' time to find bugs and
>> >> convince Kinkie that they are bugs: 2 weeks
>> >> Total: 10 weeks
>> >>
>> >> Reviewer's time to write a String class: 3 weeks
>> >> Total: 3 weeks
>> >>
>> >
>> > Which shows that if Kinkie wants to work on it, he is out 8 weeks, and the
>> > reviewers gain 1 week themselves. So I stand by, if he feels strongly
>> > enough to do it.
>> >
>> >> If you add to the above that one reviewer cannot review and work on
>> >> something else at the same time, the waste goes well above 200%.
>> >
>> > Which is wrong. We can review one thing and work on another project.
>> >
>> >>
>> >> Compare the above with a regular project that does not require writing
>> >> complex or fundamental classes (again, numbers are approximate):
>> >>
>> >> Kinkie's time to complete a regular project: 1 week
>> >> Reviewer's time to complete a regular project: 1 week
>> >
>> > After which both face the hard project again. Which remains hard and could
>> > have cut off 5 days of the regular project.
>> >
>> >>
>> >> If we want Squid code to continue to be a playground for half-finished
>> >> code and ideas, then we should abandon the review process. Let's just
>> >> commit everything that compiles and that the committer is happy with.
>> >
>> > I assume you are being sarcastic.
>> >
>> >> Otherwise, let's do our best to find a project for everyone, without
>> >> sacrificing the quality of the output or wasting resources. For example,
>> >> if a person wants String to implement his pet project, but cannot make a
>> >> good String, it may be possible to trade String implementation for a few
>> >> other pet projects that the person can do.
>> >
>> > Then that trade needs to be discussed with the person before they start.
>> > I get the idea you are trying to manage this FOSS like you would a company
>> > project. That approach has been tried and failed miserably in FOSS.
>> >
>> >> This will not be smooth and
>> >> easy, but it is often doable because most of us share the goal of making
>> >> the best open source proxy.
>> >>
>> >>> > * When assessing the impact of your changes, do not just compare the
>> >>> old
>> >>> > code with the one submitted for review. Consider how your classes
>> >>> stand
>> >>> > on their own and how they _will_ be used. Providing a poor but
>> >>> > easier-to-abuse interface is often a bad idea even if that interface
>> >>> is,
>> >>> > in some aspects, better than the old hard-to-use one.
>> >>> >
>> >>> >> Noone else is tackling the issues that I'm working on. Should they be
>> >>> >> left alone? Or should I aim for the "perfect" solution each time?
>> >>>
>> >>> Perfect varies, and will change. As the baseline 'worst' code in Squid
>> >>> improves. The perfect API this year may need changing later. Aim for the
>> >>> best you can find to do, and see if its good enough for inclusion.
>> >>
>> >> Right. The problems come when it is not good enough, and you cannot fix
>> >> it on your own. I do not know how to avoid these ugly situations.
>> >
>> > Teamwork. Which I thought we were starting to get in the String API after
>> > earlier attempts at solo by whoever wrote SquidString and myself on the
>> > BetterString mk1, mk2, mk3.
>> >
>> > I doubt any of us could do a good job of something so deep without help.
>> > Even you needed Henrik to review and find issues with AsyncCalls, maybe
>> > others I don't know about before that.
>> >
>> > The fact remains these things NEED someone to kick us into a team and work
>> > on it.
>> >
>> >>
>> >>> for example, Alex had no issues with wordlist when it first came out.
>> >>
>> >> This was my first review of the proposed class, but I doubt it would
>> >> have changed if I reviewed it earlier.
>> >>
>> >> Thank you,
>> >>
>> >> Alex.
>> >>
>> >
>> > Amos
>> >
>> >
>> >
>
>
Received on Mon Sep 22 2008 - 04:09:46 MDT