> 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.
Well, I'm not too sure about that, given all your subsequent emails which
all push in a similar direction ...
> > 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.
Good for you, bad for Slide.
The thing is :
- Contributors to the Slide project wrote most of the code in the HTTP
client
- I actually spent some time fixing the bugs I was aware of (so I believe I
was doing a relatively decent job trying to maintain and enhance it)
- Dirk has been making daily changes in Slide lately to keep up with your
changes
Yet :
- You proved you ignored my votes, or didn't count them as significant
- You obviously don't care either about the well-being of the lucky
donnating project (Slide)
- You and Morgan are apparently working for the same company. I'm glad
you're interested in the code, but it's not fair either that you use your
extra decision power to make my work on Slide any harder. I mean, we're the
ones who spent 90% of the effort that went into that component (and we
didn't stop maintaining the component either), and we're the ones who are
actually hurt by this.
I don't believe it's right. It makes us, the people who actually shared the
code, the ones who get the less in return and the most trouble.
I believe we should add a new item to the charter protecting a bit the
interests of the donating project, something like :
Until the first stable release of the component (1.0), if the component is
donated by another project :
- Any change which breaks compatibility should be avoided
- Testing changes by doing a full build of the donating project's
repository, and running a test suite (if one is available)
- Such a change requires approval (vote) of the donating projects committers
(since they're the ones); the request for vote should be posted on the
donating project's developer list
- The developer who introduced the change should try to help the donating
project's developers to make the required changes (best effort policy)
This is implicitely what happened for all the components up until now, and
it worked fine ...
If Apache is truly a meritocracy, then I believe my argument makes some
sense :)
> > 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.)
Well, I certainly didn't expect to lose all the "control over the evolution
of that precise code base", as I did.
> > 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.
Remy
