On 03/04/17 14:53, Keith W wrote:
On 31 March 2017 at 10:57, Rob Godfrey <[email protected]> wrote:
On 30 March 2017 at 12:32, Lorenz Quack <[email protected]> wrote:
+1 on the migration to git.
Regarding the name of the broker's git repo:
* qpid-broker: I agree with others that this might lead to confusions
with the cpp broker.
* qpid-java-broker: I am worried that legal will not be happy with this
since Java is a trademark. See [1] and [2].
* This leaves qpid-broker-for-java and qpid-broker-j.
Between those two I favour qpid-broker-for-java since that is what was
decided in [1]. I agree that it is a bit wordy but we won't have to
type it a lot and it is consistent with the other usages like
documentation and representation on the web page.
So my view here is that "Qpid Broker for Java" is essentially the wrong
name in every context :-) The fact that the Broker is written in Java is
really incidental to its function and unless you are looking at deploying
on a platform that doesn't support Java, it really shouldn't make any
difference to an end user. personally I would have gone for qpidj-broker or
qpid-broker-j for the product name and the repo name.
I agree. I only wish we'd had the same thought a few months back when
the Qpid Broker for Java was named that way :)
I prefer qpid-broker-j. My suggestion is that we adopt it for both
the new git repo name and the name of the product appearing in notice,
license files, documentation, website and maven metadata descriptions
etc. The Maven artefact names will be left unchanged.
Fine. I just wanted consistency between all those places you mentioned.
I wanted to avoid the work of changing all of them but I also agree that
the Qpid Broker for Java is not a good name so I'm okay with qpid-broker-j
On the legal concerns, I don't see why the git repo name would be different
from a legal standpoint to the maven artefact names... if we believe that
the git repo name is an issue then we should also be changing the maven
names... and again I would think that "qpid-broker-for-java" would be a
stupid maven artefact name too :-)
-- Rob
Kind regards,
Lorenz
[1] https://issues.apache.org/jira/browse/QPID-7341
[2] http://qpid.2158936.n2.nabble.com/Apache-Qpid-Java-naming-co
ncerns-td7648059.html
On 30/03/17 11:12, Oleksandr Rudyy wrote:
+1 for migration from svn to git
I would use qpid-java-broker as a name for the repo, as it is a bit
shorter
than qpid-broker-for-java.
I'd also be Ok with 'qpid-broker-for-java' as a name for the repo. In
general I prefer full names over the abbreviations or truncations of the
words. Mixing abbreviation with full words looks a bit unusual to me.
Thus,
I would vote against 'qpid-broker-j'.
Kind Regards,
Alex
On 27 March 2017 at 14:15, Justin Ross <[email protected]> wrote:
I like qpid-broker-j best of the alternatives proposed. I think
qpid-broker alone will cause a little confusion.
On Mon, Mar 27, 2017 at 3:41 AM, Rob Godfrey <[email protected]>
wrote:
On 27 March 2017 at 12:35, Robbie Gemmell <[email protected]>
wrote:
On 27 March 2017 at 10:47, Rob Godfrey <[email protected]>
wrote:
On 27 March 2017 at 11:31, Keith W <[email protected]> wrote:
Hi all
Now the Qpid Broker for Java and Qpid JMS AMQP 0-x Client are
separated [1]/[2], I'd like to propose the final two remaining Qpid
components are migrated from SVN to GIT.
* Qpid Broker for Java
* Qpid JMS AMQP 0-x Client
This will give us a consistent, Git based, version control approach
across the whole project and therefore a simpler 'getting involved'
story that should benefit the community as a whole.
The source code migration will maintain source code history,
including
existing release branches and tags made since r1673693/QPID-6481 [3]
The intention would be for all future releases to be made from git.
This would include any future maintenance releases from 6.0.x and
6.1.x (which would remain combined broker/client releases).
Qpid Broker for Java:
Current SVN location: https://svn.apache.org/repos/asf/qpid/java/
Proposed GIT repo: git://git.apache.org/qpid-broker
<http://git.apache.org/qpid-broker-for-java.git>-for-java.git
<http://git.apache.org/qpid-broker-for-java.git>
Do we have to make the repo name quite so wordy? :-) git://
git.apache.org/qpid-broker.git would work for me.
The existing GIT mirror at git://git.apache.org/qpid-java.git would
cease.
Qpid JMS AMQP 0-x Client:
Current SVN location: https://svn.apache.org/repos/
asf/qpid/qpid-jms-amqp-0-x/
Proposed GIT repo: git://git.apache.org/qpid-jms-amqp-0-x.git
The existing GIT mirror at git://git.apache.org/qpid-jms-
amqp-0-x.git
would become the 'live' repo..
Thoughts?
No objections on the client side, and OK on the broker side with the
proviso that I'd prefer a shorter repo name :-)
-- Rob
[1] http://qpid.2158936.n2.nabble.com/DISCUSS-Drop-the-AMQP-0-x-
client-from-the-Qpid-for-Java-7-0-release-td7657770.html
[2] https://issues.apache.org/jira/browse/QPID-7622
[3] https://issues.apache.org/jira/browse/QPID-6481
I'm also not hugely fond of 'qpid-broker-for-java' as a repo name.
Using only 'qpid-broker' doesn't necessarily do a great job of
signalling which broker it contains, though the contents would make it
pretty obvious and seeing that the cpp broker is in 'qpid-cpp' isn't
much of a stretch or that surprising (particularly as its been there a
while now, and I doubt we will separate those bits further). Adding
'-j' might be another option though.
The above was literally my reasoning as I considered what name I would
give
it... I'd also be happy with qpid-broker-j however that's not what we
call
it in maven, etc (though I wouldn't be hugely upset to rename it
consistently).
Regardless which of these its called, happy to proceed and will be
glad to see them moved to git.
+1
-- Rob
Side note, git.apache.org doesn't actually hold the live repos, just
mirrors. The actual writable repos would be at
https://git-wip-us.apache.org/repos/asf/<name>.git
Robbie
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
