[Service Bus Client] ReadMe Content Updates (for archive)

[jsquire]

Summary

Updated copy to reflect the new location for the Service Bus client library and status of this repository as transitioning to a historical archive.

The contents have been massaged to more closely match the format and voice used for the Service Bus client ReadMe in the central repository, in order to ease the cognitive burden for those navigating over. An attempt was also made to keep the original introductory content and context.

Known Issues

• The link for the Event Hubs library is not yet valid, as the initial migration to the central repository is in-process. (see: pull request)

Goals

• Update the ReadMe for the stand-alone Service Bus client repository to reflect the migration to the Azure Developer Platform central repository.

• Provide context for visitors of the repository to understand what the Service Bus client library is, where to find its active development, and to understand the new purpose of the stand-alone repository.

Non-Goals

• Archive the stand-alone repository; this will occur as a separate work stream.

Last Upstream Rebase

Tuesday, April 23, 2019 4:40pm (EDT)

Related and Follow-Up Issues

• [Service Bus] Update ReadMe in Standalone Repository (#5717)
• Update Repo Structure for ServiceBus (#5857)
• [Service Bus Client] Migrate Recent Updates ( #5915)
• [Service Bus] .NET Client Library Adoption (#5329)

[SeanFeldman]

@jsquire the new repo referenced in PR is not public.

[SeanFeldman]

The source code seems to be located at https://github.com/Azure/azure-sdk-for-net/tree/master/src/SDKs/ServiceBus/data-plane

[jsquire]

@jsquire the new repo referenced in PR is not public.

The referenced repo is the new Azure SDK repository, which is public. What gives you the impression that it isn't public?

If you're keying on the 404 that returns for the full url. as noted in the Known Issues above, the directory that it is currently pointing to will not exist until the outstanding pull request to restructure closes. Barring something unforseen, that is expected to be merged at some point this week.

[jsquire]

The source code seems to be located at https://github.com/Azure/azure-sdk-for-net/tree/master/src/SDKs/ServiceBus/data-plane

That is correct, pending the restructure covered by the pull request noted in the Known Issues. There was a new repository format recently adopted which is being applied in stages.

[SeanFeldman]

Thank you @jsquire. Not entirely familiar with the process the other repo has and knowing that there's a pending PR Azure/azure-sdk-for-net#5857 as a prerequisit for this one is good.
Which means this PR should be hod off or considered a "WIP" until the aforementioned PR is merged, right?

[jsquire]

Thank you @jsquire. Not entirely familiar with the process the other repo has and knowing that there's a pending PR Azure/azure-sdk-for-net#5857 as a prerequisit for this one is good.
Which means this PR should be hod off or considered a "WIP" until the aforementioned PR is merged, right?

My pleasure, and apologies for the confusion. Things are still in a bit of transition with several things moving at once. I'll leave it to your discretion if/when to merge this in. It's a trade-off between potentially having the repository get marked as archived, which the Service Bus team is intending to do shortly versus having links that don't yet work and are potentially confusing.

Were it up to me, given the rate of changes, I'd probably hold for that PR to close out, assuming that it does so by the end of the week - but that's just my opinion.

[nemakam]

(https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/servicebus/Microsoft.Azure.ServiceBus) [](start = 13, length = 98)

Could you make sure whereever this points to, there should be a readme file with the details of running the tests / contributing etc

[jsquire]

There's a full ReadMe that combined content from the initial migration with the standards in place for the central repository.

(Note: This location differs from the url in the changes for this PR due to an outstanding pull request in the central repository; once that is merged, the link in this comment will cease working and the link in the ReadMe changes will be the permanent home.)

[SeanFeldman]

Were it up to me, given the rate of changes, I'd probably hold for that PR to close out, assuming that it does so by the end of the week - but that's just my opinion.

@jsquire @nemakam how about marking this PR as a WIP and remove WIP once merge can take place (i.e. destination repo is ready, prerequisite PR is merged)? @jsquire you probably can remove WIP as you'll know when that work is completed. Just a suggestion.

[jsquire]

The pull request for restructuring the Service Bus area of the central repository closed last night. I confirmed this morning that things are in a good state, with tests passing and the links referred to in this update are working.

[SeanFeldman]

I've twitted to start spreading the word in the community that is so used to raise issues/PRs in the "old" repo. Would be nice if you could amplify that.

Also, two questions (sorry for tagging those here)

1. What should be done in regards to the existing issues and PRs that are either scheduled for the next major or demonstrate found bugs (Allow clients to report if they own or share the underlying connection string (Part 2) #486, [WIP] verification test for MessageSender abstraction is broken for Path when Send-Via is used #570)?
2. Should the issue tracker/PR features be disabled, instructing where and how to raise issues for Service Bus client specifically?

[jsquire]

1. With the migration complete, it is believe that the Service Bus client is now in a stable state in the new repository, and should be ready for any planned work, contributions, and issues. Please feel free to open issues and submit pull requests, as you would like.

   I'm going to defer to @nemakam, and the Service Bus team with respect to guidance on issues and pull requests already open. The last conversation that I was privy to, it was still under discussion whether they would be automatically migrated or would be requested to be recreated in the new location.

2. Yes, they should. The plan, as I understand it, is to flag this repository as archived, though I don't have a definitive timeline. From recent discussion, I believe that this is planned in the next few days though, again, I'll defer to @nemakam and the Service Bus team for a definitive answer.