13:02:45 <andreasn1> #startmeeting Cockpit weekly meeting
13:02:45 <zodbot> Meeting started Mon Sep  5 13:02:45 2016 UTC.  The chair is andreasn1. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:45 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting'
13:02:50 <andreasn1> .hello andreasn
13:02:51 <zodbot> andreasn1: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:03:01 <dperpeet> .hello dperpeet
13:03:02 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:04:25 <andreasn1> #topic agenda
13:04:42 <stefw> * Version numbers
13:04:45 <andreasn1> * ovirt dashboard
13:05:14 <andreasn1> * firmware updates
13:05:21 <harish_> * timers
13:06:11 <andreasn1> ok, lets start
13:06:14 <andreasn1> #topic version numbers
13:06:27 <stefw> so there's been some discussion about the version numbers in cockpit here:
13:06:28 <stefw> https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org/thread/UTSBRX6XQ2GJY4EHNY7DFOVE5OBITICN/
13:06:41 <stefw> the plan was to drop the '0.' from the version number
13:07:02 <stefw> and we got some objections with people suggesting a 1.0 release (somehow)
13:07:15 <stefw> since we release every week (although not the last couple weeks)
13:07:32 <stefw> the basic concept of 1.x and 2.x seems rather incompatible with what we're trying to do
13:07:58 <stefw> never the less, describing what we're trying to do (things like long term stability) does bring to mind a few more areas that may need to be finished
13:08:04 <andreasn1> any version number debate is like "Come and check out our new fancy bikeshed"
13:08:08 <dperpeet> one argument I understood was that many people have a concept of major version numbers indicating major changes
13:08:08 <stefw> such as packages requiring a certain version of cockpit
13:08:38 <larsu> andreasn1: right. The only reason I brought this up at all is because people think of 0.x as "not-there-yet"
13:08:41 <stefw> dperpeet, like in Fedora?
13:08:46 <stefw> ie: 23 vs 24 vs 25?
13:08:58 <dperpeet> I think the example listed was firefox
13:09:10 <dperpeet> when they switched to releasing often and using major version numbers
13:09:14 <stefw> firefox is at 48 right?
13:09:40 <dperpeet> somewhere around that, sure
13:09:46 <stefw> has anyone cared about 47 vs 48?
13:09:59 <andreasn1> mine says 48.0.1 :)
13:10:02 <dperpeet> I'm just bringing it up, because that is still a mindset
13:10:07 <stefw> as someone using and building stuff for firefox, i just expect the web to work
13:10:12 <stefw> firefox is actually a *great* example
13:10:22 <dperpeet> I agree with larsu that in any case, 0.x feels "alpha"
13:10:23 <stefw> there's many analogs with what we're trying to do
13:10:29 <andreasn1> it's good for Mozilla, because they can say "this new thing comes in the 49 release, that is currently in beta"
13:11:06 <dperpeet> I think it's a good example because people got used to the version numbers... and eventually you don't really need to check the actual number
13:11:23 <stefw> right for the users ...
13:11:25 <stefw> I'm using Firefox
13:11:27 <stefw> *not*
13:11:30 <stefw> I'm using Firefox 3.5
13:11:40 <stefw> and that's where we want to get for Cockpit
13:11:55 <dperpeet> whatever we do, I think we're ready to leave 0.x
13:12:03 <stefw> well a little less about "Cockpit" because we want to expose the functionality on the server ... but still
13:12:06 <dperpeet> or at least soonish, if we have good reasons to keep 0.x for a bit
13:12:28 <stefw> so if we did shore up the package dependency requirements (ie: require at least cockpit X before loading my package)
13:12:30 <andreasn1> is there any project with short release cycles (1-6 weeks) that does a 1.x 2.x kind of release numbering?
13:12:41 <stefw> so if we did shore that up ... can we drop 0.x?
13:13:46 <dperpeet> would it be more confusing to just go to 1.0 now
13:13:51 <stefw> indeed
13:13:56 <dperpeet> and then start increasing the major number?
13:14:00 <stefw> which is to say "yes"
13:14:00 <dperpeet> 2.0, 3.0, ...
13:14:11 <andreasn1> every week?
13:15:12 <dperpeet> basically we're saying that we only need one number, maybe two
13:15:16 <dperpeet> instead of two, maybe three
13:15:44 <larsu> we release every week, we don't need minor numbers
13:15:55 <dperpeet> well, for fixes
13:16:02 <larsu> distributions can use them for backports and stuff
13:16:08 <larsu> dperpeet: did we ever do that?
13:16:11 <dperpeet> yes
13:16:15 <dperpeet> -2
13:16:18 <dperpeet> et cetera
13:16:29 <larsu> was that a fix after the next version was already out?
13:16:48 <stefw> dperpeet, that's a revision
13:16:55 <stefw> but yes, people can add .y.z if they want
13:17:16 <dperpeet> well, do we bump our revisions to minor?
13:17:43 <stefw> revisions are a downstream thing
13:18:14 <dperpeet> e.g. we have 0.96-1
13:18:26 <dperpeet> would that be 120-1 in the future or 120.1
13:18:54 <larsu> isn't that a package version rather than an upstream one?
13:19:10 <larsu> in any case, my suggestion was: "drop the 0"
13:19:22 <larsu> everything else could just stay the way it is/was
13:19:55 <andreasn1> we could still make a little bang about it
13:19:59 <stefw> yup
13:19:59 <andreasn1> re josh concerns
13:20:28 <larsu> I agree
13:21:48 <andreasn1> how soon would we do this?
13:23:33 <stefw> as soon as we can add some prerequisite into the package manifests
13:23:39 <stefw> for the minimum version of cockpit they support?
13:23:43 <stefw> ^^ that would be my suggestion
13:23:58 <stefw> so the basic claim we are making is pretty bold
13:24:08 <stefw> "we want to never need another incompatible version number"
13:24:25 <stefw> just like a browser doesn't get to say ... okay from here on out I'm incompatible with that "old" web
13:24:44 <stefw> does that make sense?
13:24:54 <stefw> a browser essentially doesn't get to just say ok ... here's version 2.x
13:25:01 <stefw> for anything that worked with 1.x ... you're out of luck
13:25:03 <dperpeet> https://github.com/cockpit-project/cockpit/releases/tag/0.96-1
13:25:03 <dperpeet> in any case, I think that unless we drop the "0." prefix, people will hesitate to use cockpit
13:25:03 <dperpeet> that's the major reason for me
13:25:03 <dperpeet> whether we switch to 1.x or just x I don't care much
13:25:03 <dperpeet> and we still have a couple of years of weekly releases until the numbers become too large for comfort
13:25:08 <dperpeet> if for some reason the project does decide to have a major break of some kind, it can't be apparent from the version numbers alone
13:25:08 <dperpeet> but we don't track any other versions anyway, to my knowledge
13:25:08 <dperpeet> so, what's keeping us from just dropping 0.?
13:25:18 <stefw> major lag ... from dperpeet
13:25:21 <stefw> we saw that all in one big chunk
13:25:24 <stefw> at least i did
13:25:44 <dperpeet> aha, I'm not the only one talking -.-.
13:26:56 <dperpeet> I like the browser comparison
13:27:38 <andreasn1> do we have a general agreement then?
13:28:19 <stefw> well there's two things:
13:28:26 <stefw> 1. Whether we agree to just drop the 0.x
13:28:36 <stefw> 2. What are the things that need to happen before we do that
13:29:31 <stefw> do we have general agreement on 1.?
13:30:24 <andreasn1> the product generally work
13:30:34 <andreasn1> so no concerns from me on dropping the 0
13:30:47 <dperpeet> I agree
13:30:53 <dperpeet> (with dropping 0.)
13:31:00 <stefw> did mvollmer have concerns here?
13:31:45 <dperpeet> not that I remember
13:32:05 <stefw> anyone else have concerns with 1?
13:32:07 <stefw> sgallagh, perhaps?
13:32:23 <stefw> although sgallagh may want to read the backlog
13:32:30 <dperpeet> stephen might be offline today
13:32:32 <stefw> ah true
13:32:51 <stefw> okay, lets talk about (2)
13:32:54 <larsu> stefw: maybe we should announce it again on the list?
13:32:58 <stefw> yup for sure
13:33:04 <dperpeet> should it be up for vote?
13:33:06 <stefw> i'll work on packages requiring X version of bridge/base1
13:33:10 <stefw> dperpeet, i don't think so
13:33:14 <dperpeet> I think announcing a majority is good enough
13:33:34 <dperpeet> and wait for good reasons not to go forward
13:33:35 <stefw> the people who have contributed here
13:33:35 <stefw> https://github.com/cockpit-project/cockpit/graphs/contributors
13:33:36 <larsu> I agree, let's not turn this into a huge discussion
13:33:52 <stefw> over the last year
13:34:00 <stefw> really are the ones who get to decide
13:34:32 <stefw> top 10 or so
13:34:45 <andreasn1> sounds sane
13:35:09 * larsu will ask cockpituous over a beer tonight
13:35:15 <stefw> nice
13:35:33 <andreasn1> all right. Next topic?
13:35:35 * dperpeet begs larsu not to get cockpituous drunk
13:35:42 <dperpeet> do we postpone 2?
13:35:43 <larsu> haha :D
13:35:46 <dperpeet> until 1 is decided?
13:36:12 <dperpeet> I feel we're ready to drop 0. as soon as we can make packaging work and downstream has some warning
13:36:24 <stefw> well i'll start working on (2)
13:36:31 <dperpeet> preparing some blogs is a must
13:36:34 <stefw> i just hope that everyone understands the boldness of the undertaking here.
13:36:39 <stefw> and think about it a bit
13:36:42 <stefw> and see if there's something missing
13:37:01 <stefw> just writing the emails on the mailing list helped me think about the package version requirements
13:37:10 <stefw> so if anything else comes to mind there, it's a good time for it
13:37:21 <stefw> translations?
13:37:27 <stefw> probably not ^^
13:37:40 <stefw> anyway, enough on that topic?
13:37:44 <dperpeet> yeah, I think so
13:37:53 <dperpeet> translations wouldn't be an issue (I hope)
13:37:53 <andreasn1> all right
13:38:54 <andreasn1> ok, next up
13:39:01 <andreasn1> #topic ovirt dashboard
13:39:31 <andreasn1> so I wanted to bring this up, since I wanted to check to what extent a plugin can hook in to the main dashboard
13:39:46 <andreasn1> like, is it possible for it to display it's own panels?
13:40:04 <andreasn1> right now the ovirt host is it's own dashboard, but works kind of wonky
13:40:16 <andreasn1> so I wanted to try and see if it was possible to merge them
13:40:47 <stefw> shouldn't they be able to replace the main dashboard?
13:41:05 <andreasn1> they should, but there is also a lot that they need from the main dashboard
13:41:15 <andreasn1> like tuned and stuff
13:41:15 <dperpeet> does this go towards customizable dashboards?
13:41:27 <andreasn1> but maybe it would be possible to just replicate that
13:42:24 <andreasn1> but yeah, maybe a replacing the dashboard might be the best approach
13:42:31 <dperpeet> if components need to be reused, we can refactor some code
13:42:32 <stefw> andreasn1, tuned is trivial to bring into another dashboard
13:42:36 <stefw> it's already modularized
13:42:41 <andreasn1> right
13:42:44 <andreasn1> ok, cool
13:42:45 <stefw> it just looks for a specific html id="xxx" on the given page
13:42:46 <stefw> if you load it
13:42:50 <stefw> just load the javascript and it's all good
13:42:58 <andreasn1> I'll keep exploring that route then
13:43:15 <andreasn1> just wanted to check I wasn't attempting something really hard
13:43:29 <stefw> making it super customizable is really hard
13:43:35 <stefw> and something we've tried to avoid
13:43:47 <andreasn1> I have mockups on paper, will get those up digitally tomorrow
13:43:50 <stefw> but making certain parts be composable (such as tuned or realmd stuff) seems to work pretty well
13:44:05 <dperpeet> I agree
13:44:16 <dperpeet> making it too customizable also complicates the ui and testing
13:44:20 <andreasn1> yeah
13:44:37 <dperpeet> if you can add in a bunch of stuff, chances are the ui is too complex for what we want
13:45:18 <andreasn1> all right, that that's on that
13:45:23 <andreasn1> next topic?
13:45:34 <andreasn1> #topic Firmware updates
13:45:50 <andreasn1> so me and kalev started working on Firmware updates
13:46:14 <andreasn1> I created a wiki page https://github.com/cockpit-project/cockpit/wiki/Feature:-Firmware-updates
13:46:25 <andreasn1> and Kalev is getting started with trying things out
13:46:31 <andreasn1> will make mockups tomorrow or so
13:47:25 <andreasn1> take a look and add any concerns there
13:47:56 <dperpeet> nice
13:48:17 <dperpeet> would that be on its own page?
13:49:31 <andreasn1> I'm not sure yet
13:49:34 <andreasn1> but I think it might
13:49:41 <dperpeet> ok
13:49:51 <andreasn1> it's possible to combine it with package updates
13:50:03 <andreasn1> like how it's done in GNOME Software
13:50:29 <dperpeet> hooking a single line entry/status into the system page might be worth looking into making generic
13:50:33 <stefw> isn't it very different ?
13:50:44 <stefw> andreasn1, it's a property of the server itself, rather than the apps or the operating system
13:50:56 <stefw> i would be careful about thinking that because it's implemented using similar APIs that it's to be represented similarly
13:51:05 <stefw> wouldn't it be nearer to hardware info?
13:51:08 <stefw> ie: in the ui
13:51:12 <stefw> placed nearer to hardware info
13:51:22 <andreasn1> yeah, could be
13:51:41 <dperpeet> where BIOS info used to be
13:52:21 <andreasn1> I'll try a couple of different alternatives
13:52:43 <andreasn1> but yeah, something on the dashboard could work well
13:54:23 <andreasn1> I think firmware updates feels a bit more dangerous than software updates, so that could be a good reason for not mixing them up too much
13:54:30 <andreasn1> but maybe that's just me
13:55:47 <andreasn1> but lets discuss it more once there are some wireframes
13:55:50 <andreasn1> all right
13:55:58 <andreasn1> #topic open floor
13:56:11 <dperpeet> we had another topic
13:56:12 <dperpeet> timers
13:56:14 <dperpeet> from harish
13:56:16 <andreasn1> akc
13:56:18 <andreasn1> ack
13:56:20 <andreasn1> sorry
13:56:23 <andreasn1> #topic Timers
13:56:34 <harish_> ah thanks andreasn1
13:56:38 <harish_> Hi everyone,
13:56:41 <larsu> did Lennart implement the end-of-month stuff yet?
13:57:10 <harish_> I dont think so
13:57:16 <harish_> https://github.com/systemd/systemd/issues/3861
13:57:29 <harish_> There has been good discussions over it
13:57:32 <larsu> :/
13:57:58 <harish_> andreasn1 dperpeet we had plans for adding timers for existing services as well.
13:58:03 <harish_> Currently we could create timers for new services only.
13:58:13 <dperpeet> and edit timers, correct?
13:58:23 <andreasn1> and delete timers!
13:58:23 <harish_> yes
13:58:49 <harish_> I thought of completing adding timers for existing services next week
13:58:55 <dperpeet> that would be nice
13:58:59 <andreasn1> super nice!
13:59:02 <harish_> I have a week long holidays
13:59:12 <harish_> onam festivals :)
13:59:18 <harish_> I thought of doing this in 2 ways,
13:59:25 <andreasn1> is the design clear for that?
13:59:31 <harish_> 1. Create timer button will be having both options , ie. adding timers for existing services and create new timers with new services. This was what we had planned.
14:00:07 <harish_> 2. If https://github.com/systemd/systemd/issues/3234  work for setting persistent unit from D-BUS completes, then we could separate out and have create services and create timers separately. This is like the future plan
14:00:48 <dperpeet> I feel like the best option would be to have one dialog for creating a timer, where you either choose an existing service or not
14:01:03 <harish_> andreasn1 we thought of bootstrap combobox
14:01:30 <andreasn1> the one you either write in, or select from a dropdown?
14:01:33 <harish_> I dont have clear idea on how it should look. Could you make a mockup?
14:01:39 <andreasn1> yes, I'll get on that
14:01:45 <harish_> yes
14:02:32 <andreasn1> I'll try to get to it tomorrow
14:02:34 <harish_> dperpeet I thought of the same, if the DBUS for persistent units ( not timers) comes through then we could implement creation of services as well?
14:02:56 <harish_> thanks andreasn1
14:03:18 <dperpeet> harish_, that would be a separate discussion - while interesting, I think it's better to make the timers fully functional first
14:03:25 <dperpeet> but definitely something to keep in mind
14:03:49 <dperpeet> although to be fair, I don't think a service would often need to be manually created
14:04:42 <harish_> ohh..
14:04:53 <dperpeet> that definitely needs more research
14:05:14 <harish_> okay I thought admins usually need to create services, like create scripts and set time for it et cetera
14:05:20 <harish_> ah yes
14:05:47 <dperpeet> harish_, if you have user stories like that, you can always start a wiki page!
14:05:54 <dperpeet> it's good to have those :)
14:06:25 <harish_> Thanks
14:06:27 <dperpeet> and it's great to see timers+services moving forward
14:06:48 <harish_> thanks everyone and my mentors, in Cockpit community for guiding me into open source working
14:06:50 <andreasn1> https://github.com/cockpit-project/cockpit/wiki/Feature:-Systemd-timers
14:06:54 <harish_> and also helping me out in completing the GSoC project.
14:07:16 <harish_> https://medium.com/@harishanand95/gsoc-2016-final-submission-1fb33bbfeb50#.aucqqkmi8
14:08:04 <dperpeet> harish_, and thanks to you for contributing! it was great to see the work merged
14:08:20 <andreasn1> yeah, very solid stuff!
14:08:46 <harish_> thanks everyone :D
14:09:22 <harish_> end of topic?
14:09:25 <andreasn1> sure
14:09:37 <andreasn1> we're 10 minutes over
14:09:43 <andreasn1> so ok to do endmeeting?
14:09:51 <dperpeet> yes, I think so
14:09:52 <andreasn1> unless someone had anything for the open floor
14:10:18 <andreasn1> #endmeeting