On Nov 16, 2006, at 4:14 AM, Robert Greig wrote:
On 15/11/06, Steve Vinoski <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED]
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
