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.
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]
That much is true, assuming that you can also grab the entire build system and its dependencies, as well as all build dependencies and their dependencies, etc., and that it's all under version control, and that the upstream project hasn't done what you're doing and just grabbed a particular svn revision number to build against for their upstream projects. The transitive dependency issues involved end up biting you, and hard.
Yes this could be a problem in general but for each case I believe looking at specifics is worthwhile. In the case of MINA for example the number of dependencies is extremely small (and will shrink further very very soon when they remove the backport dependency).
That's why infrastructure software often has as few dependencies as possible. Qpid could certainly be considered to be infrastructure.
Agreed.
> 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. RG
