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 <[EMAIL PROTECTED]>: > >> 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 > > > > > >
