13:01:15 <sgallagh> #startmeeting rolekit (2015-10-06)
13:01:15 <sgallagh> #meetingname rolekitweekly
13:01:15 <sgallagh> #chair sgallagh twoerner nilsph
13:01:15 <zodbot> Meeting started Tue Oct  6 13:01:15 2015 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:15 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:01:15 <zodbot> The meeting name has been set to 'rolekitweekly'
13:01:15 <zodbot> Current chairs: nilsph sgallagh twoerner
13:01:16 <sgallagh> #topic init process
13:01:17 <sgallagh> .hello sgallagh
13:01:18 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
13:01:29 <twoerner> .hello twoerner
13:01:31 <zodbot> twoerner: twoerner 'Thomas Woerner' <twoerner@redhat.com>
13:03:08 <sgallagh> nilsph: You around?
13:04:08 <sgallagh> #topic Agenda
13:04:16 <sgallagh> #info Agenda Item: Ticket Triage
13:04:30 <sgallagh> Any other items for the agenda this week?
13:04:57 <sgallagh> (I should have more next week; I'll be talking to some potential rolekit consumers on Thursday and hopefully getting some requests that we can focus on)
13:05:06 <twoerner> nope.. no more things I think
13:05:07 <nilsph> .hello nphilipp
13:05:08 <zodbot> nilsph: nphilipp 'Nils Philippsen' <nphilipp@redhat.com>
13:05:25 <twoerner> sgallagh: that is great
13:05:28 <nilsph> sgallagh: not sure if this needs on the agenda
13:05:58 <nilsph> sgallagh: rvokal asked me about "the followup plan", "what still needs to be done in rolekit"
13:06:34 <sgallagh> nilsph: Right, my plan is for that to become clear after Thursday ;)
13:07:01 <sgallagh> But our ticket for triage today is related:
13:07:13 <nilsph> sgallagh: ok, I'll tell him that
13:07:15 <sgallagh> #topic https://github.com/libre-server/rolekit/issues/51 - Implement a CI test framework
13:07:45 <sgallagh> This is something I want to work on in collaboration with the Fedora QA team, ideally.
13:08:16 <sgallagh> rolekit, like Cockpit, is in a position where a good CI test framework would actually be testing large swaths of Fedora, not just a single project.
13:08:34 <sgallagh> So I'd like for this to be a big part of our Fedora 24 efforts
13:08:39 <nilsph> mhm
13:09:04 <twoerner> sgallagh: I'd like to see this also for other projects..
13:09:14 <sgallagh> adamw: I know you aren't awake yet, but I'd like for you to read this conversation later, so ping :)
13:09:37 <nilsph> this may require someone triaging CI errors into "this is rolekit" and "this is some other component (and specifically $this)"
13:09:46 <sgallagh> twoerner: I was at an internal meeting last week where it was beaten into us that CI/CD is going to become necessary for all RHT-sponsored projects :)
13:10:10 <sgallagh> nilsph: Right, which is why I want this to be a collaborative effort with Fedora QA.
13:10:25 <sgallagh> It would be mutually-beneficial and should help us catch potential blocker bugs early
13:11:23 <twoerner> sgallagh: hmm - maybe I missed it, but I do not think that I have seen somehting about this yet
13:11:58 <sgallagh> twoerner: This will be filtering down from the managers. But the idea is that CI should be built into our efforts.
13:12:57 <nilsph> sgallagh: so does this mean integrating vagrant with jenkins or whatver, or replacing it?
13:13:22 <sgallagh> nilsph: What it means is undefined at this moment.
13:13:39 <nilsph> ok
13:13:51 <sgallagh> Is vagrant still broken? I haven't tinkered with it for a while
13:13:55 <twoerner> I hope we will not end up in a similar test-hell as docker where updates for linux are blocked by windows build failures from time to time .. :-)
13:14:30 <sgallagh> Let's cross one bridge at a time
13:15:22 <sgallagh> So anyway, my proposal is that we attempt to move forward with this for a Fedora 24 Beta (not Alpha) target.
13:15:23 <nilsph> Yeah, we can alway blow up things if they don't work :)
13:15:27 <sgallagh> And that we make this high priority.
13:15:35 <nilsph> +1
13:15:38 <twoerner> +1
13:15:43 <sgallagh> nilsph: I fail to see why we can't blow things up if they do work as well
13:16:01 <nilsph> if they do work, maybe we'd rather keep them :)
13:16:19 <sgallagh> nilsph: Haven't you ever heard of pen-testing?
13:16:21 <sgallagh> :-D
13:16:47 <nilsph> heh
13:17:46 <sgallagh> #agreed Continuous Integration/Deployment efforts will be a primary focus for the Fedora 24 schedule and we will try to collaborate on this with Fedora QA (+3, 0, -0)
13:17:57 <sgallagh> #topic Open Floor
13:18:48 <twoerner> sgallagh: do you know if the properties patch will be removed from dbus-pyton, now?
13:18:54 <sgallagh> As noted above, I'm going to be trying to meet with multiple consumers in the next few days. Hopefully we'll have some clearer short- and medium-term goals after that and we can start assigning new tasks.
13:19:05 <sgallagh> twoerner: I haven't heard anything from Leigh.
13:19:24 <sgallagh> It's definitely coming out of F24; no word on F23 but we don't rely on it anymore so it shouldn't matter either way.
13:19:33 <twoerner> there was no additional change in the bug
13:20:39 <sgallagh> twoerner: There's a build in Koji for F23 that drops the patch, but it has not been submitted as an update to F23
13:20:57 <twoerner> I have done that locally for me also
13:21:41 <sgallagh> Thanks again for figuring out a workaround there. Rewriting against a new D-BUS framework would have been nightmarish
13:22:09 <twoerner> using rolekit with python2 on RHEL-7 is now also possible :-)
13:22:52 <twoerner> sgallagh: yes, a rewrite will most likely be needed in the future
13:23:31 <twoerner> to get some of the new features of kdbus
13:23:51 <twoerner> but the time frame is still completely open...
13:24:05 <twoerner> NM has been ported to gdbus for version 1.2
13:24:13 <twoerner> s/for/in/
13:24:26 <sgallagh> I saw that.
13:24:41 <twoerner> but with some hacks/workarounds... :-)
13:24:42 <sgallagh> twoerner: Do you want to work on a python2-compatibility patch?
13:24:52 <sgallagh> Please file an issue and we can discuss when and where to land it.
13:25:27 <sgallagh> But my thoughts on RHEL 7 were that if we explored it, we'd likely do so with the Python 3 in the Developer Toolset.
13:25:47 <sgallagh> I don't really want to carry Py2/Py3 cruft if we can avoid it.
13:25:52 <twoerner> there is no python3 in RHEL-7 yet
13:26:42 <sgallagh> twoerner: Not in the base, but it's available in the Developer Toolset
13:26:51 <twoerner> there is some collection as far as I know
13:26:59 <sgallagh> Right, DTS is an SCL
13:29:58 <sgallagh> twoerner: Let's dodge the Python 2 question for now.
13:30:04 <twoerner> ok..
13:30:12 <sgallagh> Anything else for Open Floor?
13:30:21 <sgallagh> (If not, I'll give you 30 minutes of your lives back)
13:30:52 <nilsph> yeah
13:31:21 <nilsph> I thought we could add some kind of a HACKING or CONTRIBUTING file toplevel to the source
13:31:45 <nilsph> Where we can put in stuff like "Don't import wildcards" and so forth :)
13:31:52 <sgallagh> nilsph: That's kind of what we've been using README.md for.
13:32:04 <sgallagh> But I'm all for establishing a coding guideline.
13:32:12 <sgallagh> Write it up, I'll review it :-D
13:32:27 <sgallagh> Oh, I did have one other question:
13:32:42 <nilsph> I think we should separate info for users (README) from info for contributors (HACKING, whatever)
13:32:48 <sgallagh> Review Board 2.5 Beta: Impressions, things you like, things you don't?
13:33:05 <sgallagh> nilsph: Sounds reasonable
13:33:34 <nilsph> I found some reviewed commits have overly long commit info lines, is that a byproduct of revieboard, or did it just happen?
13:34:26 <sgallagh> nilsph: Ah, I suspect I know why that happens.
13:34:39 <nilsph> ok
13:34:49 <sgallagh> Short answer: by-product of RB
13:35:15 <sgallagh> Longer answer: `rbt patch -C` probably needs to reflow the description field to fit inside 79 characters.
13:35:41 <nilsph> Aah.
13:36:12 <nilsph> So it does rewrite the commitlog from the title and description fields?
13:36:16 <sgallagh> The ones that are extra long are the places where we edited the description field in the UI and added comments without explicitly adding newlines.
13:36:47 <sgallagh> nilsph: Well, when I push, I always apply the patches with `rbt patch -C` because it writes the approriate additional comments in.
13:36:58 <sgallagh> And it confirms for me that I'm pushing exactly the right version of the patch
13:37:21 <nilsph> Ahh so that's how the "Testing Done" stuff ended up in the commit logs...
13:37:29 <sgallagh> Yes
13:38:08 <sgallagh> Actually, another patch I'm working on upstream is to have ShipIts translate into "Signed-off-by" lines as well
13:38:44 <nilsph> Ideally, RB would somehow update description etc. from updated (rbt post -u) commits.
13:39:02 <sgallagh> nilsph: add `-g` and it will :)
13:39:09 <nilsph> Aaahh.
13:39:11 <nilsph> TIL
13:39:27 <nilsph> should be default :)
13:39:38 <sgallagh> It's default for `rbt post` but not for update.
13:39:46 <nilsph> and "testing done" should be a separate field
13:39:50 <sgallagh> I can see an argument for not clobbering edits made in the GUI
13:40:09 <nilsph> well...
13:40:15 <sgallagh> nilsph: It is a separate field.
13:40:22 <sgallagh> That you have to specify manually to `rbt`
13:40:30 <nilsph> mhm
13:40:46 <sgallagh> nilsph: The feature to update the fields is there. Make an alias if you want :)
13:41:01 <nilsph> from the point of someone whose patch is reviewed, we should have a workflow where what I edited in the commitlog lands in the final commit by default :)
13:41:21 <nilsph> but now I know about "-g" I can work with it
13:41:43 <nilsph> it just very surprising if you update the patch, and get the old commitlog with it
13:42:10 <twoerner> I'd also like to have -g per default
13:42:20 <sgallagh> I'd have to check the docs, but I think you can set an option to change the default.
13:42:39 * nilsph goes looking for $HOME/.rbtrc
13:42:43 <twoerner> sometimes I was editing the text in reviewboard manually
13:43:09 <nilsph> Hmm nothing :(
13:43:19 <twoerner> there is no $HOME/.rbtrc ..
13:43:22 <sgallagh> https://www.reviewboard.org/docs/rbtools/dev/rbt/commands/post/#controlling-guessing-behavior
13:43:44 <sgallagh> It's set per-project.
13:44:13 <sgallagh> So if you want to add GUESS_FIELDS = 'yes' to .reviewboardrc, I'll ack and push it :)
13:44:27 <sgallagh> By default it's 'auto' which means create but not update
13:45:31 <twoerner> why is there no man page for rbt that is covering this?
13:45:32 <nilsph> I'm actually unsure about setting this project-wide rather than per user
13:46:34 <sgallagh> twoerner: The manual is on the web. It can also be built into the package, but I keep not having the motivation to do so
13:47:02 <sgallagh> nilsph: Then you can set it on your own .reviewboardrc and add that to your personal .gitignore
13:48:40 <sgallagh> OK, any other topics?
13:49:00 <nilsph> not from me
13:49:49 <nilsph> and I'd rather not have conflicting .gitignore and .reviewboardrc in the rolekit tree, but from a first glance rbt should support some kind of user configuration
13:51:04 <sgallagh> nilsph: Let me check the source.
13:51:10 <nilsph> just checking it
13:51:13 <sgallagh> It *may* support a per-user .reviewboardrc as well
13:51:14 <nilsph> it's used in the comments
13:51:20 <nilsph> I mean referenced
13:51:30 <nilsph> # user's $HOME/.reviewboardrc
13:51:42 <sgallagh> OK, so there you go.
13:51:51 <nilsph> Just not sure which one takes precedence
13:52:03 <nilsph> I guess I'll have to try it :)
13:52:06 <sgallagh> If it's not your personal one, I'd call that a bug
13:53:49 <nilsph> Hmm it doesn't pick up the bogus REVIEWBOARD_URL I put into my own rc...
13:54:01 <sgallagh> nilsph: Yeah, I just found the source
13:54:16 <sgallagh> It looks like your $HOME is the lowest prio
13:54:19 <sgallagh> But that's probably accidental
13:54:36 <sgallagh> see: rbtools/utils/filesystem.py
13:54:41 <sgallagh> I'll work up a patch
13:55:09 <nilsph> is it on github? then I can do that as well
13:55:11 <sgallagh> OK, I'm declaring this meeting over :)
13:55:35 <twoerner> sgallagh: I just found a gub!
13:55:37 <twoerner> bug!
13:55:48 <sgallagh> https://github.com/reviewboard/rbtools
13:55:58 <sgallagh> twoerner: A bug in what?
13:56:23 <twoerner> TRANSITIONAL_STATES is used in dbusrole.py but not imported
13:56:53 <sgallagh> nilsph: The list of config paths is sorted using os.readdir() and then tacks $HOME on at the end. But it then processes them in reverse order
13:57:06 <nilsph> yeah found it
13:57:49 <sgallagh> twoerner: Patches most welcome :)
13:57:57 <sgallagh> OK, anything else before I close the meeting?
13:58:08 <nilsph> maybe we should add a call to python3-pyflakes for python files to the pre-commit hook?
13:58:13 <nilsph> or is that too drastic?
13:58:40 <nilsph> but we don't need to discuss that in the meeting I guess
13:58:44 <sgallagh> nilsph: I'm fine with that if you want to send a patch.
13:59:00 <nilsph> I'm not sure it'll work, with the hooks being run on github....
13:59:06 <nilsph> need to experiment first
13:59:16 <sgallagh> Oh, right. In that case, maybe include it in 'make test-rpm' ?
13:59:22 <nilsph> and we don't want to be held up by false positives either
13:59:29 <nilsph> something like that maybe
14:01:04 <sgallagh> OK, we're now at the top of the hour. Thanks for coming, folks.
14:01:15 <sgallagh> This was a more involved meeting than I had expected.
14:01:22 <sgallagh> #endmeeting