Craig wrote (and I've quoted it out of order):
> > On Wed, 8 Aug 2001, Waldhoff, Rodney wrote:
> >
> > Or submit a patch. It'd be nice to at least pretend jakarta-commons
> > operates like any other jakarta sub-project, as it says in the charter. (No
> > offense, but I don't know you from Adam. I can't just +1 you as a committer
> > sight unseen. I'm sure you're patch is great, so submit it as such, and
> > then nominate yourself as a committer.)
> >
> We should applaud people willing to contribute packages to commons "for
> the common good".
Absolutely. And I hope my comment wasn't seen as a contradiction of that statement. It certainly wasn't intended that way.
> We should probably modify the charter to somehow confer
> committer status on the same code that these individuals
> had committer status on before.
Well, maybe. But there are at least two other mechanisms supporting that function.
The first is to list the relevant developers as committers within the initial proposal. When the proposal is accepted into the commons, those developers are automatically granted commit status. In fact, several jakarta-slide committers became jakarta-commons committers in precisely that way when httpclient became a commons component. Perhaps Dirk should have been another.
The second is simply to send a note to the list saying:
"Hi. I'm Joe, a committer over at the jakarta-X project, and I'd like to (continue to) work on the foo component now that its moved into the commons, so I'm nominating myself as a committer and calling for a vote."
The second way isn't quite so automatic, and takes just a little bit more effort, but that effort doesn't seem too onerous, and it would be in keeping with the notion of Apache as a meritocracy.
> but Dirk isn't somebody who wandered in off the street :-).
Right, and a note like the above is likely to be taken more seriously than "I'm Jack, someone who just wandered in off the street and I'd like commit access to your CVS repository."
We did also explicitly consider this point (or at least a very similar one--giving every jakarta committer direct commit access to jakarta-commons tree) when establishing jakarta-commons and decided against it. I don't have a terribly strong opinion either way, although I think the two mechanisms described above are probably sufficient.
The "requirements" for becoming a commons committer aren't all that difficult (and become less difficult all the time as the number of committers goes up). But the notion of giving every Jakarta committer committer status in commons isn't all that much different than saying "I'm an ORO committer so I should be a log4j committer too" (Well, the argument for open access to commons is a little stronger than that.) Like every other Jakarta project, commons is a slightly different community than the others, with different needs, concerns, conventions and practices. Having some sort of gating mechanism, however slight, is one way to "indoctrinate" (if you'll ignore the negative connotations) new members of the community to those practices. Otherwise it seems likely that commons becomes some sort of incoherent dumping ground as other teams drop in new components, become dissatisfied with the results or loss of control, and then abandon them.
(And please note, I'm making no assertions about Dirk or anyone else in particular here. I stopped talking about Dirk several paragraphs ago.)
> The source of the httpclient package code *was* the
> jakarta-slide project, where Dirk is a committer, and
> where this code was in use. (In the same way, digester
> and beanutils came originally from Struts, where it's been
> in use for over a year).
We should certainly be sensitive to the needs of the "donating" project, but perhaps no more so than any other "customer" of the component--within Apache/Jakarta and beyond.
As with all open source development, when you "release" a project to the community, you gain some things, like having a larger group of developers test, document, fix, maintain and enhance that project (and projects that may interoperate with it). But you also lose some things, namely a bit of control over the evolution of that precise code base. You're always free to try to push that evolution in one direction or another, or (under the Apache license at least) to fork it off and do whatever you want with your forked version of the code. But you've lost the ability to directly control that evolution without gaining some sort of consensus with the larger community. (You may lead but they don't have to follow.)
> But we should also be sensitive to arbitrarily
> changing APIs that the original "source" project
> depends on, without gaining agreement (Yes, I
> understand that it was unwitting in this case [...])
Absolutely. And I'd argue that the process is working precisely as it should here. It was unwitting, but even if it wasn't, didn't this happen exactly the way it should? We deprecated a method or two. Dirk spoke up and said "wait, don't deprecate that, I need it for X", and now we're (Dirk too) working to find a way to support that.
(Note also that this particular component isn't yet at a 1.0 release, so it shouldn't be too surprising for it to change from time to time. If it needs to "change back" for some reason, it can and certainly should do that.)
> this situation illustrates one of the social issues we
> need to be sensitive about when migrating packages out
> of other projects and into the commons.
I think your concern here is valid. This is a critical (in the sense of "important") interaction, and one that we'd do well to handle carefully. But it seems to me that this is a healthy process.
