On Nov 15, 2006, at 5:44 PM, Robert Greig wrote:
On 15/11/06, Steve Vinoski <[EMAIL PROTECTED]> wrote:
Carl, the better question is, "Why would you want do that?"
As an example: Martin and I have been working on enhancements to MINA.
We have submitted the changes to the MINA project (who I should add
are very responsive and open to improvements and suggestions), and
they are currently looking at those changes. One user, who is part of
the AsyncWeb project has tested it and found that throughput doubled
for some of their tests, so it clearly has at least some merit.
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.
If we have developed something that we as a group agree improves our
project, should we have to wait for the release cycle of other
projects? What if it is a straightforward but for us critical bug fix?
As some people have mentioned, the Apache release process can be quite
long.
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.
Does Apache have any kind of policy or guidelines for releasing
patches? Does Maven have any support for patches? e.g. can you say
take "M24 plus patches 6432 and 6433"?
In a pom, you specify a version. For development work, you can pick
up snapshot versions from the snapshot repository. For releases, my
understanding is that you can pick up only released dependencies.
For released software, though, creating dependencies like this would
be sheer insanity. You'd be generating artifacts that couldn't be
reproduced.
I don't understand this. If you include an archive of the source
surely it is reproducible? Information indicating the svn revision on
which it is based is surely sufficient to make it clear from where the
source for that dependency is derived?
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.
In an ideal world we would be able to take released versions of all
our dependencies but for some dependencies I don't think this is
feasible. Some dependencies such as MINA have a huge impact on our
software.
That's why infrastructure software often has as few dependencies as
possible. Qpid could certainly be considered to be infrastructure.
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.
--steve
