13:01:28 <mvollmer> #startmeeting 13:01:28 <zodbot> Meeting started Mon Jun 22 13:01:28 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:34 <mvollmer> #topic Agenda 13:01:37 <mvollmer> .hello mvo 13:01:38 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 13:01:46 <dperpeet> .hello dperpeet 13:01:47 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com> 13:02:03 <mvollmer> * Next steps with storage 13:02:19 <mvollmer> * API Compatibility 13:02:35 <dperpeet> * build status on landing page 13:03:01 <dperpeet> * github labels 13:04:58 <mvollmer> phatina, are you here? 13:05:24 <phatina> mvollmer: yes, I am 13:05:32 <phatina> .hello phatina 13:05:33 <zodbot> phatina: phatina 'Peter Hatina' <phatina@redhat.com> 13:05:38 <mvollmer> ok, great. 13:05:43 <mvollmer> let's start! 13:05:51 <mvollmer> #topic Next steps with storage 13:06:01 <andreasn> .hello andreasn 13:06:02 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com> 13:06:29 <andreasn> (sorry for being a bit late, lost track of time) 13:06:41 <mvollmer> so one option is to move main development to rawhide and take storaged from there. 13:07:05 <mvollmer> the other is to stay on f22 for now and take storaged from a copr 13:07:54 <mvollmer> rawhide is in a bad shape right now and wont bootstrap (but maybe that's our bug) 13:08:02 <petervo> the tests aren't all passing on rawhide right? 13:08:11 <mvollmer> correct 13:08:39 <mvollmer> so I would go with a copr for f22 for now. 13:08:42 <petervo> i think it's good to run storaged on from copr then 13:08:47 <mvollmer> like we did for f21. 13:08:52 <petervo> but we won't release anymore on f22 13:09:01 <petervo> once we merge 13:09:04 <mvollmer> right, storaged would also go to that copr, or to its own. 13:09:04 <phatina> I have no problems updating copr 13:09:24 <mvollmer> ok, nice 13:09:43 <mvollmer> so, we would like to ask you to keep storaged up-to-date in the f22 copr, then. 13:09:56 <mvollmer> up-to-date == same version as in rawhide. 13:10:29 <mvollmer> and we keep cockpit up-to-date in our f22 copr. 13:10:30 <phatina> sure, I will do so 13:10:34 <mvollmer> ok, thanks. 13:10:39 <dperpeet> sounds good, that would help defragment our development 13:10:46 <mvollmer> #info phatina keep f22 storaged copr up-to-date 13:11:05 <mvollmer> and we keep trying to make rawhide work for us. 13:11:10 <andreasn> so this means for any vm 13:11:23 <andreasn> 's running f22, it needs a copr enabled to work? 13:11:30 <andreasn> with master 13:11:33 <mvollmer> yes 13:11:37 <andreasn> all right 13:11:40 <mvollmer> not yet, though. 13:11:50 <mvollmer> but enabling the copr is harmless already now 13:12:00 <andreasn> will it work on CentOS? 13:12:12 <mvollmer> not without extra work. 13:12:26 <andreasn> same with RHEL I guess 13:12:36 <mvollmer> yeah 13:13:30 <mvollmer> ok 13:13:55 <mvollmer> #action mvollmer get storaged from copr for the f22 test machine images 13:14:01 <andreasn> excellent 13:14:29 <mvollmer> but let's hear it from stef also 13:14:44 <mvollmer> he has the best overview of this, I think. 13:15:08 <mvollmer> ok, eot? 13:15:36 <andreasn> one more thing 13:15:42 <mvollmer> yep 13:16:01 <andreasn> will it make the RHEL-7/x86-64 tests to fail? 13:16:24 <mvollmer> probably... :-) 13:16:40 <andreasn> and should the copr be fixed so it works for that too? 13:17:05 <mvollmer> we could, 13:17:29 <dperpeet> rhel 7 should stay green on master 13:17:36 <andreasn> all right 13:17:47 <andreasn> just wanted to make sure we don't make half the tests red 13:17:59 <andreasn> eot for me :) 13:18:02 <mvollmer> phatina, do you build storaged for epel? 13:18:14 <mvollmer> i see that it fails: https://copr.fedoraproject.org/coprs/phatina/storaged/build/87526/ 13:18:48 <phatina> mvollmer: no 13:18:54 <phatina> mvollmer: I need to verify, what's the problem 13:19:52 <mvollmer> ok, that would be great. 13:20:10 <mvollmer> #action phatina to check and hopefully build storaged 2 for epel 7. 13:20:44 <andreasn> excellent 13:21:00 <mvollmer> #topic API Compatibility 13:22:01 <mvollmer> we don't have that under control yet, but I think there is a good plan. 13:22:05 <mvollmer> and pull requests for it. 13:22:26 <mvollmer> so we (temporarily) didn't keep the promise, but we will soon again. 13:22:59 <mvollmer> petervo and stef are on top of that 13:23:43 <mvollmer> comments? 13:23:43 <petervo> well i imagine we won't hear from stef too much this week 13:23:49 <mvollmer> right 13:24:29 <petervo> i've been holding off on doing a release until we at least get something like #2425 13:25:19 <mvollmer> i think there are more places where we need to ignore unknown message 13:25:24 <mvollmer> in the bridge 13:25:26 <petervo> and the the capabilities discussion can go on until we all thing we have it right 13:25:42 <dperpeet> should we add some testing for that? 13:25:45 <dperpeet> with unknown messages 13:26:08 <mvollmer> or old versions of cockpit 13:26:25 <petervo> testing between versions of cockpit would be good 13:26:36 <dperpeet> yes, now that we have image versions 13:26:38 <petervo> but seperate feature/PR 13:26:53 <mvollmer> definitely 13:27:19 <petervo> mvollmer, can you think of were else we might need to look at ignoring unknown messages? 13:27:35 <mvollmer> wait a second... 13:28:24 <mvollmer> https://github.com/cockpit-project/cockpit/blob/master/src/bridge/cockpitmetrics.c#L80 13:28:27 <mvollmer> places like that 13:29:09 <mvollmer> they have nothing to do with the current bug, but we might fix them too, before we hit them 13:31:28 <mvollmer> petervo, I think #2425 is good to go with the additional docs, and it fixes the bug, so let's go ahead with it 'asap'. 13:31:36 <petervo> ok 13:31:47 <mvollmer> cool 13:31:59 <mvollmer> and then we keep discussing. :-) 13:32:04 <dperpeet> I added priority label 13:32:13 <dperpeet> since it's blocking release 13:32:31 <mvollmer> very good 13:32:47 <mvollmer> next? 13:33:01 <petervo> yep 13:33:26 <mvollmer> #topic 13:33:38 <mvollmer> heh, how did I do that? 13:33:43 <mvollmer> #topic build status on landing page 13:33:48 <dperpeet> so, our build status on the landing page will become more rather than less confusing as we add more configurations 13:33:50 <mvollmer> ohh, easy. 13:33:58 <dperpeet> https://github.com/cockpit-project/cockpit 13:34:16 <andreasn> confusing how? 13:34:23 <dperpeet> prior discussions led me to believe that we should add some kind of differentiation 13:34:40 <dperpeet> between essential and non-essential configurations 13:35:05 <dperpeet> for example: jenkins, fedora-22, rhel-7 are essential 13:35:07 <mvollmer> that might depend on the viewer 13:35:28 <dperpeet> well, those we strive to fix 13:35:33 <dperpeet> so we should present our view 13:35:41 <mvollmer> yes, true 13:35:44 <dperpeet> but this is why it needs to be discussed 13:35:55 <dperpeet> do we send the wrong message by saying something is non essential? 13:36:05 <dperpeet> or should we present all equally 13:36:07 <petervo> maybe say release blockers 13:36:14 <dperpeet> with the implied message: "you don't like this? fix it!" 13:36:34 <dperpeet> rawhide is something we've been treating as non essential 13:36:47 <andreasn> what ones are non-essensial? atomic and rawhide? 13:37:06 <dperpeet> atomic is somewhere in the middle, but pretty essential 13:37:09 <dperpeet> see the problem? =) 13:37:31 <dperpeet> so what do we do, when we add more 13:37:44 <dperpeet> say archlinux, rhel-atomic, ... 13:38:06 <mvollmer> it would be nice to add some comments, like "rawhide is new, has never passed, and is broken by itself" vs "f22 is usuall green and now it's red because of stupid race in our tests" 13:38:57 <dperpeet> I like the idea of comments 13:39:30 <mvollmer> we can't update master to update the comments, though. 13:39:33 <andreasn> is there a nice way of doing that without taking up too much space? like in the alt-tag or something? 13:39:50 <dperpeet> I think it would be nice to link to a more detailed page 13:39:54 <dperpeet> like hubbot status 13:39:55 <andreasn> yeah 13:39:55 <mvollmer> i think the links should go to dedicated pages. 13:40:02 <mvollmer> not to the general hubbot status page 13:40:10 <dperpeet> yes, separate 13:40:12 <dperpeet> but links like that 13:40:27 <dperpeet> ok, I'll try something like that 13:40:27 <mvollmer> or we can try to shove things into the README via iframes 13:40:41 <dperpeet> that sounds a bit horrible :) 13:40:50 <andreasn> iframes in the readme? funky 13:40:52 <mvollmer> well, now we use images.... 13:41:08 <dperpeet> and the text gets loaded if you hover? 13:41:10 <dperpeet> :) 13:41:22 <dperpeet> I'll prepare something external 13:41:23 <petervo> we can xss ourselves 13:41:36 <dperpeet> and if that info is useful and good, we think about integration 13:42:05 <dperpeet> #action dperpeet to prepare extra build info on dedicated pages 13:42:44 <dperpeet> end of topic 13:42:53 <mvollmer> :-) 13:43:02 <mvollmer> #topic github labels 13:43:16 <dperpeet> andreas started a brainstorm on this 13:43:37 <dperpeet> we decided that a bunch of issues look like they're just ignored 13:43:40 <dperpeet> which isn't true (usually) 13:43:41 <andreasn> and dperpeet added some notes 13:43:56 <dperpeet> #link https://github.com/cockpit-project/cockpit/wiki/Issue-tracker-organization 13:44:07 <dperpeet> feel free to partake 13:44:27 <dperpeet> I think that implied decisions should be explicit 13:44:51 <dperpeet> we also don't want to read tons of labels 13:45:02 <dperpeet> and work in progress should remain on trello, I think 13:45:04 <stefw> dperpeet, yes exactly 13:45:05 <andreasn> re Needs-discussion vs. Needs-design, I wanted something that was a clear "yes, this is a good idea" from the team or not 13:45:10 <dperpeet> if we have to manually sync, we'll lose 13:45:17 <stefw> dperpeet, i agree with all your commenst on that wiki page :) 13:45:26 <stefw> you migth as well add my name to all of them too :) 13:45:38 <dperpeet> heh 13:45:57 <andreasn> categories was what I was first was thinking of when I started it. I'm starting to get lost in what issues belong to what section with 300 issues 13:46:12 <dperpeet> andreasn, why do we need categories 13:46:22 <dperpeet> in the sense of which section of cockpit 13:46:37 <dperpeet> we should make use of renaming the issue if it's unclear 13:46:44 <andreasn> yeah, that could work too 13:46:47 <stefw> yeah 13:46:54 <dperpeet> how about we use the same structure as for pull requests 13:47:06 <dperpeet> we can just prepend something 13:47:10 <andreasn> I wanted a way to get a quick overview of what storage issues was open 13:47:11 <stefw> yup 13:47:15 <dperpeet> and github will keep a history of changes in the conversation 13:47:18 <dperpeet> so nothing is lost 13:47:18 <stefw> and that mirrors what we do in commit messages 13:47:30 <stefw> it's also very searchable 13:48:02 <dperpeet> I'll wait a day or two for more comments and discussion 13:48:05 <andreasn> so name them similar to this? https://github.com/cockpit-project/cockpit/issues/1959 and https://github.com/cockpit-project/cockpit/issues/1964 ? 13:48:08 <dperpeet> and then I think we can make a little decision tree 13:48:13 <dperpeet> to show how we label stuff 13:48:15 <petervo> what is won't implement supposed to convey? we won't implement but you are welcome to, or we don't want this feature and won't ever accept it? 13:48:39 <dperpeet> petervo, e.g. it conflicts with cockpit ideals 13:48:44 <dperpeet> or is too specific 13:50:54 <dperpeet> the fact that I'm trying hard to think of an example tells me I should remove the label 13:50:57 <dperpeet> :) 13:51:25 <andreasn> some kind of indication that "this is a bad idea, actually". But maybe wontfix is that? 13:51:25 <dperpeet> andreasn, yes: rename them that way 13:51:33 <dperpeet> fix implies a bug 13:51:34 <andreasn> dperpeet: sounds good to me 13:51:45 <dperpeet> but we can just use it for that 13:51:49 <dperpeet> instead of having a label 13:51:51 <petervo> i think we need something like that, i just wasn't clear which one it was meant for 13:51:58 <petervo> maybe 'rejected' 13:52:14 <dperpeet> that's so negative, I would really hesitate to use that for someone else's idea 13:52:18 <dperpeet> but maybe that's just me 13:53:00 <petervo> yeah maybe 13:53:04 <dperpeet> we can rename "wontfix" into "wontimplement" 13:53:06 <dperpeet> to be more generic 13:53:10 <dperpeet> instead of adding a label 13:53:11 <andreasn> not-cockpit? 13:53:24 <andreasn> to indicate "this could be a great thing, but not for cockpit"? 13:53:30 <dperpeet> that would confuse me 13:53:34 <dperpeet> we have "invalid" 13:54:02 <andreasn> wontimplement could work 13:54:13 <dperpeet> and rename wontfix to that? 13:54:26 <andreasn> possibly 13:55:04 <dperpeet> the idea is that if something is good 13:55:15 <dperpeet> and we think it should be implemented sometime in the near future 13:55:20 <dperpeet> we add it to trello 13:55:25 <dperpeet> not add another label to it 13:55:26 <andreasn> right 13:56:17 <dperpeet> ok, then I'll revise this soon 13:56:37 <dperpeet> according to my current count we will have the same number of labels afterwards 13:56:45 <aruiz> sgallagh, do you know a reliable way to check if a user belongs to a group other than parsing the output of 'getent group'? 13:56:54 <andreasn> that's good 13:57:00 <andreasn> thanks for all the feedback! 13:57:11 <sgallagh> aruiz: getgroups() 13:58:04 * aruiz reads man 13:58:09 <sgallagh> Sorry, getgrouplist() 13:58:20 <andreasn> next topic? 13:58:30 <sgallagh> aruiz: http://man7.org/linux/man-pages/man3/getgrouplist.3.html 13:59:02 <aruiz> sgallagh, oh great! 13:59:03 <mvollmer> #topic aob 13:59:08 <aruiz> just what I was looking for 13:59:20 <aruiz> sgallagh, thanks 13:59:31 <andreasn> aob? 13:59:39 <mvollmer> any other business 14:00:42 <andreasn> oh. I thought it was a library 14:00:45 <andreasn> :) 14:01:07 <mvollmer> :-) 14:01:12 <mvollmer> I think we are done, no? 14:01:15 <andreasn> think so 14:01:21 <mvollmer> #endmeeting