I took two days away from this for work and personal stuff... back now
:)
[EMAIL PROTECTED] wrote:
>
> > that will have essentially no operational or observable meaning. For
> > example, what does it mean to have someone listed as a committer who
> > doesn't participate? Conversely, under what circumstances do we see
> > someone interested in contributing and with a prior history with other
> > Jakarta projects not being accepted? I have seen little evidence that this
> > is a problem.
>
> Only in this thread we heard few times that people from one project feel
> like outsiders to other projects. And I think this is wrong and shouldn't
> happen for the library.
>From who? I 'feel like an outsider' to every other project, but I am
sure that if I do start constructively participating, it won't be a
problem. My limited contact with Craig re Tomcat issues were nothing
but welcoming and supportive, for example.
> BTW - I feel the same way.
Ok - that's valid.
> This whole "become a commiter" is not that easy - you need to send a
> number of contributions, spend some time on the list, then find an
> existing commiter to propose you. That's not impossible - but takes time
> and nobody has time.
If you *need* to be a committer, isn't that set of things going to be
what you are going to do anyway?
> We are not talking about random people here - we are talking about
> commiters involved with a projects who want to contribute to a peer
> project something that is related with their work.
>
> Example - we wrote a simple <ant> taglib that can be used to run watchdog
> or a build from a web page. It would belong to taglibs - but I would have
> to become a commiter first, or send it as a PATCH ( and then deal with
> the fact that taglib commiters can change it and brake tomcat without me
> having any control ).
> The net effect is that I would rather keep the taglib local to the /admin
> app in tomcat.
I see the point - but I think thats different : it's one thing to add
another entry ad hoc into a list of 'similar things', as an addition to
taglibs might be (?), and another to make ad hoc changes to a singular
thing like a DB Connection Pool.
> Maybe I'm wrong about this - but my feeling is that this happen to many
> people who feel getting into another project is as hard as getting into
> the first one.
Just as commentary, I found the Velocity people welcoming to me - I did
work very hard on the parser as my first included contribution while my
Velocimacro stuff was being chewed on, but that was my choice - and I am
equally confident that if I get off my kiester and finish some things I
am working on for Tomcat, the tomcat community will welcome me as well.
At least I hope :)
> That's why I am so vocal about making sure the rules for the library are
> written in such a way that everyone should feel part of it. The challenge
> is to get people involved and getting commiters from all projects feel
> they are part of the library. Refactoring code is easy, getting people
> involved is very hard.
Well, that might make it important that we choose not only technical
leaders but social leaders as well to lead this...
geir
>
> My feeling is that the bariers between "normal" jakarta projects are
> too high. There is no distinction between outsiders and peer commiters,
> and the library is one way to fix that ( if we can make it work ).
>
> Costin
>
>
>
> >
> > There are a number of things that can't be mandated. For example, version
> > to version compatibility is one of them. However, we can choose to inform
> > people of the impact of changes, that's why I have been working on Gump.
> >
> > Overall, I believe that people will choose to participate - or not - based
> > on the quality of the code in the components, not based on how sound the
> > "constitution" for this subproject is. And if time proves that the bylaws
> > need to be tweaked, they will be.
> >
> > Finally, it is my hope that the end result of this effort is that the walls
> > between projects that people see as much harder barriers than they really
> > are will become more porous, with both people and code flowing more freely
> > between them. Much talk has been given to people getting commit rights to
> > this subproject based on their contributions to another subproject, but the
> > converse also needs to be true. If someone is working on a XML mapper used
> > by multiple subprojects, perhaps it might make sense for that person to
> > maintain the project specific wrappers for this function contained in each.
> > The project lead for Rhino is a committer to BSF and maintains his own
> > wrapper.
> >
> > - Sam Ruby
> >
> > P.S. I do try to read each of the e-mails sent to this newsgroup.
> > Generally, each time I read one, I find myself agreeing with the point that
> > person is trying to make - even when the participants clearly feel that
> > they are disagreeing with each other.
> >
--
Geir Magnusson Jr. [EMAIL PROTECTED]
Developing for the web? See http://jakarta.apache.org/velocity/
