qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Vinoski <vino...@iona.com>
Subject Re: Maven and artifacts....
Date Thu, 16 Nov 2006 15:08:40 GMT
On Nov 16, 2006, at 4:14 AM, Robert Greig wrote:

> On 15/11/06, Steve Vinoski <vinoski@iona.com> wrote:
>>
>> > However, we don't know for sure when MINA will decide to adopt the
>> > patch. They may have competing priorities for their release.
>>
>> Right. So one avenue open to you is to lobby them to prepare a
>> release, just as you lobby them to accept design changes and patches.
>
> The point I was trying to make was that in general even with projects
> where we have a very good relationship and where there is clear
> agreement that changes we need are widely beneficial they may not be
> able to do a release to fit with our timescales. In an ideal world we
> would lobby them and get agreement on a release but in general we
> should be prepared for this not to be the case.

I don't see that you have a choice. If Apache rules state that  
releases must ensure that dependencies consist only of officially  
released artifacts, as both Rajith and Dan have said, then lobbying  
to get an artifact released is your only option.

>> Yes, it can be long. But those are the rules by which we must abide
>> under Apache. As Rajith points out in a separate email, it's not even
>> clear that M1 as it stands can get out the door given its dependency
>> on an unreleased version of mina.
>>
>> I don't make the rules. I just want to live by them, as I'm sure we
>> all do, and I know that maven will help greatly in that regard.
>
> I think Brian McCallister cleared this up, indicating it was not a
> rule: http://mail-archives.apache.org/mod_mbox/incubator-qpid-dev/ 
> 200611.mbox/%3c15F925F7-6DDC-4F52-AD7E-45F7FFB734A6@apache.org%3e

No offense to Brian, but I wouldn't be so sure about that. This is a  
critical question. You're fond of linking to email messages, but in  
this case, the link we want is to chapter and verse of Apache rules.  
I've been looking for said chapter and verse but haven't been able to  
find it yet, as unfortunately there are lots of TBDs in the Apache  
release guidelines, so I sent an email to Cliff asking for help on  
this issue, but haven't seen a response from him yet.

<snip/>

>> > I do not believe this is unique to open source projects; I often  
>> work
>> > with vendor software where we get special patched versions to use
>> > until the vendor has released an "official" service pack or point
>> > release.
>>
>> Right, but I bet that 1) you don't actually reach into their source
>> code control systems and build your own patches, and 2) they manage
>> their patches such that they can be completely recreated at any point
>> in the future if necessary. You don't *take* the versions -- instead,
>> *they* release the versions to you. Similarly, for Qpid dependencies,
>> we'll want to only use artifacts that projects have released for us
>> to use.
>
> For most vendors they don't let us do (1) and we are usually paying
> them to do (2). It's a different kind of relationship we have with
> other open source projects.

What is somewhat ironic to me is that you guys see no harm into  
reaching into upstream svn repositories for artifacts, yet you insist  
on doing a whole M1 release for this existing customer. Since  
grabbing directly from svn is OK in your book, why not just save  
everyone here all the trouble surrounding M1 so far and reach  
directly into the qpid svn repository for that customer? I'm not  
trying to be combative or humorous, I'm just trying to figure out why  
it's OK to do so in one case but not in the other.

--steve

Mime
View raw message