On Apr 4, 2005, at 7:12 PM, 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.
This is a fairly common line with other open source projects, and commercial and corporate development as well. We can be (gawd, it hurts to use this word) professional. People want to know what is in the the software they are deploying, that they are building products and business on. They want to know where it comes from. They want to know that others are using the same thing (safety in numbers) and they want to know that if there is a bug or patch, they can go to the source and get it.
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."
--------------------------------------
And before that, he said :
Seems like we are going in circles on this one. Can we reasonable agree that it isn't practical to hold up a Geronimo release till every project we have a snapshot depenency on is able to hand us some sort of official release of their own?
So I was confused. I do think he cleared it up.
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.
The fact is that when we do a release, and are telling people that we declare the software safe and ready to use, with the standard conventions of dependencies on other software, that I'd like to be sure that there is the absolute minimum of strangeness about what we release, and that we have the minimum of objections for adoption. Cutting our own releases of dependencies is going to be a barrier.
I think you need to be more flexible. This is especially true when dealing with a volunteer organization.
I think you are making a mountain out of a molehill. We have great relationships with those projects (we have many cross-committers), so I'm not terribly worried, especially if we do a bit of coordination, planning and help.
geir
-dain
-- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
