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