13:02:01 <pitti> #startmeeting Cockpit weekly meeting
13:02:01 <zodbot> Meeting started Mon Jun 12 13:02:01 2017 UTC.  The chair is pitti. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:01 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting'
13:02:16 <andreasn> (#topic agenda)
13:02:20 <pitti> #topic Agenda
13:02:35 <pitti> - package name for "Software Updates"
13:02:44 <dperpeet> .hello dperpeet
13:02:45 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:02:49 <pitti> oh, that part, sorry
13:02:50 <andreasn> .hello andreasn
13:02:51 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:02:52 <pitti> .hello martinpitt
13:02:53 <garrett> .hello garrett
13:02:53 <zodbot> pitti: martinpitt 'Martin Pitt' <martin@piware.de>
13:02:57 <zodbot> garrett: garrett 'Garrett LeSage' <garrett@lesage.us>
13:03:41 <pitti> any other topic?
13:03:59 <andreasn> * usability testing of software update
13:04:02 <andreasn> s
13:04:44 <pitti> #topic package name for "Software Updates"
13:04:52 <pitti> this is the last blocker for https://github.com/cockpit-project/cockpit/pull/6724
13:05:10 <pitti> right now, this is being called pkg/pkgupdates, and the rpm/deb is cockpit-pkgupdates
13:05:32 <pitti> but stefw voiced some concern that we usually name our cockpit modules after technology, not functionality
13:05:55 <andreasn> so pkg/packagekit?
13:05:57 <pitti> there was a proposal to call it packagekit / cockpit-packagekit, but that really doesn't work for multiple reaons
13:06:08 <petervo> packagekitd?
13:06:25 <petervo> isn't that what the daemon is called?
13:06:34 <pitti> first, this is soon going to use other backends (for configuring dnf-automatic/unattended-upgardes), and we will also call PackageKit from other modules (like mvo's  app install)
13:06:37 <pitti> so it would be rather confusing
13:06:45 <andreasn> yeah
13:07:03 <pitti> it's not a web UI for package kit, but for configuring and issuing OS package updates, similarly to ostree
13:07:17 <pitti> I think the latter should have been named ostree-updates (as e. g. app install will also work on/use ostree)
13:07:39 <pitti> so maybe a compromise would be cockpit-packagekit-updates or cockpit-pk-updates for brevity
13:07:48 <petervo> pitti, is the plan for the same package to do both dnf and packagekit?
13:07:54 <dperpeet> "pk-updates" sounds bad
13:07:56 <pitti> but "name by underlying technology" really doesn't work well here
13:08:25 <pitti> petervo: PK doesn't expose automatic updates, or (proper) "needs reboot" detection etc., so this is going to get dnf/yum/apt specific knowledge, yes
13:08:54 <pitti> we might ignore these corner cases and still call it "packagekit based OS updates" (plus a bit of cheating), but it would still be weird
13:09:08 <pitti> e. g. pkg/systemd/ is really not the only module that talks to systemd
13:09:46 <petervo> couldn't we do those as a seperate package that gets pulled in by this
13:09:47 <pitti> so, I'm open to suggestions, but cockpit-packagekit feels really wrong
13:10:14 <pitti> petervo: you want to put the "Install apps" functionality into the same package?
13:10:25 <pitti> it's completely different functionality and UI
13:10:28 <petervo> no
13:10:40 <pitti> and for the same reason we wouldn't put app installation into ostree (even though it also works *on* ostree)
13:10:55 <petervo> i want the 'updates' package to be used by the app install package to pull in what it needs
13:11:31 <petervo> same for the scheduling of updates
13:12:03 <petervo> although it's a little vague to me what that does
13:12:16 <pitti> hm, I don't understand - what would the app install page use from the updates page? except for maybe a ten line convenience function to create a PK transaction
13:12:44 <petervo> i guess i'm thinking of this similar to how the systemd package is used around in a bunch of places
13:12:53 <pitti> and how would a separate pkg/automatic-updates appear on the same HTML page than updates?
13:13:21 <pitti> petervo: ah, do you have an example of that?
13:13:54 <dperpeet> wouldn't our standard approach be to pull stuff out as needed if we need to use it in more than one place
13:13:56 <dperpeet> ?
13:14:22 <petervo> well the point of doing this would be not all systems have packagekit
13:14:24 <pitti> sure, we could put that ten-liner into a shared .js library thing if we wanted to
13:14:40 <pitti> but outside of that there's really not much commonality UI and code wise
13:14:40 <petervo> so apps would pull the 'updates' package
13:14:57 <petervo> and on atomic that would be different than on a packagekit system
13:15:06 <dperpeet> that makes sense
13:15:10 <pitti> oh, you mean "pull" in terms of package dependencies, not code/UI
13:15:27 <dperpeet> i.e. cockpit-updates, cockpit-packagekit?
13:15:52 <petervo> but i'm probably getting ahead of myself here
13:16:06 <petervo> as we really don't have any of these other pieces implemented
13:16:15 <pitti> in this case, the atomic equivalent of pkgupdates is our existing cockpit-ostree
13:16:30 <petervo> not from the pov of what apps will need
13:17:00 <pitti> right; but I don't understand why cockpit-apps would depend on cockpit-pkgupdates
13:17:15 <pitti> (or cockpit-packagekit if we would name it that way)
13:18:35 <petervo> i think we are talking past each other here,
13:18:46 <petervo> for the specific issue at hand
13:18:54 <petervo> i would vote for cockpit-packagekit
13:19:04 <petervo> but i don't have strong feelings either way
13:19:31 <petervo> if in the future we find a better way to share
13:19:33 <pitti> petervo: and that would initially ship the "software updates" page, and maybe in the future also the "app install" page?
13:19:38 <petervo> we can always change it
13:20:08 <petervo> as long as we use the alias updates i think pretty much any name is safe
13:20:45 <pitti> and woudl that only go for the pacakge name, or for the module name too? right now it's pkg/pkgupdates
13:20:56 <pitti> pkg/policykit would feel *really* wrong
13:21:02 <pitti> err, pkg/packagekit of course
13:21:05 <petervo> i think the module name at least for now should match the package name
13:21:49 <pitti> note that it's manifest has "name": "updates" to be an "alternative" to ostree
13:22:12 <petervo> right that's the alias that they both should share
13:23:17 <pitti> so how would we wrap up the app discover/install bits in that schema?
13:23:31 <pitti> it uses packagekit, docker, and ostree as technologies
13:23:42 <petervo> we aren't naming that package right now
13:23:54 <petervo> or do we need to decide on that too right now?
13:24:17 <pitti> well, I'm mostly interested in how this schema makes more sense than naming it by functionality
13:24:26 <petervo> or can we postpone that until there is an implementation there
13:25:19 <pitti> ok (I thought you had some schema in your head why it should be packaged that way, to better fit in future things)
13:25:22 <petervo> i do
13:25:30 <petervo> but i'm not the one building it
13:25:41 <petervo> so i don't want to presume to know what the best way to do it is
13:25:48 <pitti> ok, so s/pkgupdates/packagekit/ for now?
13:25:58 <petervo> i wish marius was around to get his thoughts
13:26:11 <pitti> for the package name and pkg/ dir
13:26:24 <pitti> this can wait until tomorrow, I'll try to catch him in the morning
13:26:28 <petervo> since that would probably carry more weight in terms of how he's thinking about it
13:26:41 <pitti> or we discuss on Wed
13:27:00 <dperpeet> postponing to get Marius' input sounds good
13:27:03 <petervo> but yes my vote would be packagekit for both rpm package name and pkg/dir
13:27:10 <pitti> ok, thanks!
13:27:15 <dperpeet> for what it's worth, I prefer packagekit over pkgupdates
13:27:30 <pitti> ack
13:27:36 <pitti> #topic usability testing of software update
13:27:45 * pitti hands mic to andreasn
13:28:12 <andreasn> so I've discussed this with pitti and garrett already, but I thought it's worth mentioning here too
13:28:35 <andreasn> I'm planning on doing usability testing on the Software Updates, hopefully next week at the latest
13:28:41 <andreasn> here is the planning document https://docs.google.com/document/d/1Vcs1f02b-j_H01ebtM0AqD0Js1e_zpD9gvGIYXzGslg/edit
13:29:02 <andreasn> I'm planning on doing it as a Bluejeans call with screen sharing, so anyone who wants can participate
13:29:29 <andreasn> if anyone has anything that they feel needs to be tested, feel free to add it to the document
13:29:43 <andreasn> oh, wait, that's the wrong document, sorry
13:30:11 <andreasn> #link https://docs.google.com/document/d/1nBNxKgOAqhuGK8hm68e1mASsLNdt1HxVWXlcrmcheos/edit
13:30:14 <pitti> /msg andreasn NOT the s3kr1t world domination plan!
13:30:15 <petervo> do you have people lined up to do the testing?
13:30:16 <andreasn> that's the one
13:30:33 <petervo> oh cool
13:30:35 <andreasn> I have at least 3 that I've talked to so far that has agreed to help
13:30:43 <andreasn> and I'll reach out to at least 3 more today
13:31:23 <andreasn> EOT
13:31:28 <pitti> thanks andreasn
13:31:30 <pitti> #topic AOB?
13:31:48 <pitti> going once..
13:31:53 <andreasn> AOB?
13:32:04 <pitti> "any other business", sorry
13:32:05 <dperpeet> all other business
13:32:10 <andreasn> hah
13:32:14 <dperpeet> pitti loves acronyms :)
13:32:14 <pitti> going twice..
13:32:32 <pitti> sold to the gentlemen on the Swedish leather throne!
13:32:33 <andreasn> good thing you started working at The Acronym Company then :)
13:32:45 <pitti> #endmeeting