Before this spins out of control, let's give everyone a chance to clarify. I must admit I didn't quite clearly understand the "...and they do that...." part of the email. I took the overall point to mean something like, if we need to release in-step then we should consider cleaning up the coupling between the projects, which wouldn't be an unreasonable statement.
Geir, is that what you meant? -David On Mon, Apr 04, 2005 at 04:12:06PM -0700, Dain Sundstrom wrote: > On Apr 4, 2005, at 3:53 PM, Geir Magnusson Jr wrote: > > >On Apr 4, 2005, at 5:48 PM, David Blevins wrote: > > > >>Even further, I don't think pressuring projects into giving us an > >>officially named version of our SNAPSHOT when they aren't ready to > >>release is a solution either. Then we are just turning a blind eye > >>and saying, "not my problem." > > > >Well, if we are working closely with a project (like OpenEJB, > >ActiveMQ, HOWL, etc) and they do that it's time to reconsider working > >so closely with them, IMO. I'm not saying that projects should > >release for us on a whim because they are independent and have other > >parts of their community to cater to, and I know things will settle > >down, but there are lots of users that wouldn't take things seriously > >until the pedigree of the OSS we're using is clear, and it wouldn't be > >if we were issuing our own snapshots of external dependencies. > > Geir, I think your comments are way too hard of a line to take. Let's > put this back in context. David originally wrote the following: > > -------------------------------------- > You do realize we are talking about two different things here. No one > in their right mind would propose SNAPSHOT dependencies are a good idea > for releases of any kind. Not only do I strongly agree, I think we > shouldn't switch something back to SNAPSHOT after a release. > > Even further, I don't think pressuring projects into giving us an > officially named version of our SNAPSHOT when they aren't ready to > release is a solution either. Then we are just turning a blind eye and > saying, "not my problem." > -------------------------------------- > > The reality is our timeline are not likely to align with most projects. > There will be tough times when a project is focused on another task > and not ready to cut a release (much like geronimo is now focused on > certification). In times like that, how do you propose we "reconsider > working so closely with them". Would we fork a project because they > wanted to wait a 3 weeks for an official release? Would we replace the > project? Most of the projects you listed are simply irreplaceable. > > I think you need to be more flexible. This is especially true when > dealing with a volunteer organization. > > -dain
