Created attachment 195972 [details] net/ceph13 shar net/ceph13 is the next released Ceph version. Still also maintaining net/Ceph, since that is v12.2.7
You may want to consider copying net/ceph to net/ceph12, and upgrading net/ceph through to 13.* if there is an upgrade path there. It's fairly standard for the 'main' port to always be the latest release branch. Alternatively, if dual major branches will be supported going forward, one may consider moving net/ceph -> net/ceph12, and create a new net/ceph13. Which is the better option depends on a few things, such as dependency complexity, upgrade-ability experience/process through major versions. Can you also confirm that this port passes QA please (portlint, poudriere at a minimum)
(In reply to Kubilay Kocak from comment #1) To start with the last one: Yes, it has passed both poudriere and portlint. Portlint complains that the patch format could be more to its liking, but it is the git diff format that is used in the project. About naming... Both version will be supported as long as they are on the release map of Ceph. Ceph usually has 2 stable versions out, and a HEAD version. At the moment I will track atleast the 2 stable versions. I would prefer not continuously keep renameing net/ceph -> net/ceph<version> new release -> net/ceph everytime a new majore release is done. So I would then move net/ceph to net/ceph12. But I have no clou as to how that is done... Maybe you can advise?
(In reply to Willem Jan Withagen from comment #2) It's less 'continuously renaming', and more 'cut new fooX port from the main port every major version'. Users can then decide to switch the origin of the package/port if they don't want to go through the major version, and update/switch back again at a later date if they want. But the choice is yours, and there's no *major* issue with fooX/fooY with no 'foo', except users may expect there to be a 'foo' (without a suffix). As for how to move/rename, if you decide to go that path... That can take the form of a separate issue (reference this one in See Also field) with title: net/ceph: Move to ceph12 If you'd like to create the patch for that, the svn diff would be the output after: svn mv net/ceph net/ceph12 edit net/Makefile entry (update net/ceph to net/ceph12) edit MOVED file (add MOVED entry) Alternatively the committer assigning themselves can take of it, just provide a reason for the move, such as: "Multiple supported major branches" Hope that helps, don't hesitate to ask if anything needs clarifying
(In reply to Kubilay Kocak from comment #3) So how do I find a commiter that wants to commit this version 13? After which I submit another paatch to move net/ceph to net/ceph12.
(In reply to Willem Jan Withagen from comment #4) There's nothing special to do or that can be done, short of poking people you might already have relationships with. One more question though (to assist the future assignee with clarity): Is/was this port based on the existing net/ceph port with updates? Said another way, is/was the process to svn cp net/ceph net/ceph13 && make changes from there? That is the preferable (fairly well 'enforced') method, where the origin of the port was an existing one.
(In reply to Kubilay Kocak from comment #5) Hi Kubilay, Yes, the net/ceph13 port is a direct copy from the net/ceph12 port. With some small changes in chksum, required dependancies, different pkg-plist, and what not. But in essence are they equal.
Created attachment 196247 [details] Share file for Ceph13 initial port Needed to fix an error in the rc.d/ceph script. It was using too many parameters.
Testbuilds@work
A commit references this bug: Author: pi Date: Tue Feb 5 18:01:38 UTC 2019 New revision: 492262 URL: https://svnweb.freebsd.org/changeset/ports/492262 Log: New port: net/ceph13: Ceph delivers object, block, and file storage Ceph is a distributed object store and file system designed to provide excellent performance, reliability and scalability. * Object Storage Ceph provides seamless access to objects using native language bindings or radosgw, a REST interface for applications written with S3 and Swift. * Block Storage Ceph's RADOS Block Device (RBD) provides access to block device images that are striped and replicated across the entire storage cluster. * File System Ceph provides a POSIX-compliant network file system aiming for large data storage, high performance, and maximum compatibility with legacy applications. This FreeBSD build will build most of the tools in Ceph: * Mon, OSD, rados, RadosGW, rbd * init-ceph, and etc/rc.d/ceph on top of that * ceph-disk {prepare, activate} With these tools one can build a multi server, multi osd cluster fully running on FreeBSD and do some testing... WWW: https://ceph.com/ PR: 230432 Submitted by: Willem Jan Withagen <wjw@digiware.nl> Changes: head/net/Makefile head/net/ceph13/ head/net/ceph13/Makefile head/net/ceph13/distinfo head/net/ceph13/files/file-git_version head/net/ceph13/files/patch-boost-1.67 head/net/ceph13/files/patch-src_test_CmakeLists.txt head/net/ceph13/files/patch-src_test_librbd_test_mock_Journal.cc head/net/ceph13/files/patch-src_tools_ceph__kvstore__tool.cc head/net/ceph13/files/patch-srr_tools_rbd_gate_debug.cc head/net/ceph13/pkg-plist
A commit references this bug: Author: pi Date: Tue Feb 5 18:16:15 UTC 2019 New revision: 492265 URL: https://svnweb.freebsd.org/changeset/ports/492265 Log: net/ceph13: Make PKGNAME unique PR: 230432 Pointy hat to: pi Changes: head/net/ceph13/Makefile
Committed, thanks -- and sorry for the delay!