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