2 years back I proposed dropping the sheepdog mailing list from the
MAINTAINERS file, but somehow the patch never got picked up:

  https://lists.gnu.org/archive/html/qemu-block/2018-03/msg01048.html

So here I am with the same patch again.

I further looked at the sheepdog project though, and I'm wondering
if we actually want to keep the sheepdog storage driver at all.

This thread from a little over a year ago:

  http://lists.wpkg.org/pipermail/sheepdog/2019-March/thread.html

clearly states that sheepdog is no longer actively developed. The only
mentioned users are some companies who are said to have it for legacy
reasons with plans to replace it by Ceph. There is talk about cutting
out existing features to turn it into a simple demo of how to write a
distributed block service. There is no evidence of anyone working on
that idea.

  https://github.com/sheepdog/sheepdog/commits/master

No real commits to git since Jan 2018 and that's just dealing with
technical debt.

There is essentially no activity on the mailing list aside from
patches to QEMU that get CC'd due to our MAINTAINERS entry, if and
when someone processes the moderator queue.

Fedora packages for sheepdog failed to build from upstream source
because of the more strict linker that no longer merges duplicate
global symbols. So we patch it to add the missing "extern" annotations.
Upstream source remains broken for everyone else.

AFAIK, none of our containers or VMs include the sheepdog server
packages, so we have no testing coverage for it in CI that I see.

Does someone have a compelling reason for QEMU to keep supporting
this driver, other than the fact that it already exists ?

If not, it looks like a candidate for deprecating in QEMU with a
view to later removing it.

Daniel P. Berrangé (1):
  block: drop moderated sheepdog mailing list from MAINTAINERS file

 MAINTAINERS | 1 -
 1 file changed, 1 deletion(-)

-- 
2.26.2

On 22/09/2020 11.01, Daniel P. Berrangé wrote:
[...]
> Does someone have a compelling reason for QEMU to keep supporting
> this driver, other than the fact that it already exists ?
> 
> If not, it looks like a candidate for deprecating in QEMU with a
> view to later removing it.

I think you gave enough examples why this is a good candidate for
deprecation. So I'd say: Simply send a patch to deprecate it. That's
what's our deprecation process is good for. If someone still cares for
sheepdog, they then can speak up and we can revert the patch that put it
on the deprecation list.

 Thomas

Thomas Huth <thuth@redhat.com> writes:

> On 22/09/2020 11.01, Daniel P. Berrangé wrote:
> [...]
>> Does someone have a compelling reason for QEMU to keep supporting
>> this driver, other than the fact that it already exists ?
>> 
>> If not, it looks like a candidate for deprecating in QEMU with a
>> view to later removing it.
>
> I think you gave enough examples why this is a good candidate for
> deprecation. So I'd say: Simply send a patch to deprecate it. That's
> what's our deprecation process is good for. If someone still cares for
> sheepdog, they then can speak up and we can revert the patch that put it
> on the deprecation list.

Concur.