David Cantrell wrote: >> ... Should be a problem for someone who ALWAYS has something more >> important to do than CPAN. > > I wonder where that "always" came from. Certainly not from me. ----
Basic logic applied to your statements: David Cantrell wrote: > On Thu, Nov 24, 2011 at 08:09:35AM -0800, Linda W wrote: >>if we want CPAN to be able to be relied upon.. it's can't have >> unaddressed bugs for months (let alone a year or more)... > > I promise to address bug reports quickly if you make them more important > than everything else in my life. ---- The given reason for not fixing the bug, was that the fixing of a particular module was less 'lower priority' than everything in your life. Let E=EVERYTHING, A=ANYTHING, and S=SOMETHING and all be sets that include their definition. By definition, E⊇A (set >=), (A is any object, in set E). It is usually the case that A⊃S (>), but minimally that A⊇S (>=). Thus E⊇S (>=). If E is true "in life", then is is also true that "S" is also always true in life. ∴ (therefore) - the original statement! Q.E.D. (quod erat dēmōnstrandum (that which was to be demonstrated)) NOTE: It was an application of logic based on what you said. It may not have been what you *meant* --- that I can't know... my mind reads only extends to the UK in the case of very close personal acquaintances. Also note, the proof was designed be 'amusing' (though dry), and in no way mean to be offensive!)... ;-) > You also appear to have not noticed the word "quickly". I will deal > with *all* bug reports eventually. --- Eh? I DID mention months to a year -- to give an idea of 'quickly'. But eventually, doesn't cut it. Companies can loose millions or billions of dollars if something is stalled for a protracted period. If any SW developed for them by anyone, uses one of your modules and it doesn't work, you've affected all those who have used your module. Having all of them look bad to their clients "until 'eventually'" is a certain way to kill off contractors using perl to solve problems and it's use. Not acceptable.... So often, coming to common terminology and agreement of 'definitions' is 90% of the work in reaching an agreement about something. Damn language...screws us every time .. and worse when we move 1000's of miles away from each other and isolate our selves for a few hundred years and each evolve the 'common language' -- can the two diverse forks be merged? I will say it is better than grunts, but it's too cerebral for human communication, as we are only half-rational (approx, maybe more or less, depending on individual and who'd doing the evaluating). That's one reason why people are so easily deceived/gullible: It's constant driven into us that we should pay attention to what people "say"... and many (if not most) people do that by default. The smart ones are the ones that pay attention to all the cues...(dreadfully limited in this form!)... Cheers! Linda Oh...some text at the bottom of my post I forgot about... ;-) > Sometimes that will be by fixing > them, sometimes it will be by saying "no, that's not a bug". --- Very true, THOUGH 'bug' is a very vague term in SW. (!)Some might limit it to 'program crash/hang/not work'. (2) Others would say (not consistent with spec (not really applicable to CPAN modes usually) (3) its documentation (can fix docs or code: pick one, but sometimes there is a preference... The one that the people in QA and specialized in Customer experience, usability and satisfaction use the most stringent form, that I feel should be what we strive for in excellence. It has a few corollaries... the 'worst' (maybe most unreasonable), is (A) 'something that violates user expectations in behavior) (and note, 1 person, isn't sufficient to generate a bug report...but when '10 people call you an ass, you might consider buying a saddle', the saying goes. A.1) related: "Principle of "Least Surprise". A.2) related: "DWIM, or do the best you can (in the case of non destructive operations); safety overrides convenience... Hypothetical example: A perl that continued after doing alot better job of discerning user code errors, AND continued execution (w/a flag set). Any dangerous or file-changing ops would cause the program to halt (Insufficient integrity to write to disk)... I.e. a program even with warnings should have a -5 integrity, with errors, -30 up to -100, (these are not unix 'nice values!)... starts with some base (base either solely on the 'compile' OR perhaps on CPAN modules included and recent 'SMOKE tests', number of tests vs. # lines of source code...? whatever...just ideas). So maybe starts with a 50 integrity (**possibly** higher OR lower depending on if running with privileges (or as root) (site policy; not perl fiat). Then could have levels of ops allowed (likely this would be in a module of some sort)...though how much support from Base, (or Core), would be unknown (0-??), but example rules might say 'same dir write: requires 25 or higher, subdir path, 35 or more, rest of FS 60 or more... Etc...you get picture. Not that I'm SUGGESTING the above be implemented, but showing it as an EXAMPLE of providing a large amount of support for "DWIM" with gradations of safety checks. Just getting basics fixed I encounter major resistance! Any change to the status quo, serverely resisted... worse that conservative GOP!... In the absence of such, more primitive heuristics need to be used. Stopping full 'initial compilation' based on 1 error, is very primitive (though necessary in a primitive (as compared w/the language it is parsing, parser. Consistent and orthogonal interfaces. If A & B are parallel functions taking parallel argument types (maybe each as 1 different arg type), the common args should be parsed the same... If A is based/derived from B (even documented as such), but operates on a different type of object), functionality between the two should have similar flexibility and semantics as appropriate to their object. The derived functions should be artificially restricted to not allow similar params and similar behavior for its' class as the one it followed upon. > sometimes it will be by saying "I'm not going to fix this, would you like > to take over maintenance?", and so on. --- Only sometimes? ;-) Hey, having a CVS/merc(hg)/git/... something setup , where people can submit branches. .. would be an awesome (and probably is really NEEDED in today's world), where you can allow commit access to branches, or they can be submitted back to you for a final signoff (I would want you to sign off -- I would want someone else's eyes to at least run my code and made sure it ran and looked at it and optimally, glance over it to see if there any *glaring* errors I make mistakes ALL THE TIME -- the only way I was able to get things done well in the past was by my ability to *make* mistakes and *correct them* *faster* than most people. Now days, with my typing impeded, and programming time physically limited, .. work is alot slower to the point of near nothingness. And it's NOT possible to say "oh, if you go more slowly and do designs and flow charts and...all the other things that make managers feel warm and fuzzy, then you will get things right the first time .. I have yet to meet someone who is able to consistently do it right the first time. As I rarely feel something is good enough to be handed off to anyone or used by anyone else...(I think my having such high standards for myself that prevent me from releasing set the stage for it being especially galling when I see unfinished modules on CPAN, that are 5-7 years old where the author setup a project, and, in some cases did no work (others, a framework, but nothing useable. a 0.1 release). Such unfinished projects should be removed from main listings after, at most a year...(when detected.)...
