Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: domain of dblevins@visi.com designates
 208.42.156.2 as permitted sender)
Date: Mon, 4 Apr 2005 18:29:53 -0500
From: David Blevins <david.blevins@visi.com>
To: dev@geronimo.apache.org
Subject: Re: [PROPOSAL] Geronimo PMC Managed,
 project-specific Maven Repository
Message-ID: <20050404232953.GA25797@isis.visi.com>
References: <424CCB6C.2040900@apache.org>
 <D56E8562-A293-11D9-B609-000A95D41A40@apache.org>
 <a625cdc952dff6b3ff48b139b342116f@hiramchirino.com>
 <56861E2C-A4FE-11D9-B609-000A95D41A40@apache.org>
 <20050404165904.GA20826@isis.visi.com>
 <2192527eab74167a619ce912aa234692@gluecode.com>
 <455D8734-A53D-11D9-B609-000A95D41A40@4quarters.com>
 <20050404214839.GC27942@isis.visi.com>
 <4FCFABCE-A55C-11D9-B609-000A95D41A40@4quarters.com>
 <94096a4cb6068631ba7b57e8ad117332@gluecode.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <94096a4cb6068631ba7b57e8ad117332@gluecode.com>
User-Agent: Mutt/1.3.27i

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