> 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
