> 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.
BTW - I feel the same way.
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.
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.
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.
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.
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.
>
