|
in reply to Run your own perlmonks!
Disclaimer: I am one of the gods, but I speak for myself, not the gods as a whole or any of the other gods.
We have here a community of motivated hackers, who know the language that PM is implemented in. We have a body of software. Why not apply one to the other?
Patches welcome.
As to the window between when a flaw is discovered and when it is announced, that will get shorter if the flaw is public, now won't it.
Will it? What if the flaw isn't easily fixable? What if no god is around to apply the fix? I realize these questions apply whether a flaw is discovered by reading code or by guessing at opcode parameters. That doesn't mean handwaving will magically answer them in either case.
The first is that more gods should help, or the ones we have could take some interest.
Yeah, and I should be richer and better looking.
It seems pretty arrogant and selfish of you to tell volunteers what they should and shouldn't do, especially since those volunteers have been keeping this site running for years. I suppose in some perverse way your frustration and demands could be interpreted as appreciation, but my brain just won't do that today.
Getting patches to be public, commentable, and votable would take some work, but IMHO the work is well worth it.
Voting on patches is a terrible idea. Perl Monks is not run by consensus. It's run by people who've proven themselves knowledgeable, mature, and trustworthy over the span of years.
I don't know of a single open source project that votes on patches in the terms I think you're describing — I think it'd be a fiasco. You're welcome to prove me wrong, though.
...it would become easier, and more likely to happen, as more people could see the code and do the work.
In my experience, getting people to do work is more work than doing the work yourself around 90% of the time. I don't expect more than two new coders to show up and write anything of merit if the codebase were opened completely.
Besides that, what are you going to do if you know that the code for the Personal Nodelet is just "pull some fields out of the database, linkify them, and put them all in a string"? Saints in our Book is just "pull some fields out of the database, linkify them, add some colors, and put them all in a table in a string". I don't think even the backup script is that interesting — if you've done any sort of web programming with Perl and databases before, you've already got the hang of it and you can learn the features of the Everything Engine from existing, open sourced code already!
Besides all of that, it's not difficult to become a member of pmdev. Making you work a little bit for it is a way of making sure you're serious. Again, even that doesn't mean that every member of pmdev has proposed a patch.
There are a lot of shoulds and maybes and mights in your post. I'd rather have facts. What are you going to do? What have you been prevented from doing? What are you going to do with the Perl Monks code that hasn't been released that you can't do with the code that has been released? |
Re: Re: Run your own perlmonks!
by demerphq (Chancellor) on Sep 29, 2003 at 13:17 UTC
|
Patches welcome.
Patching Everything wont help PM. And I think the motivation of PM'ers who want to participate is to change PM, not the latest release of Everything, which by all indications PM will never use.
It seems pretty arrogant and selfish of you to tell volunteers what they should and shouldn't do, especially since those volunteers have been keeping this site running for years.
Im perturbed by this comment. Actually what theorbtwo is saying is that the volunteers should open up to more volunteers contributing. This means that by having the older hands do a different kind of work (essentially management and oversite of a busy pile of pmdevers) the sum total of work being done grows drammatically.
Let me put it this way, if Linus or Larry insisted that every line of code in Linux and Perl was written by them in their style using the solutions they wanted to see implemented then neither would be the raring success it is. The success of both is a credit to these gentlemens maturity. They simply sit back and throw the occassional veto in. They stay at the high level of oversight and planning. They tend not to grind axes with their community. And if they dont have a personal solution that is better than a reasonable proposal they sure dont ignore or block the reasonable proposal. From what I can see pumpkings are specifically chosen for their maturity.
The fact is that there are only a mere handful of patches out of several hundred that have been written by pmdev that have been applied. Just about all that have been applied have been written by on of the gods. So this says that the gods really are pmdev and that they aren't actually pumpkings in any sense of the word. Which leaves me to wonder what the point is. And before you speak about quality ask yourself, of the many patches posted by pmdevers that have been ignored or not applied can it really be true they _all_ suck? Does it make sense that _none_ of them have been applied because there is a better solution coming down the pike?
A pressing example of this is your signature patch. It was poorly thought out. I have posted patches to it which correct its flaws and to make it consistent for root nodes and for replies. You haven't applied it. Why? Personally my guess is that you are insulted by this. Given what I see of your comments about the audience here you probably look down at me and find it hard to accept that I could possibly fix or improve what you have made. Yet the fact remains that I have. If our situations were reversed very soon after I saw the audience response (not positive, somewhat irritated) I would have applied the patches provided to me that improved the behaviour. And then thanked you for cleaning up my mess.
The core issue here to me is that the gods need to either expand their group with conservative but interested individuals for handling minor patches. (A responsible god would not apply a patch they did not understand.) Or they need to start spending more time doing the same, or they need to tell the pmdev group that basically its unlikely that a patch will be accepted or applied so dont waste your time, or maybe just comission specific patches from the pmdev team so that people wont waste their time.
Whatever happens I think the frustration theorbtwo has expressed is a genuine positive comment about the monastery. There are committed interested individuals who wish to contribute as only a hacker can to something they love. Denigrating them for wanting to do so is beneath the character of the monastery In my opinion.
In my experience, getting people to do work is more work than doing the work yourself around 90% of the time.
Then you obviously dont know how to delegate. The only way I can see this being true in your life is if you like to micromanage people doing work for you. Its obviously not generally true otherwise organizations and businesses would not be able to function, having a situation like that that would just mean that financial collapse is on the way.
I don't expect more than two new coders to show up and write anything of merit if the codebase were opened completely.
Think about it chromatic. This comment is pure elitist nonsense.
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply]
[d/l] |
|
|
demerphq, I respect you and I often agree with you. I think you're very wrong about my intentions and my character in this situation and I regret that.
I think the motivation of PM'ers who want to participate is to change PM, not the latest release of Everything, which by all indications PM will never use.
I believe we could use the latest release, which is much nicer, better documented, and easier to adapt.
if Linus or Larry insisted that every line of code in Linux and Perl was written by them in their style using the solutions they wanted to see implemented then neither would be the raring success it is.
That's exactly what Linus does. Larry is much less involved in the day-to-day decisions and he has amazing powers of compromise that nearly always lead to better decisions, but I've seen him shoot down ideas and implementations that he doesn't like.
A pressing example of this is your signature patch. It was poorly thought out. I have posted patches to it which correct its flaws and to make it consistent for root nodes and for replies. You haven't applied it. Why? Personally my guess is that you are insulted by this.
You are welcome to guess, but please believe me when I say that you are completely wrong. I wrote my patch for three reasons:
- Some signatures bother me and I'd love to be able to ignore them.
- I believe that code that sorta works is much better (even just as a discussion point) than a brilliant patch that isn't even written.
- I thought it would take less than five minutes.
The reason I haven't applied your patch is that I'm on vacation this week — I've been travelling, with sporadic access. My system administrator experience taught me never to apply patches before or during vacation. I'm willing to take responsibility for that.
Then you obviously dont know how to delegate... This comment is pure elitist nonsense.
"Merit" was obviously the wrong word, and I think that explains your interpretation of my comments. I don't mean to say that only people who've been on Perl Monks for four years are capable of writing patches. I simply mean that, in my experience, for every ten people who ask for the source code to a project, one will download it. For every ten people who download it, one will read it.
The numbers of people who patch open source projects are shockingly small — in my case, out of hundreds of modules I've used, I've probably written patches for a dozen or so. There's nothing wrong with that, but it doesn't match my experience that there will suddenly be a flood of bugfixes and new features if all of Perl Monks were to be made ready for download.
Your point about not enough patch checking and application is well taken — I think that's the most productive discussion we could have.
I don't think that saying, "Hey, volunteers! DO THIS YOU HYPOCRITES!" is productive, though, and I definitely got that tone from the original post. Whether that's fair or accurate, theorbtwo will have to judge. I could be misinterpreting his intent very badly.
| [reply] |
|
|
I think you're very wrong about my intentions and my character in this situation and I regret that.
I think that this reply shows that you are correct that I have misjudged you. For that I too am regretful, and offer an unreserved retraction and apology of that part of my comment. Your rationale about vacations is very true, and one that I've heard from many a wise person.
That's exactly what Linus does. Larry is much less involved in the day-to-day decisions and he has amazing powers of compromise that nearly always lead to better decisions, but I've seen him shoot down ideas and implementations that he doesn't like.
I still believe that both Linus and Larry are very mature about these things. Ive seen Linus shoot things down, and fwict its with a rationale and a replacement. I know that he is very conservative in some respects, (I found his point of view on interfaces to be very illuminating,) but I do believe that he has strong delegation skills and does not insist on overseeing the very minutae of everything being done.
"Merit" was obviously the wrong word, and I think that explains your interpretation of my comments.
Yes I believe it does. I think I now understand what you were driving at. I think however that for open source to work properly the guiding lites need to be as encouraging as possible of new sparks. Its very important to encourage people to contribute, even if their contribution is below par. A person only capable of patching the perl documentation for typos and clarity one day will be the pumpking. (I make this as a general observation.) The newbie reading this with 1 XP in the bank right now will in two years be a core member of pmdev, etc...
Your point about not enough patch checking and application is well taken — I think that's the most productive discussion we could have.
I agree heartily. Another discussion is providing a dev/test enviornment for experimenting on. Since PM seems to be its own beast such an enviornment seems critical to any kind of serious collaborative efforts. As would of course an expanded group of people able to post patches. (Its a pity there is not some way to graduate such access rights.)
I could be misinterpreting his intent very badly.
Personally I think you have. I do think that to a certain extent his node was designed to have some shock value. And personally I agree. Its long been a minor frustration that pmdev isn't more coherent. I think that underlying theorbtwos comments is that frustration. More people with access to the code would mean more patches. More patches would mean more coordination and patch applying was required.
Ultimately I think the question comes down to what type of site this is. There has always been an open kind of sharey vibe here. We share our knowledge and our skills and our time and sometimes even our personal lives here. Does this also mean that we share in the development of the site? I say it would be better if it does. As I said earlier I also realize that this is a question of balance and risk, and that the answers are not easy. I just hope that the gods want this to be the kind of place that I do and so make more or less the decisions I would.
Cheers,
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply]
[d/l] |
|
|
In my experience, getting people to do work is more work than doing the work yourself around 90% of the time.
Then you obviously dont know how to delegate. The only way I can see this being true in your life is if you like to micromanage people doing work for you. Its obviously not generally true otherwise organizations and businesses would not be able to function, having a situation like that that would just mean that financial collapse is on the way.
You overlooked a minor detail. It's the implication of the word "voluntary" in chromatic's sentence. Most businesses pay the people that do their work for them. So I'm not concerned about financial collapse, just yet.
While I appreciate your sentiment, I think you're reading chromatic's post much too negatively.
I do believe that he has a good point when he says we're not likely to attract a lot of volunteers by opening the code base. After all, getting adopted into pmdev is not very difficult (heck, I made it in just because I inquired a few minor details about the site from tye to write my newest nodes interface). That fact could, maybe, be advertised more, of course.
But as tye has explained time and again, and which is something only implied in chromatic's post, the lack of gods is a problem because patches have to be tested - both by themselves as well as in their interaction with the rest of the codebase. Obviously, it's easy for a god to do that for their own code on the "shadow" PerlMonks devel setup they have. Since that one runs on a backup of the live PM database, I can understand that they don't want to open that. (Or do you want all your /msg's out there for everyone to read?) So you have a situation where a small handful of people (with limited time on their hands to boot) have to validate all foreign code passed in from outside.
I think the biggest problem we face is what perrin has often complained about: that the code is stored in the database. Were it completely separate, it would be much easier to make the code available, and hand out a mock up database to test it with, without any of the security and privacy issues of the current setup.
Before that changes, contributing to PM development is always going to be a cantankerous matter.
Makeshifts last the longest.
| [reply] |
|
|
because patches have to be tested
Indeed. In fact I mentioned it twice in this thread already. :-)
Don't tell anyone, but that issue is currently in hand, and with a bit of effort and luck will be a done deal in a few weeks, if not sooner.
While I appreciate your sentiment, I think you're reading chromatic's post much too negatively.
I may have. I think I did him a disservice in my original reply that I apologised for. I think that if one point this thread makes clear is that its real easy to mistake the underlying intentions of people who are passionate about what they believe (in), especially is such an inpersonal forum.
cheers
---
demerphq
First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi
| [reply]
[d/l] |
Re: Re: Run your own perlmonks!
by bunnyman (Hermit) on Sep 29, 2003 at 18:06 UTC
|
Voting on patches is a terrible idea. Perl Monks is not run by consensus. It's run by people who've proven themselves knowledgeable, mature, and trustworthy over the span of years.
I don't know of a single open source project that votes on patches in the terms I think you're describing — I think it'd be a fiasco. You're welcome to prove me wrong, though.
The Mozilla project allows users to vote on specific bugs in the bug tracking database. This gives developers feedback about which bugs to fix first and which features they should add. This is different from voting on the actual patches - the users don't vote for those, but they are free to comment on them if they want. This is a nice way to keep the users feeling like they matter to the project, without giving them the ability to make messes that the developers have to clean up.
Besides that, what are you going to do if you know that the code for the Personal Nodelet is just . . .
I'll give you a counter example - why does anybody need to know that /bin/ls is "just" calling readdir() and printing to stdout? On the other hand, why does it need to be a secret? All other things being equal, I would rather have code be open. 98% of the time, I don't even look at the code, but when I do dig into it, I get to have that "oh cool, this is how it works" feeling that drives hackers to take things apart.
It isn't harmful to open up the code to the site so that people can look - unless it's insecure code, and then it should be fixed.
| [reply] |
Voting can be good!
by DentArthurDent (Monk) on Oct 01, 2003 at 13:38 UTC
|
| [reply] |
Re: Re: Run your own perlmonks!
by eric256 (Parson) on Sep 29, 2003 at 16:13 UTC
|
The first is that more gods should help, or the ones we have could take some interest.
I interpreted that as "there should be more gods, because then the work would be spread over more people", not as "the gods we have should help more"
Also, i though that voteing and commenting on patches was for pmdevils only, and while voting might not be that great, it could give gods an idea as to which patches the pmdevils thought were best/most urgent.
English is a crappy language that is open to many different interpretations. :)
___________
Eric Hodges | [reply] |
|
|
