On Sun, 15 Dec 2002, Jon Scott Stevens wrote:
> on 2002/12/15 3:58 PM, "Henri Yandell" <[EMAIL PROTECTED]> wrote: > > > With some reflection, another alternative is that when a project becomes > > dependent on a CVS HEAD of an unreleased proejct, or even a HEAD of a > > released project, they make sure that someone documents this in the > > STATUS.html. > > > > Hen > > #1. Years and years ago, this file was originally created by me based on > some source from Jserv and put into the Turbine source code. No one bothered > to get in touch with me to say that they were going to get rid of it from > CVS and replace it with 10 more classes in a different package. No code ownership. Given Apache's current structure, I can see that committers like us should be asking Apache members for permission to do such thigns as we don't own the code, but I didn't think Apache subscribed to the notion of code ownership. The PMC are welcome to start pushing management if they wish. > #2. It was moved from Turbine into Jakarta Commons Util on Aug 7 23:23:41 > 2001. Well over a year ago. > > Given that it has been in there for that amount of time and commons-email > has depended on it for probably just as long, I think that overrides any > sort of released version non-sense. It is simple to deprecate the class > and/or submit a patch saying that the code is going to go away and be > replaced with something else. I still disagree. If an unreleased component dies because another unreleased component, I see no problem. And if that previous unreleased component is only noticed as a change due to gump reporting it, then it might be better off dead. If however it notices because the active developer working on it notices, then that's all well and good. The code hasn't gone anywhere, it's still in CVS etc. > I think the point that Sam and I are both trying to make is that the > complete lack of disregard for history and communication can't be ignored > any longer. We need to work together on things. I believe this is a problem with the Commons charter and beliefs in how Commons should work that don't seem workable. Developers should be able to focus on creating a component that is as good as possible in its own independent state. The other solution in which people dump common code into a commons project and then forget about it until something goes wrong just doesn't seem to work. Given the two very real choices between a code graveyard and a moving target, I'd choose the moving target. Yes I'd prefer a perfect project, but I like to deal in solutions that work with reality. Hen -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
