Re: [development] Trust (was: Hit and run contrib)
On Friday, 30. May 2008, Daniel F. Kudwien wrote:
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project?
Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default.
OTOH, if there was a prepared candidate - would you really grant CVS access? Would you grant access to me?
The question is "would I trust you not to mess up my modules"? Personally, I'm confident that you are careful with other people's modules (given your previous track record), I would grant you commit access to all my projects in a second because I know that you won't abuse that power. But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. Now there are plenty of arguments against this, but I think trust is a crucial element in open source projects, and stimulating involvement is important *especially* for modules that have wide exposure and a large user base. I think granting CVS access should be the default, as well as expecting the account holders to follow a commit policy that we set up. Instead of denying commit access to single directories, we'd trash the CVS account of people who don't respect the commit policy (which would involve not pissing off the respective module maintainer). That also has the consequence that people who deliver more and better code for a given module can't be blocked by inactive maintainers anymore, instead the maintainers have to actively work on their status as project leader. Which in turn stimulates progress both of "external" contributions and of maintainer involvement. As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance. If collaboration doesn't work out (which I believe will be the exception much rather than the rule), one can still fork anything and come up with something else on his own. That's how open source normally works, and I fail to see why drupal.org needs to be the big exception. If we grant CVS access to people, we should trust them to fix more stuff than they break. If they break more stuff than they fix, retract commit access on the whole. Think about how we can make a transition to trusting people. Wishes, Jakob P.S.: A showcase. KDE has a repository where each committer has access to the whole SVN repository, and an accompanying commit policy [1] (next to other policies). Potential committers need to formally apply for an account, but when they get one then they're trusted to do stuff right. And you know what? It works. Bugs are fixed by people who would otherwise just be watching the progress, and code gets ported by people who modify the base framework. Just recently I fixed a few trivial bugs in Kate, which made me motivated enough to join the Kate development list and post a few more, less trivial patches there for review - if they're approved, I can commit them on my own. On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess. Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff. Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account. [1] KDE commit policy: http://techbase.kde.org/Policies/SVN_Commit_Policy *goes off to get his flame-resistant jacket*
On Saturday, 31. May 2008, Jakob Petsovits wrote:
As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance.
I revoke the governance part. Modules still need to have a responsible maintainer (or team of maintainers), but one that oversees and judges commits instead of being the bottleneck for committing changes.
On Saturday, 31. May 2008, Jakob Petsovits wrote:
Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account.
And just in case someone wants to imply that newbies can't get an account under that scheme: no, that's wrong. They just need to acknowledge that they are aware of their limitations in version control or open collaboration, and that because of this they won't randomly commit code into other modules that they have no clue about. So, trust doesn't need to be coupled with technical expertise, just with responsibility and knowledge of one's own skills.
Quoting Jakob Petsovits <jpetso@gmx.at>:
On Friday, 30. May 2008, Daniel F. Kudwien wrote:
We are parsing the "#12345" bit, but why don't we also parse the "by sun" bit to assign 'contributor credits' to users for the corresponding project?
Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default.
And IMO every module, as well as Drupal core, should have it's own ChangeLog file. This is standard in every other project I've ever worked with.
OTOH, if there was a prepared candidate - would you really grant CVS access? Would you grant access to me?
The question is "would I trust you not to mess up my modules"? Personally, I'm confident that you are careful with other people's modules (given your previous track record), I would grant you commit access to all my projects in a second because I know that you won't abuse that power.
But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong.
Now there are plenty of arguments against this, but I think trust is a crucial element in open source projects, and stimulating involvement is important *especially* for modules that have wide exposure and a large user base.
I'm thinking of wiki from these statements. Everyone is trusted with being able to update the document or create new documents. Everyone is trusted to fix the mistakes of others with no fuss.
I think granting CVS access should be the default, as well as expecting the account holders to follow a commit policy that we set up. Instead of denying commit access to single directories, we'd trash the CVS account of people who don't respect the commit policy (which would involve not pissing off the respective module maintainer).
I agree and disagree; see below.
That also has the consequence that people who deliver more and better code for a given module can't be blocked by inactive maintainers anymore, instead the maintainers have to actively work on their status as project leader. Which in turn stimulates progress both of "external" contributions and of maintainer involvement.
It helps with the collaborative effort, yes.
As of now, modules are considered to be the personal property of a given person or company, even if their importance has a much higher impact than those. I think we should get away from this notion, and consider modules on drupal.org the joint property of the community, not only in license but also in governance. If collaboration doesn't work out (which I believe will be the exception much rather than the rule), one can still fork anything and come up with something else on his own. That's how open source normally works, and I fail to see why drupal.org needs to be the big exception.
This "personal property" is one of the reason we have such a large number of duplicated modules. However with the "take over" process already identified, I shouldn't need to duplicate for this reason any longer.
If we grant CVS access to people, we should trust them to fix more stuff than they break. If they break more stuff than they fix, retract commit access on the whole.
Think about how we can make a transition to trusting people. Wishes,
If I have a module that I've put a lot of work into then "personal property" is how I would feel about it. I wouldn't want Joe Schmuck coming along and undoing some long hard work and thus creating work for me to retract his changes. Commit access without collaboration isn't a good thing. Commit access with collaboration is a good thing but I would want to have the control over when a person can commit. It would even be nicer to be able to control that commit access to a particular branch tag. However, for the abandoned modules this would be a good start to develop the infrastructure. The modules could become open and everyone has the right to create a release. There are some modules that are just simple and need a touch here and there when a new core release are made; this idea fits perfect from them. Perhaps on the CVS access page for the project an "Open for all" could be established for a project and the maintainer would then be "Community". So if a maintainer is turning over a project he can just grant access to everyone and move on.
Jakob
P.S.: A showcase.
It can work but there has to be a lot of rules in place and that infrastructure isn't ready here. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Jakob Petsovits wrote:
Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default.
Here's a counter-showcase for you. :) That's how contrib used to be, back when I joined the project (June 2005). On my very first CVS commits to Quiz module (my SoC project), because... a) I didn't know what the hell I was doing and had never used CVS before b) The only docs for CVS back then were geared toward people who already knew CVS and thus were totally useless to me c) Therefore, I was using TortoiseCVS since that was the only thing that made sense and there were absolutely NO docs in the handbook for that ...I ended up somehow changing code in Voting module accidentally during my commits. Look! You can still see it in the list of commits on my user account page. ;) http://drupal.org/user/24967 (I think I did a checkout of the entire contributions repository, added my files, and then committed *everything* from the root modules directory, and in the time between me checking out contrib and getting my stuff ready to commit, Voting module had made a change, and I ended up committing old stuff back. Maybe. I'm still not sure how I ever managed to do this.) Anyway, I got yelled at for it, and directed to send the maintainer of Voting module an e-mail to apologize. After my life finished flashing before my eyes, I did so. Fortunately, he was a nice guy and said it was okay, and managed to undo the damage I'd done, which was great, because I had absolutely no idea how to possibly fix it myself. But how annoying and frustrating must it have been for him, in addition to the stuff he already had on his plate that day, to have to add "fix webchick's stupid CVS mistake" to his TODO list? :( Yes, the docs are better today, and yes, the collective intelligence of the Drupal development community has risen significantly in the past 3 years, so there are more people I could've asked for help nowadays. But consider that I single-handedly managed to cause this poor maintainer at least 20 minutes' worth of un-screwing up what I'd done. And I'm just one person. Figure that some percentage of CVS accounts are newbies like I was (I'd even go as high as 20%, given the questions that regularly pop up on #drupal), and throw the fact that you can branch and tag now and that those have implications on the release system, and that's a *frightening* amount of time that would be spent undoing mistakes, by both module maintainers and the CVS admins. Read http://lists.drupal.org/pipermail/development/2006-May/016096.html for more behind the rationale for this change, but IMO this was one of the smartest things we ever did as a community. If anything, this encourages us to allow *more* people to have CVS accounts, because at worst, the only thing they can really screw up is their own modules, not everyone else's. And although I like you a lot and respect your development skills, Jakob, I don't want you or anyone else but Earl Miles and people he's specifically christened as knowledgeable, committing *anything* to Views module, which is used on approximately 40 gazillion sites, even if it is a "simple" break; fix. :) That module is critically important for the community, and Earl has done a fantastic job of maintaining it. Secondly, shame on you for wanting to commit something without a corresponding issue #. Tsk, tsk. ;) Oh. And let's not forget the fact that Update Status module now yells loudly when there are new versions of modules available. So if I'm tracking dev releases (which I might be, while my site's in development, to get the latest stuff) I could cvs up and get the parse error you accidentally left in your break; statement fix (cos, you know, you were in a hurry so you did the commit and then stepped away to go grab a sandwich and got distracted by pickles), then I start screaming at Earl Miles for committing a parse error because I'm just a poor user and don't have the ability to fix the parse error myself. And for old, crusty projects that aren't being maintained which you claim blocks contribution? Ever since Michelle wrote up http://drupal.org/node/248145 I've been noticing a rash of project take-overs (in a good way!), which has resulted both in new contributors AND support for modules that were dying from lack of attention. I follow the webmasters list pretty closely, and have never once heard back from a maintainer screaming, "HEY! What did you give away my project for?!??" The guidelines give the existing maintainer a reasonable timeframe in which to respond, while at the same time not being a horribly long time (two weeks) for a prospective maintainer to wait around, during which time they can submit patches to prove their interest in long-term maintenance, which thus makes our jobs easier to fork over the keys. Basically, are you sure that you're trying to solve something that needs to be solved? -Angie
Angela Byron wrote:
Jakob Petsovits wrote:
Imho that's a quick-and-dirty workaround, whereas the proper solution would involve letting the contributor commit the patch by herself. That might either be reached by switching to a distributed VCS (where "committer" and "uploader" are decoupled from each other - probably the right solution for core) or by the even more open-sourcey way of granting access to all of contrib by default.
Here's a counter-showcase for you. :)
That's how contrib used to be, back when I joined the project (June 2005).
On my very first CVS commits to Quiz module (my SoC project), [...] I ended up somehow changing code in Voting module accidentally during my commits. Look! You can still see it in the list of commits on my user account page. ;) http://drupal.org/user/24967
Great example, sounds like something I'd do. Some more empirical evidence: I quite often check code out of the wrong branch *of my own modules* then get confused when several months of changes have disappeared mysteriously. I have, on occasion, tried to commit to modules like Views just because of being in the wrong working directory (this coupled with the swearing that usually adorns my debug messages would make a nice surprise for Earl). I'm making these mistakes using GNU/Linux and a terminal: imagine the damage a newbie, wielding Tortoise or Eclipse, could do. I'm blonde, dippy and error prone. So please don't let give me commit access to the whole contrib repo, I *will* break it. However, the suggestion of a distributed system would work nicely. IMO that's the road we need to go down *if* we want to be more open and stop people, like me, breaking stuff. Don't know how many people view this as a priority however. My projects aren't very interesting or popular, so a distributed system wouldn't make much difference. I'm the only one working on the code! Are most other projects like mine, or would they benefit from a distributed RCS? Better plug the RCS group on g.d.o (just in case anyone on the list hasn't seen it): http://groups.drupal.org/revision-control-systems :) Kind Regards, Liam McDermott.
Jakob Petsovits wrote:
On Friday, 30. May 2008, Daniel F. Kudwien wrote:
On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess.
Let incompetent CVS users release their modules on their own server (they're probably no good for drupal.org either) and educate them to get into version control and patches before they're granted a CVS account. In turn, give trust to the people who actually have proven to be worthy of a CVS account.
Views is a large and complex system. It turns out that even very small changes can have a very large impact that is not necessarily clear to people who don't have a good feel for how the entire system is put together. Given the incidence of patches that are Just Wrong that I get (at least 10%, mostly they're Just Wrong because they fix the symptom, not the problem) from people who are perfectly confident that their fix is the right one, I shudder to think about what could happen if just anyone could commit to Views at this point. Now, this never actually happened when just anyone COULD commit to Views, luckily, but there's always been a stigma against committing to people's projects without permission. Now it's just coded. But you know what HAS happened? A lot? People screwing up and being in the wrong directory when they commit and adding their stuff to the root directory rather than their module. Or not realizing they'd left in some change when they were hacking and committed that. No, if you think you're very smart and you've spotted a bug in Views and you fix it without ever consulting anyone at all, what have you done to make sure it's right? That's why we have a process of peer review.
Jakob Petsovits schrieb:
On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess.
Would you fix the bug without opening an issue which documents it? That might be OK if you are on your own. But its a really bad idea in a team environment. Views is a large module and if you do not grok it, how do you know the break isn't missing on purpose? Eric
Jakob Petsovits wrote:
On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess.
Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff.
I just grepped and looked at 43 instances of switch() in Views 1. I find one case that might look like a missing break in the theme wizard; and it's kind of odd. Otherwise, nada. Waste of my time.
On Saturday, 31. May 2008, Earl Miles wrote:
Jakob Petsovits wrote:
On the other hand, just recently I noticed a missing break; statement somewhere in Views. Checked out with CVS. But it didn't directly concern me or pose any problems to what I was doing, and opening up a new issue would have taken more time and effort than I was willing to put in. Like, "someone will probably fix it anyways". With commit access, I would have committed the fix right away, and in the unlikely case that it's actually wrong (and a "// fall through" comment would be required instead) then Earl would have noticed and fixed it the right way. It's probably still unfixed, I guess.
Now you can critizise me for being lazy, but I think this is symptomatic and happens all the time. If we want to scale contrib, we need to lower the contribution barrier for people who are able to fix stuff, while raising the barrier for people who break stuff.
I just grepped and looked at 43 instances of switch() in Views 1.
I find one case that might look like a missing break in the theme wizard; and it's kind of odd. Otherwise, nada. Waste of my time.
Views 2. Ok, let me see if I can dig this up again... don't know anymore where I found it, but perhaps it's still in there somewhere. See you in your issue queue, Jakob
On Sunday, 1. June 2008, Jakob Petsovits wrote:
On Saturday, 31. May 2008, Earl Miles wrote:
I just grepped and looked at 43 instances of switch() in Views 1.
I find one case that might look like a missing break in the theme wizard; and it's kind of odd. Otherwise, nada. Waste of my time.
Views 2. Ok, let me see if I can dig this up again... don't know anymore where I found it, but perhaps it's still in there somewhere.
Ok, found it, and it seems that it's indeed intended (for reference, 'style_options' vs. 'row_options'). So shame on me and further reinforcing the notion that I should not be granted commit access to Views. Putting a // fall through comment instead of the break; might help avoiding stupid monkeys like me, though. Sorry for wasting your time; friends?, Jakob
Jakob Petsovits wrote:
On Sunday, 1. June 2008, Jakob Petsovits wrote:
On Saturday, 31. May 2008, Earl Miles wrote:
I just grepped and looked at 43 instances of switch() in Views 1.
I find one case that might look like a missing break in the theme wizard; and it's kind of odd. Otherwise, nada. Waste of my time. Views 2. Ok, let me see if I can dig this up again... don't know anymore where I found it, but perhaps it's still in there somewhere.
Ok, found it, and it seems that it's indeed intended (for reference, 'style_options' vs. 'row_options').
So shame on me and further reinforcing the notion that I should not be granted commit access to Views.
Putting a // fall through comment instead of the break; might help avoiding stupid monkeys like me, though.
Sorry for wasting your time; friends?,
Hehe. No prob. =)
Angela seems to have hit the jackpot though, if the maintainer is allowed to set a flag per module which shows somewhere on his module's page. On Sun, Jun 1, 2008 at 9:33 AM, Earl Miles <merlin@logrus.com> wrote:
Jakob Petsovits wrote:
On Sunday, 1. June 2008, Jakob Petsovits wrote:
On Saturday, 31. May 2008, Earl Miles wrote:
I just grepped and looked at 43 instances of switch() in Views 1.
I find one case that might look like a missing break in the theme wizard; and it's kind of odd. Otherwise, nada. Waste of my time.
Views 2. Ok, let me see if I can dig this up again... don't know anymore where I found it, but perhaps it's still in there somewhere.
Ok, found it, and it seems that it's indeed intended (for reference, 'style_options' vs. 'row_options').
So shame on me and further reinforcing the notion that I should not be granted commit access to Views.
Putting a // fall through comment instead of the break; might help avoiding stupid monkeys like me, though.
Sorry for wasting your time; friends?,
Hehe. No prob. =)
-- Ashraf Amayreh http://blogs.aamayreh.org
On Saturday, 31. May 2008, Jakob Petsovits wrote: [snip]
But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. [snip]
Ok, I figured that people way smarter than me would have no problem demonstrating why we should not do it the way that I proposed. I can live with that :) Hope it was not a complete waste of your time, maybe someone else can find a way some time on how not to make mistrust the default. So yeah, I'm done with this again already :P Thanks for reading, Jakob P.S.: Views was probably the worst possible example, with a highly skilled *and* incredibly active maintainer making random commit access not only unnecessary but (as rightly stated) also counter-productive. A better example would have been more low-profile stuff like http://drupal.org/project/comment_cck, where the maintainer hasn't committed or posted to the issue queue for half a year, with a couple of patches including a Drupal 6 port being left out in the queue. That's the classical example of a project that should be lead by the community instead of a single maintainer.
Jakob Petsovits wrote:
On Saturday, 31. May 2008, Jakob Petsovits wrote: [snip]
But that is the core of the issue at hand here - we've got lots of CVS accounts, but we don't trust them a single bit. Instead of relying on trust and goodwill, we rely on technical measures to lock out potential helpers before they even get the chance to do something wrong. [snip]
Ok, I figured that people way smarter than me would have no problem demonstrating why we should not do it the way that I proposed. I can live with that :)
Hope it was not a complete waste of your time, maybe someone else can find a way some time on how not to make mistrust the default.
No, it was a fine suggestion, no worries. :) Plus it was fun to re-live my days as a total n00b. ;) The only thing I could think of is some kind of flag a maintainer can optionally (opt-in!) set to mark their project "open" which allows anyone who wants to to commit stuff to it. I'd probably do that with every single one of my modules, since I'm a truly awful maintainer. :D And then people like Earl Miles could NOT opt-in since his module is important and he's clueful about its inner workings, but d.o webmasters could enable this flag if a module was known to be abandoned and not have a suitable person to take over. I wouldn't put this higher on the priority list than other things though, like, say, porting Project* to D6. :) -Angie
participants (7)
-
Angela Byron -
Ashraf Amayreh -
Earl Miles -
Earnie Boyd -
Eric-Alexander Schaefer -
Jakob Petsovits -
Liam McDermott