geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@apache.org>
Subject Re: [PROPOSAL] Geronimo PMC Managed, project-specific Maven Repository
Date Tue, 05 Apr 2005 14:01:55 GMT

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
geirm@apache.org


Mime
View raw message