Hello everyone.
This is definitely a great news for us. We will flesh out the details I
suppose. I'll try to clarify some of your points for the start. I guess I'm
guilty of many of the storaged odd decisions...
On Fri, 25 Nov 2016 15:32:22 +0100
Martin Pitt <martin.p...@ubuntu.com> wrote:
<...>
> * Personally I would prefer to leave development on GitHub, as it's
> much more powerful than fd.o in terms of CI and much more nicely
> integrated with issue reports.
One thing we miss at the moment is some good communication channel. Github
does not have mailing lists and since storaged is not a Freedesktop project
we didn't feel like discussing our stuff here. Perhaps this ML list would be
a good place to discuss the project's merge.
> * We can decide later whether we want to mass-close the fd.o bugs at
> some point and ask people to re-submit issues against github if
> their report is still current. ("bug bankrupcy" + migration to GH).
Some of them were actually already copied to storaged I think. But yes, doing
a triage and migrating the bugs would be more respectful to those who
bothered to file them.
> * 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'm not in charge of the CI infrastructure so Vratislav can eventually
correct me. It's currently being run on Red Hat's internal machines. And yes,
we need to fix the results publications so at least those would be visible
for the public.
The tests we actually run are these:
https://github.com/storaged-project/storaged/tree/master/src/tests/dbus-tests
> * At some point I should probably become a storaged project member,
> but there is no urgency -- everyone including project members
> should always use PRs anyway.
Yes. We have actually decided to let every non-trivial PR unmerged for some
time so people get chance to add their comments and reviews.
> What do you think about this in general?
> My instinct tells me that the hardest part of this will (as usually)
> be the naming: udisks or storaged. Quite a lot of upstream and
> third-party software builds/links against/calls the "udisks" API, and
> indeed storaged ships and provides just that, which is rather
> confusing. Even more curiously, Fedora builds a "libstoraged" package
> which ships libudisks.so.
This is a result of historical development: storaged was in the beginning
installed in parallel with udisks2 (and provided its own API) and only in
Fedora 25 we have decided to go back to udisks2 API to get rid of the code
duplication and make the maintenance easier. However since storaged was not
udisks, we didn't want to use the same package or even project name. There is
actually no visible change from the user's perspective. RPM's "Provides"
feature allows the updates or even installations to be totally transparent
for the user.
> So it seems that renaming "storaged" to "udisks" would be the simpler
> alternative as it would not require changes to external
> software/packages. If you prefer to keep "storaged", then I think it's
> better to rename the D-Bus API/library/ABI consistently and port the ~ 30
> users of it (at least that's how many we have in Debian) to the new
> names.
I don't know how it works in Debian: this is mostly non-issue on Fedora/RHEL
so I don't really care as long the result is usable and working from the
user's perspective.
> We mentioned this a while ago already in some private email exchange,
> but let's discuss it publicly on the ML now and actually reach a
> decision this time. :-)
Yes. Let's try to put together some step-by-step plan.
Thanks and regards,
--
Tomáš Smetana
_______________________________________________
devkit-devel mailing list
devkit-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/devkit-devel
