Re-unifying udisks and storaged

[Martin Pitt]

Hello Vratislav,

Vratislav Podzimek [2016-11-28 16:04 +0100]:
> >  * storaged PRs do run some tests, but unfortunately the result links
> >    don't work at all so I don't know what they actually test. I would
> >    hope that at least build + src/tests/integration-test? If not,
> >    that's something I would like to work on/set up. E. g.
> >    https://semaphoreci.com/ offers full QEMU (although only on Ubuntu
> >    14.04, but it should suffice) which is enough to run the scsi_debug
> >    tests. If that's already the case in the current tests, then ignore
> >    me of course.
> I'd like to apologize for this a bit.

Please don't apologize for having CI! :-) Things can always be
improved of course. I was mostly just wondering what actually runs
there.

That said, I'm a big believer in making such integration tests
reproducible and available to every developer, as otherwise they will
be hard to maintain and the onus of keeping them up to date will
always lie with the core developers instead of PRs and contributors.
But it seems this is already in progress:

> As Tomas has already mentioned, the CI is running on our internal
> Red Hat machines and it's not particularly easy to publish the
> results in some sane way. However, my plan for the next two weeks is
> to use Stef's sink [1] tool to make this work much  better.

Great to hear!

> As Tomas has already explained, this is not a problem in Fedora. And to be
> honest, I see storaged as a bit different project than udisks. Especially
> when thinking about the goals. The plan for storaged is not to just be a
> "hey, disk appeared, do you want to mount it?" kind of daemon. And please
> don't take me wrong here, I know udisks goes far beyond that even though
> I'm still getting familiar with some parts of its codebase. Anyway, storaged
> (esp. its extra modules) focuses on storage configuration management. As I
> tried to explain in my blog post [2] I see storaged as a next evolution step
> of udisks2. And changing the name to "storage daemon" makes perfect sense to
> me under that light.

Yes, understood. Due to its modules it will continue to remain
possible to not ship the "enterprise-y" features in a desktop install
to avoid extra dependencies; do you plan on keeping this?

So, as I said I'm not fundamentally opposing the "storaged" name, and
æsthetically it's quite nice too. I'm just saying that we shouldn't
keep a project name "storaged" and not ship a single "storaged"
binary/CLI/D-Bus name in it, as that's rather confusing. In other
words, if we go with "storaged" it should be done consistently.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)