On Mon, 2016-11-28 at 22:17 +0100, Martin Pitt wrote: > 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? Sure, we want to keep it modular as much as possible. There are definitely environments that we want to support/cover which don't need any of these extra features.
> > 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. Absolutely agreed and I think that should be our (long-term) goal. Thanks! -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/devkit-devel
