Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

pmdev: patches to consider (feature idea)

by crazyinsomniac (Prior)
on Mar 12, 2003 at 11:06 UTC ( #242314=monkdiscuss: print w/ replies, xml ) Need Help??

Dear pmdevils and gods,

I thought it might not be a bad idea if we could add moderation to patches. Something like 5 votes and it gets approved.

We could have a patches to consider superdoc, and a patch approval nodelet (or that can be a part of PmDev Nodelet and Patch Lister respectively).

theorbtwo thought it a reasonable idea, but one that would never happen. (btw, he suggests 4 votes to approve, gods get 2 votes, pmdevil's 1)

So what do you guys think?

Sure it might open up the possiblity for pmdevils to do bad things, but 4/5 votes is a lot.

Short of simple markup/html changes, I wouldn't approve a node until I tested it (my vow to you -- I got E installed locally and can reasonably test most everything ), and I'm sure other pmdevs would be just as scrutinizing.

PS - I volunteer theorbtwo to implement this if it comes to that , and volunteer to help ;)

 
______crazyinsomniac_____________________________
Of all the things I've lost, I miss my mind the most.
perl -e "$q=$_;map({chr unpack qq;H*;,$_}split(q;;,q*H*));print;$q/$q;"

Comment on pmdev: patches to consider (feature idea)
Re: pmdev: patches to consider (feature idea)
by Chady (Priest) on Mar 12, 2003 at 11:54 UTC

    This looks like a fine idea.

    On a different note though, (about testing a patch) - The other day I installed everything locally, but I can't seem to find a way to test pm patches, how can this be done? should I go through all the nodetypes, nodelets, opcodes... here and copy the code to my local everything and then start from there?

    Someone suggested that pm nodeballs should be made so that one can have perlmonks-like everything to test on, but I don't know what happened to the idea, is there such nodeballs?


    He who asks will be a fool for five minutes, but he who doesn't ask will remain a fool for life.

    Chady | http://chady.net/
      When i'm testing I'm mostly testing for syntactic/logic corectness, for which all that's required is creating ghost htmlcodes and the like (that part can usually be commented out).

      Testing superdocs, like blakem's improved newest nodes lister (link to go here) is easier, since it's more self contained.

      Most patches don't require a working copy of perlmonks to test ;), a working copy of everything will sufice, but even that's not entirely neccessary (fake a few global vars and you're in business).

      A nodeball might not be a bad idea -- back in the day when we were trying to port perlmonks to the latest everything, there was a dump of the database going around, I still got that, but it's dated December 16, 2001. I don't know if it's a no-no to distribute it, or how usefull it would be.

      I'm hoping if you wrote the snippet (shouldn't be hard, mysqldump database htmlcode container nodetype opcode superdoc;), the gods wouldn't mind dumping containers/nodetypes/opcodes/htmlcodes/superdocs, which is all you'd need to get a working clone going (minus settings as there seems to be some issues regarding revealing settings, not sure why). The rest is html fluf, and really isn't needed.


      MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
      I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
      ** The Third rule of perl club is a statement of fact: pod is sexy.

Re: pmdev: patches to consider (feature idea)
by JayBonci (Curate) on Mar 12, 2003 at 15:53 UTC
    I don't think it's a really hot idea. Sure patches get taken up slowly, but I think that's because of a) problems with the patch mechanism, and b) not all patches are a great idea.

    I don't think patches should automatically be approved. This overextends the boundaries of what pmdev is here for. We are here to provide suggestions, and patches, to spot bugs, etc. Making us a 1/5th god doesn't really make it the right idea.

    A better idea might be to add commenting to patches so that they can be discussed, rather than the dogpile method in the wikis. Any god can just make a change (you don't need two or whatever). If we want to throw our two cents in under a patch to say "yeah I tested this" or "this idea sucks", then that might be more organized, than some kind of automatic approval system.

    The security problems inherent there would make me itchy. Or are you talking about "needs 5 votes to be presented for application"?

        --jaybonci
        Honestly, another feature I'd like is the ability to release a patch's creation to be editable by pmdev. To seriously be able to collaborate on patches, it makes sense that we should be able to make "friendly" amendments to patches, without the actual patch nodes themselves stack up. This'd work well if we had patchcomments to back it up. It'd also help refine things into the best piece of code that the community could come up with. The semantics and social coordination aspect will form naturally from this collaboration.

            --jaybonci
Re: pmdev: patches to consider (no, thanks)
by tye (Cardinal) on Mar 12, 2003 at 19:26 UTC

    Since approving a patch allows code to run in the privileged environment, it is the power to do anything gods can do and so if we want to allow "vote to apply" then we'd need a new group that lies between gods and pmdev in power and thus selectivity. But I think that isn't the best solution.

    I think the solution is better communication on several fronts.

    Ways to encourage more discussion of patches would be good. We could just use note to reduce the effort required for this and to allow all members to see these discussions. I've already been wanting to allow all members to see the list of patches and their descriptions (but not the code details, unfortunately, since the security level of the code is still not high enough for my comfort).

    Those writing patches need to make more effort to test their patches. I've had more than one person get impatient to get a patch applied only find out that their patch has bugs that I found without applying the patch (which means the original author could have found the bug with the same effort). At the very least, take your patch and prepend "use strict; my( $q, $query, $USER, ... );" to the front of it and verify that it compiles. Do this no matter how small the patch is.

    For most patches, dummy up enough functions and variables so that you can see the resulting HTML (or whatever it produces). It isn't that much work. I've done it many times.

    Other pmdevils commenting on patches (including "code review") will help with the lack of feedback and with getting comfortable enough with a patch to apply it.

    I think there is also sometimes a problem with expectations. Applying patches takes weeks not hours. Sure, sometimes I appear to write and apply a patch myself in a matter of hours, but that is usually preceeded by weeks of getting a feel for the "policy" implications. If someone else writes a patch, then I usually haven't had the time to think about the wider implications.

    Also, schedules don't line up so it can take a week or more to get a chunk of time appropriate for the consideration and application of a patch.

    Believe me, I've got lots of patches that have been started many months ago that haven't been applied. I'm afraid that is the nature of changes to PM until several fundamental changes happen that are of big enough scope that I don't plan to be personally involved in them.

    I recently went through all of the old patches and applied a few that had been sitting around and found that the rest that I'd had on my internal to-do list had either been applied by other gods or had been superceeded by newer patches. So I don't think there are any patches more than a few weeks old that are waiting to be applied.

    I think we also need a "please don't apply" convention so it is trivial to distinguish old, unapplied patches that should be considered and old, unapplied patches that have been rejected. A reply noting the reject is helpful, but we recently had a patch applied that was noted in PMDiscuss and in the pmdev wiki as being unacceptable but it still got applied. So I think a direct indicator is worthwhile. Perhaps put "***Don't apply" plus a comment as to why at the start of the patch code and a "!" at the start of the patch description?

    I think part of the problem is that it is hard to wait if you don't think you'll be notified when something happens. It'd be nice if, after applying a patch, there was a field for /msg'ing the patch author to encourage feedback.

    Having a "*" show up on the "Patch Lister" link in the PmDev Nodelet if there are patches one hasn't seen yet would help.

                    - tye

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (7)
As of 2014-11-27 06:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (180 votes), past polls