As much as I detest the thought of getting into it again with you after all these years...
Jonathan Revusky wrote: > You see, what is the alternative? If you don't trust people by > default, then how is trust established? Trust is earned over time. Two simplistic examples: I mountain climb and train in several martial arts. The first time I go climbing with somebody I do not automatically assume they have the prerequisite skills, attention to detail, etc. that I have and that are necessary to keep both of us alive. I double-check their knots, their belay stations, everything they do. I become nervous if they do not do the same to me. The first time I train a joint-locking art with someone I do not assume they have the sensitivity necessary to know when to stop twisting, pressing, sealing, etc. so I will tap early and often. I _do_ have the sensitivity necessary and my partners will often comment that I began releasing pressure just as they started the tap-out thought process... but I do not expect them to trust me to stop just before things get really painful. Plus if they do not tap I lose valuable feedback about my own techniques. The application to commit access would be similar. I would check their code. I would run regression tests. Once I became confident that their code quality is acceptable and they meant the project no "harm" then I would grant commit access. Is this optimal? Eh, I don't know, I suspect not as it would take a lot of my time, but it certainly shows one way trust can be established in a project context. > I mean, this seems to be related to the catch 22 problem that you > become a committer by contributing a lot, but it's practically > impossible to contribute without being a committer in the first place, > Craig never responded to this basic question. (Somehow, I suspect he > won't.) This is a perfectly valid point... similar to every other situation in the real world: we won't hire you without experience. How do I get experience without being hired? I won't climb with you until you're more experienced. How do I get experience without climbing? It's a real problem. I _firmly_ believe that granting access to anybody that asks for it is a Very Bad Idea. One glance through the posts on this list is _more_ than enough to show me that if some of the posters asked for commit access they should _not_ get it. Yes, it's (relatively) easy to back changes out, but even that (relatively) easy process takes time that I'd rather spend doing other things. > Actually, you know, in the earlier message, where I used the terms > "immature" and "unwise" in my response to Craig, an earlier draft > contained much harsher adjectives. Of course, when somebody says stuff > like: "Deal with it or go away" that person is hardly expressing a > willingness to have an open-minded exchange of ideas about something. > Frankly, I don't think that kind of tone or attitude should be > considered acceptable. Then don't accept it and go away? I just don't think the Apache project is going to change how things work (at least not drastically, at least not now). They don't have to care what we think. I really don't see what the problem with that is... Yeah, it might be wonderful if they did everything I wanted them to, let me have commit access to the particular projects I'm interested in, etc. But... they don't and won't, and I move on. > But the real problem here, that just about everybody seems to be > skirting around is that, given the utter failure of the Struts > community to compete with Webwork technically, there surely is a need > for an open-minded exchange of ideas about these project management > issues. And the people who lost the technical competition (the Struts > people) should, by the basic logic and structure of competitition, > adopt a fairly humble attitude about these topics. > "Should" implies a level of obligation that I am uncomfortable with. It's one thing to _want_ somebody to take a different position, it's quite another to imply that they are under some _obligation_ to do so. Quite frankly, if I was in the shoes of an Apache committer I'm not sure I'd change anything either, although I would have to give this meta-discussion more thought to be sure. > I actually am not somebody with strong opinions at the moment about > web app development. I don't know so much about Spring and other > frameworks and so on. However, just from what I observe lurking in > this community, I would have one recommendation for anybody who asked > my opinion on these matters. And that is: Whatever else you decide on, > do not use Struts (I mean, don't use Struts Classic, don't use Struts > Action, don't use Struts Shale) because the community is > dysfunctional... major league FUBAR... I agree that the community may be _one_ factor in deciding a technology, but I hardly feel it should be the _only_ factor. I _do_ believe that this thread, in some ways, is doing a disservice to the Struts "umbrella". It's been disheartening in many ways, and I wish it would go away because for the most part we've been spinning over philosophical issues (perhaps we need a Struts and/or Jakarta and/or Apache meta-group). I don't believe that a non-Action-based Struts _is_ Struts (and have felt that the mailing lists should be separated as well) but it's a) not a decision for me to make or b) not something I feel I have a "right" to vote on etc. Would I _like_ a vote? Yes, actually, I would. I don't think they're related enough to group together, regardless of who the major proponents are. > In an open-source project, everybody can just leave and you're left > dictating to nobody but yourself. The fact that there are people still here says to me that for the most part people are happy (or complacent, or mesmerized, etc. :) enough with the dictatorship level that Struts has. It's certainly arguable if this is a _good_ thing, but it's really not all that interesting of an argument to me, and I do agree that it makes the Struts community look bad. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
