Beefy Boxes and Bandwidth Generously Provided by pair Networks
We don't bite newbies here... much
 
PerlMonks  

Re^4: Status of Recent User Information Leak

by ELISHEVA (Prior)
on Sep 23, 2009 at 05:22 UTC ( #796891=note: print w/ replies, xml ) Need Help??


in reply to Re^3: Status of Recent User Information Leak
in thread Status of Recent User Information Leak

I only wish all of that "defensive egotistical self-centered crap", much of which I wrote, were mere excuses. Unfortunately, they are not. Should this change? Can it change? You bet. Will this change? That depends on the only people with the ability to make unfettered changes to code and site policy, the gods, of which I am not one.

Perl Monks has a long list of pmdevs but only a very few who can make meaningful changes. The code for Perl monks is split into hundreds of micro-segments spread across a database. To fix any of the issues that you consider "crap" would require a coordinated set of change that affects multiple segments, possibly 10, 20 or more!

Each and every change must be individually approved and tested by a god before it can be applied. There is no mechanism to submit and approve changes as a group. There is no test bed that pmdev's can use to validate their proposed changes before submitting them. There isn't even any good system documentation to show how all the code segments work together to support each custom post-Everything-I engine feature. That means that each and every significant change is a research project. For even a simple change to a system (rather than a bolt-on feature), the amount of information generated is apparently too time consuming to review. For instance, we have a pending proposed change to address the documentation situation that is still waiting for final approval (or rejection). When I last asked about its status I was told there was too much to go through at that moment - it has been over a month and it still hasn't been reviewed, approved, or rejected.

Should there be a test bed? Yup. Why isn't there? Well, first user data, system metadata and code is all mixed together in the database. The easy part is creating a specialized query to skip over private user information and using it to generate a tarball. That has even been done already. The hard part is that security rules are all mixed up in the code rather than segregated into a separately identifiable set of code segments. There is no way to eliminate that material from the download, without extensive code review and analysis, plus changes to multiple code segments, each requiring individual approval and review. That brings us round to where we started: no testbed, too few people reviewing too many changes. It is a vicious cycle.

Making massive changes without testing is a very stupid idea. Allowing testing and significant change would require expanding the circle of trust to include people other than the current set of gods. The current set of gods simply don't have the time to manage such a large set of changes to such an extensive codebase. This would be a lot of work for a paid team, and the gods are volunteers fitting this around their day jobs. But expanding the circle of trust also carries risks as well. At the moment the risk of change appears to the gods as greater than the risk of no change.

So call these excuses if you may, but the management problems at Perl Monks are not technical problems that can be fixed just by "doing it". Do you have a solution to the trust dilemma? A better way to add more hands to the till?

If so, stop spending time complaining and step to up to the plate. If you are so fussed (and you have a right to be), make yourself known, and advocate for what you think is right. Take the XP risk. And do it in a separate top-node where it will get attention. This thread is old news and the milk is already spilt. It is time to move on.

Best, beth


Comment on Re^4: Status of Recent User Information Leak
Re^5: Status of Recent User Information Leak
by Argel (Prior) on Oct 05, 2009 at 23:50 UTC
    We have some prominent members such as Dominus, Damian Conway, Randall Schwartz, Larry Wall, et. al. who may not wish to reveal who they are when posting that kind of message (basically calling the people who run PM out). Maybe they would like the post stand on the the merits and not their name. Or maybe they don't want to ruffle too many feathers. It's hard to say, but calling the OP out for posting anonymously could be way off the mark.

    The rest of your post just supports

    "The PerlMonks code is so bad, even competent programmers can't fix it quickly."
    and thus by implication,
    "We've really poorly represented the Perl community, and we're sorry."
    As to the rest, would a new post be useful? If the gods don't really care there is not a lot anyone else can do. Unfortunately, contacting The Perl Foundation directly about this incident may be more useful at this point. And along those lines, it is becoming clearer that the long term goal should probably be to migrate PM to a supportable framework/platform.

    Elda Taluta; Sarks Sark; Ark Arks

      For the record, I have not in the past, nor do I intend in the future, to post anonymously on this issue.

      -- Randal L. Schwartz, Perl hacker

      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

        To be clear on my part, I chose people I did not think wrote that post, but did help make my point that there are legitimate reasons for posting anonymously. My apologies for any misunderstandings.

        Elda Taluta; Sarks Sark; Ark Arks

Re^5: Status of Recent User Information Leak
by Anonymous Monk on Oct 06, 2009 at 01:59 UTC
    I recall reading that there is some kind of test bed where gods test the patches.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://796891]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (8)
As of 2014-12-26 07:43 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (168 votes), past polls