Infra has fixed it for us.
Carl.
Robbie Gemmell wrote:
The Qpid mailing lists have disappeared from the mod_mbox site listing at
http://mail-archives.apache.org/mod_mbox/
For a while both the incubator lists and the new top level lists were
present on the page, but now neither set are presen
Agree that Qpid as a project needs to pay more attention to licensing
issues.
I had to update a ton of files for the ASF header across all languages and
it wasn't fun at all :)
The addition of a GPL library was a honest mistake and should have been
caught during the review process.
I also agree th
Hi Aidan,
As Rafi pointed out, your proposal seems like a good fit to handle the
current situation.
However the current situation is very confusing for potential users and
newcomers to the project.
Having gone through 5 releases and looking at the queries on the user/dev
list, my experience is tha
I would agree with Rafi.
If we jump straightaway to 1.x and continue from there, people will start to
expect API compatibility.
I don't think Qpid is in a position to make such guarantee.
I also agree that we should not follow AMQP versions. Our version has to be
independent of AMQP.
BUT I think w
Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming wrote:
I think this would make a bit more sense. For me at least versions like 1.5
and 1.6 imply a level of API compatibility and client/server interop that
goes beyond what we currently test for in our releases.
I think
On Mon, Feb 2, 2009 at 11:15 PM, Rafael Schloming wrote:
> I think this would make a bit more sense. For me at least versions like 1.5
> and 1.6 imply a level of API compatibility and client/server interop that
> goes beyond what we currently test for in our releases.
I think we should adopt APR
> >> Short and sweet... I propose we move from Mx naming and with
> >> M5 move to 1.5 then 1.6 and so forth.
> >>
> >> any takers?
> >>
> >
> > Another possibility... Go to 0.5, 0.6, etc. until a version is
done
> > that supports AMQP 1.0 and that is Qpid 1.0.
> >
>
> Personally I think i
Marnie McCormack wrote:
I'd put the opposite view forward - we are currently unable to avoid doing
releases with non-interop-ing components and are also duty bound to test
against old broker/client releases (we do this for each release).
Thus I think component releases should not present a probl
Carl Trieloff wrote:
Steve Huston wrote:
Hi Carl,
Short and sweet... I propose we move from Mx naming and with M5 move
to 1.5 then 1.6 and so forth.
any takers?
Another possibility... Go to 0.5, 0.6, etc. until a version is done
that supports AMQP 1.0 and that is Qpid 1.0.
Pers
Steve Huston wrote:
Hi Carl,
Short and sweet... I propose we move from Mx naming and with
M5 move to 1.5 then 1.6 and so forth.
any takers?
Another possibility... Go to 0.5, 0.6, etc. until a version is done
that supports AMQP 1.0 and that is Qpid 1.0.
I think this would make a bit more s
Steve Huston wrote:
Hi Carl,
Short and sweet... I propose we move from Mx naming and with
M5 move to 1.5 then 1.6 and so forth.
any takers?
Another possibility... Go to 0.5, 0.6, etc. until a version is done
that supports AMQP 1.0 and that is Qpid 1.0.
Personally I think it is
Hi Carl,
> Short and sweet... I propose we move from Mx naming and with
> M5 move to 1.5 then 1.6 and so forth.
>
> any takers?
Another possibility... Go to 0.5, 0.6, etc. until a version is done
that supports AMQP 1.0 and that is Qpid 1.0.
-Steve
Some of the work being done has been around performance. At this point
we have 2 locks
that still need some work.
One of these locks are in the OS memory allocator, to this end I have
spoken to the glic/gcc
maintainers and they are working on a better malloc/free for us. However
the other si
Justin Ross wrote:
I'm all in (+10) on "Send a message." ("!" optional, imho)
I really like "I'm with Qpid", but I think I'd prefer it for a t-shirt.
Same here, for the same reasons:
+10 on "Send a message"
Nuno
-
Apache Qpi
+10 : I'm with Qpid
Carl.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
Short and sweet... I propose we move from Mx naming and with M5 move to
1.5 then 1.6 and so forth.
any takers?
Carl.
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-s
I'm personally more concerned about points 8 and 9 though. The Java
patch review process is clearly a bit hit and miss.
We caught 9 which is key. What concerns you about nine? I saw it as an
honest error that
was corrected as soon as it was spotted.
Carl.
--
First, I'd like to thank Rafi for getting M4 out. Best Qpid Ever.
Secondly, I'd like to start a bit of discussion about our development
process before we get too deep into M5. These things never go
smoothly, and there's a partial list of things at
http://qpid.apache.org/m4-release-process-notes.ht
C++ tests need Linux-isms changed to build on Windows
-
Key: QPID-1625
URL: https://issues.apache.org/jira/browse/QPID-1625
Project: Qpid
Issue Type: Improvement
Components: C++ B
On the Java broker side, we currently have no-one (unless I missed it)
declaring that they're working on 0-10 for M5. Is someone planning to
do this, firmly ? I think this has bearing on my (and other Java-ers)
views here of the short-term/medium-term requirements.
Marnie,
From the thread
[
https://issues.apache.org/jira/browse/QPID-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Huston resolved QPID-1561.
Resolution: Fixed
Fix Version/s: M5
Assignee: Steve Huston
Diff applied; Fixed in sv
Should be fixed now.
- Original Message
> From: Carl Trieloff
> To: dev@qpid.apache.org; Apache Infrastructure
> Sent: Monday, February 2, 2009 3:44:40 PM
> Subject: mailing lists are not showing on the mod_mbox site listing
>
>
> Infra,
>
> Is some one able to take a look at this,
[
https://issues.apache.org/jira/browse/QPID-1561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Huston updated QPID-1561:
---
Attachment: qpid-1561.diff
Diff for changes made on this issue.
> qmfconsole Event.h enum Severity ha
I think a key point in our decision making here, one we have not always
given enough importance to, is the needs of our existing users. A few of
them bend my ear, so here goes
Qpid has been going for quite a while now, and we have many existing users
who have deployed a Java Broker and are us
Infra,
Is some one able to take a look at this, do we need to file a ticket?
Carl.
Robbie Gemmell wrote:
The Qpid mailing lists have disappeared from the mod_mbox site listing at
http://mail-archives.apache.org/mod_mbox/
For a while both the incubator lists and the new top level lists were
The Qpid mailing lists have disappeared from the mod_mbox site listing at
http://mail-archives.apache.org/mod_mbox/
For a while both the incubator lists and the new top level lists were
present on the page, but now neither set are present, although the current
archives are still working ok if you
Carl Trieloff wrote:
Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff
wrote:
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 c
Aidan Skinner wrote:
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff wrote:
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 client for .NET and ot
On Wed, Jan 28, 2009 at 8:01 PM, Robert Greig wrote:
> 2009/1/23 Aidan Skinner :
>
>> Traditionally, the approach to writing the .Net client has been to
>> transliterate the Java client by hand and slap a random API on top of
>> that. That seems like a bit of a waste of effort to me. I was thinki
On Mon, Feb 2, 2009 at 2:00 PM, Carl Trieloff wrote:
>> Only supporting 0-10 means it won't talk to the current Java broker or
>> any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
>>
>
> Does that really matter, we already have an 0-8 client for .NET and others
> exist. We need t
Hi,
I've been writing up a proposed implementation for adding IP
Whitelisting to the Java broker on the wiki at
http://qpid.apache.org/ip-whitelisting.html
Feedback gratefully received.
- Aidan (also, possibly a snowmobile if this weather keeps up)
--
Apache Qpid - World Domination through Adva
Only supporting 0-10 means it won't talk to the current Java broker or
any of the other AMQP implementations such as OpenAMQ or RabbitMQ.
Does that really matter, we already have an 0-8 client for .NET and
others exist. We need to look
forward. I would say the target is Windows where dll's
ASL & EPL are cleared for use as dependencies in Apache.
We also need to deal with the package & all the dependencies.
Carl.
Andrea Gazzarini wrote:
Hi All, I'm going to submit the first version of QMan Admin console.Before
explaining what it is and how it's working I need help about licensi
Aidan Skinner wrote:
On Sun, Feb 1, 2009 at 2:06 AM, Carl Trieloff wrote:
let's make them... hand them out at apachecon
I have seen many other projects do it, from what I remember you just
need to notify them
Carl.
On Fri, Jan 30, 2009 at 6:11 AM, David Ingham
wrote:
> Carl's right, we have been investigating the idea of layering a WCF channel
> implementation on top of the C++ client library. That is, the managed code
> channel implementation would pinvoke down to the native C++ code. This is the
> appr
It's in java/resources and contains all the applicable licenses.
M
On Mon, Feb 2, 2009 at 9:40 AM, Andrea Gazzarini wrote:
> Hi Marnie, thanks for reply. Just two questions :
>
> "add details of each additional license to the license file in svn (they're
> separated by language)
> We used to sto
On Sun, Feb 1, 2009 at 2:06 AM, Carl Trieloff wrote:
>
> let's make them... hand them out at apachecon
I think we might need to run this by prc@ before we do this. Also, I
think it would be better to decide on a logo and slogan first, before
creating merch. Cafepress and friends can get stuff in
Sorry there was only "one" question...
Andrea
2009/2/2 Andrea Gazzarini
> Hi Marnie, thanks for reply. Just two questions :
>
> "add details of each additional license to the license file in svn (they're
> separated by language)
> We used to store a license file alongside the jars but it looks
Hi Marnie, thanks for reply. Just two questions :
"add details of each additional license to the license file in svn (they're
separated by language)
We used to store a license file alongside the jars but it looks like we
abandoned than in favour of one big license file (correct me here if I'm
wron
All sounds good - aside from automatic posting (hold your fire!!).
If you are anything like us, you wouldn't do that lightly. We run lots of
builds and get quite a few failures which need eyeballed so to speak before
list posting. I doubt you'd all want to be recipients of all of our
infiltered st
Hi Andrea,
If we distribute (or store in our repo) any licensed artifact, then we
(sadly) have to take on the responsibility of dealing with it. Most likely
the licenses are ok to use (since Jetty is also Apace licensed) but you'll
have to check each one and include it as appropriate for Qpid. Bas
41 matches
Mail list logo
