Skip to content
This repository has been archived by the owner on Jul 16, 2020. It is now read-only.

Weekly Meeting 2016 05 19

Jump to bottom
Tim Pepper edited this page May 19, 2016 · 3 revisions

Agenda

  • Opens
  • Meeting logs: Which bot? Which infrastructure? Where do we store the logs?
  • Release process: Validate the proposal
  • QA: Functional testing
  • Single Machine Setup: Status
  • Slack?

===================== #ciao-project Meeting

Meeting started by sameo at 16:01:44 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-05-19-16.01.log.html .

Meeting summary

Meeting ended at 17:06:27 UTC.

Action Items

  • Amy to add some github labels for prioritizing issues/bugs
  • Amy to import all issues into github
  • Kristen to set a Slack team for us to start playing with
  • kristenc to copy the IRC logs
  • kristenc to put the logs on her webserver as well
  • tpepper to document the qa flow and daily tagging
  • Document the requirement for modifying changelog.md as part of any PR.
  • sameo improve CONTRIBUTING to point to the release process wiki
  • Move the changelog generation discussion to the mailing list for now
  • fuentess to move the QA document to the wiki
  • tpepper to check for better github permissions and grant e.g. wiki editing permission.
  • Prepare for creating a set of fake clients and servers.
  • sameo single VM and QA to be added to next week agend
  • AmyLee7 to decide if we have this meeting next week

Action Items, by person

  • fuentess
    • fuentess to move the QA document to the wiki
  • kristenc
    • kristenc to copy the IRC logs
    • kristenc to put the logs on her webserver as well
  • sameo
    • sameo improve CONTRIBUTING to point to the release process wiki
    • sameo single VM and QA to be added to next week agend
  • tpepper
    • tpepper to document the qa flow and daily tagging
    • tpepper to check for better github permissions and grant e.g. wiki editing permission.
  • UNASSIGNED
    • Amy to add some github labels for prioritizing issues/bugs
    • Amy to import all issues into github
    • Kristen to set a Slack team for us to start playing with
    • Document the requirement for modifying changelog.md as part of any PR.
    • Move the changelog generation discussion to the mailing list for now
    • Prepare for creating a set of fake clients and servers.
    • AmyLee7 to decide if we have this meeting next week

People Present (lines said)

  • sameo (109)
  • tpepper (103)
  • kristenc (100)
  • mcastelino (25)
  • markusry (16)
  • fuentess (11)
  • mrkz (9)
  • chamings (6)
  • ciaomtgbot (2)
  • jvillalo_mobl (1)
  • albertom (1)
  • obedmr (1)

Generated by MeetBot_ 0.1.4

.. _MeetBot: http://wiki.debian.org/MeetBot

Full IRC Log

16:01:44 <sameo> #startmeeting
16:01:44 <ciaomtgbot> Meeting started Thu May 19 16:01:44 2016 UTC.  The chair is sameo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:44 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:51 <kristenc> woot!
16:01:55 <chamings> \o/
16:01:56 <mcastelino> o/
16:01:57 <obedmr> o/
16:02:00 <sameo> o/
16:02:04 <tpepper> o/
16:02:09 <jvillalo_mobl> o/
16:02:20 <fuentess> o/
16:02:27 <markusry> o/
16:03:16 <sameo> #topic Ciao weekly meeting - 2016-0519
16:03:16 <tpepper> fyi today's agenda has moved a bit as we organized the wiki:  https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-05-19
16:03:19 <albertom> the bot hsould be named hola :P
16:03:58 <sameo> First item on the agenda are opens.
16:04:00 <chamings> sameo:  suggest changing #topic as you move through agenda items; keeps the summary nice and readable
16:04:14 <sameo> #topic Opens
16:04:16 <sameo> chamings: Thanks.
16:04:45 <sameo> Does anyone have any opens ?
16:04:56 <tpepper> I have none..agenda's got everything I'm concerned with short term
16:05:02 <kristenc> will we be doing bug scrubs at some point?
16:05:07 <mcastelino> Yes. Can people provide feedback on the two single machine setup proposal
16:05:09 <kristenc> going through the open issues?
16:05:24 <sameo> mcastelino: It's on the agenda already.
16:05:28 <mcastelino> ok
16:05:43 * kristenc reads agenda
16:05:45 <sameo> kristenc: I think we should prioritize bugs/issues before scrubbing ?
16:05:52 <tpepper> (I'll add an agenda template to the wiki)
16:06:41 <kristenc> yes - probably agenda item #1 should be - what do we want this meeting to be generally?  Obviously, we have a lot of ramping up to do today, and it will be an unusual agenda
16:07:02 <sameo> #info We will eventually do bug scrub during this meeting. We need to have a prioritization method first
16:07:46 <sameo> kristenc: I think we may end up filling the meeting if we start with bug scrubs, unless we select a short list of them as part of the agenda.
16:08:11 <kristenc> i'm ok with deferring that till we have established our process first - it's more important.
16:08:28 <tpepper> we will want some level of pre-work on meetings.  have a list of bugs that need focus added to the agenda ahead of the mtg.  to keep the meeting itself efficient.
16:08:39 <sameo> Agreed.
16:08:50 <kristenc> yes.
16:09:02 <sameo> #info Bugs to be scrubbed should be added to the agenda first.
16:09:12 <kristenc> by when and by who?
16:09:31 <fuentess> do we have priorities for bugs? if so we can filter them that way to include them in the agenda
16:09:31 <sameo> AmyLee7 ?
16:09:37 <sameo> fuentess: We don't
16:09:39 <kristenc> yes.
16:09:49 <kristenc> yes - to this should be something amy does.
16:10:14 <sameo> fuentess, kristenc, tpepper: Do we want to use github issues for tracking all issues ?
16:10:14 <markusry> Right now we have 72 open issues and only 14 bugs
16:10:28 <sameo> fuentess, kristenc, tpepper: Do we want to use github issues for tracking all bugs?
16:10:32 <markusry> Perhaps they're not all labelled correctly
16:10:54 <kristenc> sameo: amy and I were talking about this the other day - she is going to look into project management tools that integrate with github.  meanwhile, we need to use github issues.
16:11:12 <kristenc> we need a tool that can be publicly viewable we think.
16:11:20 <sameo> #action Amy to add some github labels for prioritizing issues/bugs
16:11:22 <markusry> And one that imports the issues we already have
16:11:50 <kristenc> there are quite a few tools which use the github api to interact with github issues.
16:11:56 <kristenc> so it layers on top of that.
16:11:59 <kristenc> doesn't replace.
16:12:03 <sameo> I'll assign that to Amy.
16:12:26 <sameo> #action Amy to import all issues into github
16:12:36 <tpepper> markusry or kristenc: can you comment on what slack would look like on top of that?
16:13:03 <tpepper> if it's non-trivial, we can defer slack (or other alt's) discussion for another day
16:13:20 <markusry> sameo: Actually, my comment was that if we move to some other bug tracking system, it would be nice if if imported all existing issues from github
16:13:45 <kristenc> tpepper: I've been playing with slack for about a week now.  I'm no expert.  it has some nice integration features.  it will integrate with various project management tools. you can update bugs/issues/tasks from the channel then.
16:13:49 <markusry> But from reading kristen's comments it doesn't look like this will be a problem
16:14:09 <markusry> kristenc: Did you create a team for ciao on slack?
16:14:18 <sameo> markusry: Ok. But if we're going to track them through github at first, we also need to put the ones we currently have on other tools there.
16:14:44 <kristenc> markusry: no.  the concern I have with slack is whether its open to anyone to join your team, or whether you have to issue invitations.
16:15:10 <sameo> #info Kristen been playing with slack for about a week now.  She's no expert.  it has some nice integration features.  it will integrate with various project management tools. you can update bugs/issues/tasks from the channel then
16:15:11 <kristenc> with irc meetings, they are definitely clunkier than in slack.
16:15:16 <markusry> sameo: Ok.  I see.
16:15:21 <kristenc> everything actually is very nice in slack.
16:15:31 <kristenc> and you can setup an ircbot <-> slack
16:15:58 <markusry> kristenc: So what teams did you join?
16:16:03 <sameo> #info Kristen concern about Slack being open to everyone or needing invitations
16:16:17 <kristenc> markusry: I joined the "women who go" slack team.
16:16:20 <sameo> kristenc: Can I talk to slack from my IRC client ?
16:16:31 <kristenc> and we are also playing with it as part of the LF TAB.
16:16:37 <markusry> does it integrate with github?
16:16:41 <mcastelino> kristenc: does slack integrate with github such that you can map a commit to an issue
16:16:42 <kristenc> yes.
16:17:06 <sameo> mcastelino: You can do that through the commit message btw.
16:17:07 <kristenc> there are github issues integrations.  but more likely you'd integrate with trello or whatever amy choses for a project management solution.
16:17:28 <kristenc> there are at least 3 we looked at that have both slack and github integration
16:17:56 <kristenc> we are all a bit busy for this right now, but we can setup a team and just play with it.
16:17:57 <sameo> #info Slack integrates with IRC, github and potentially trello.
16:18:15 <markusry> There's another go team I think.
16:18:16 <markusry> http://bit.ly/go-slack-signup\
16:18:16 <tpepper> slack's motto is "be less busy"
16:18:21 <markusry> I'll give this a go.
16:18:26 <sameo> #action Kristen to set a Slack team for us to start playing with
16:18:33 <kristenc> ok
16:18:52 <sameo> We should move to the next items on the agenda if there are no other opens...
16:19:21 <sameo> #topic Meetings logging
16:19:25 <mrkz> sameo: if you use irc nick for the actions, it'll show better on minutes :)
16:19:28 <tpepper> yes lets move on.  looks like item two (meeting structure) and the last item ("slack?") have been covered now
16:19:51 <tpepper> for meeting structure I've set up:
16:19:52 <tpepper> https://github.com/01org/ciao/wiki/Meetings
16:19:55 <sameo> tpepper: We should decide where we want to store the logs.
16:19:57 <tpepper> https://github.com/01org/ciao/wiki/Meetings-Weekly-Agenda-Template
16:20:02 <tpepper> https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-05-19
16:20:05 <tpepper> basic hierarchy
16:20:11 <chamings> #link https://github.com/01org/ciao/wiki/Meetings
16:20:18 <tpepper> we can auto copy logs onto the wiki page in the short term
16:20:18 <chamings> #link https://github.com/01org/ciao/wiki/Meetings-Weekly-Agenda-Template
16:20:25 <chamings> #link https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-05-19
16:20:33 <chamings> (those will show up in the summary as hyperlinks now)
16:20:33 <tpepper> we're now trialing the meeting bot
16:20:40 <tpepper> logs stored on github
16:20:56 <sameo> #info We will copy meeting logs into the github wiki for now.
16:21:01 <tpepper> so I think we've got this addressed for now, aside from who does the manual copy for now
16:21:12 <kristenc> they are on my machine, so I think I'm doing it.
16:21:21 <sameo> #action kristenc to copy the IRC logs
16:21:24 <tpepper> ok...bot owner does the copy.
16:21:29 <sameo> mrkz: Thx
16:21:37 <tpepper> eventually we can look into automation.  but this should be lightweight as is.
16:21:39 <kristenc> I am going to temporarily setup a way to stuff the logs onto my personal webserver, so anyone can get them.
16:21:43 <kristenc> in case I'm not here.
16:21:46 <tpepper> and maybe slack allows something fancier too?
16:21:54 <tpepper> kristenc: sounds like a plan.
16:22:03 <kristenc> slack is designed for online meetings, so I would guess so.
16:22:10 <kristenc> but we'll make this work.
16:22:33 <sameo> #action kristenc to put the logs on her webserver as well
16:22:38 <kristenc> btw the bot is living on a desktop machine that is always on.
16:22:46 <kristenc> so I will leave it going.
16:22:53 <sameo> kristenc: Cool, thx.
16:23:15 <tpepper> simple/easy/sufficient for now
16:23:20 <sameo> Next topic: Release process
16:23:41 <sameo> Unless someone wants to add something about meeting structure...
16:23:56 <tpepper> #link https://github.com/01org/ciao/wiki/Release-Process
16:24:02 <sameo> #topic Release process
16:24:25 <kristenc> i feel we've agreed in principle to the release process.  we just have some details to work out.
16:24:26 <sameo> I'd like to know if everyone agrees with kristenc proposal
16:24:36 <tpepper> it's a good starting point
16:24:41 <sameo> Yep.
16:24:46 <tpepper> fuentess: any comments especially from your side?
16:25:00 <tpepper> if dev inputs like it, but qa consumers don't...we need to fix it
16:25:42 <fuentess> Well, I need to investigate a way to manage my QA in physical cluster and then send the 'Go' to github
16:26:00 <kristenc> fuentess: the "go" is just a tag.
16:26:14 <kristenc> so - what you do is grab the head commit.
16:26:17 <kristenc> then, test it.
16:26:27 <kristenc> then, if it passes, use the github api to tab that commit id.
16:26:35 <kristenc> if it doesn't pass, don't tag.
16:26:39 <fuentess> kristenc: got it
16:26:43 <tpepper> fuentess: kristenc and I were brainstorming this as a way to simplify the plumbing
16:26:46 <kristenc> the github api is http post/get
16:26:54 * kristenc looks for link
16:27:04 <fuentess> I am not sure if I need any special permission for that
16:27:08 <markusry> Will we define milestones, i.e., have some way to predict in which release an issue will be fixed?
16:27:09 <kristenc> probably you do.
16:27:17 <kristenc> permission to tag probably implies admin.
16:27:26 <tpepper> we'll need to insure you (and automation eventually?) have perm's to push tags
16:27:33 <mcastelino> kristenc: will the dev get a notification on failed tests or does it go to a separate mailing list
16:27:42 <fuentess> Ok, so I will make some tests today and tomorrow and let you know if I need something
16:27:48 <kristenc> https://developer.github.com/v3/git/tags/
16:27:50 <sameo> kristenc, tpepper: Are we saying that the tag should be done daily by QA ?
16:27:51 <tpepper> gitolite has nuanced levels of permission. I hope in github we can grant just tag push ability
16:28:01 <tpepper> sameo: that's the idea
16:28:13 <kristenc> fuentess: I think you can easily script with curl
16:28:18 <tpepper> final output of successful QA is the tag on the commit from which the testing started
16:28:22 <sameo> tpepper: What if tests do not pass ?
16:28:31 <tpepper> if tests don't pass there's not a release
16:28:36 <tpepper> and not a tag
16:28:39 <kristenc> but if you need any help, I'd be happy to do it.
16:28:45 <sameo> makes sense. Can we document that on the wiki as well ?
16:28:50 <tpepper> yeah
16:28:54 <kristenc> there's one more item to look at.
16:28:57 <tpepper> we need a page for the qa flow
16:29:00 <kristenc> the github "releases"
16:29:07 <kristenc> which create a virtual tarball.
16:29:12 <sameo> #action tpepper to document the qa flow and daily tagging
16:29:17 <mcastelino> we need to put the failure logs somewhere on a failed tagging
16:29:18 <kristenc> and also we need to talk about how changelogs get generated.
16:29:45 <fuentess> kristenc: thanks
16:29:49 <kristenc> as far as I recall - if you setup the github releases stuff right, a tag with a specified format will automatically turn into a release.
16:29:49 <markusry> And whether there is some way to update an issue with the release in which it was fixed
16:29:57 <sameo> tpepper: Does clearlinux have a tool for automated changelogs ?
16:30:01 <kristenc> but you still need to provide a changelog somehow.
16:30:10 <tpepper> sameo: yes
16:30:24 <sameo> tpepper: Could we re-use it ?
16:30:30 <kristenc> I've been reading up on how to do proper changelogs.  There's a lot of people who claim you cannot do good changelogs automatically.
16:30:36 <tpepper> I was thinking...if the "owner" of the changelog file is the automation...
16:30:48 <kristenc> for example - they claim using the short diff of the gitlog is useless and helps nobody
16:30:49 <sameo> #idea Error logs should be stored in a well know place
16:31:03 <tpepper> it could insert a commit editing just the changelog file after the tested commit, and tag the commit which added the changelog file
16:31:21 <sameo> kristenc: I kind of agree.
16:31:25 <tpepper> but then we'd need to rebase any newer commits and non-FF push, which is ugly ugly ugly
16:31:40 <kristenc> sameo: me too.
16:31:43 <kristenc> https://developer.github.com/v3/repos/releases/
16:31:48 <kristenc> there's an api to create releases.
16:31:52 <kristenc> we can automate this too.
16:31:53 <tpepper> maybe the qa tag is preceeded by a branch? with addition of changelog and NEWS file additions
16:31:59 <sameo> tpepper: Do you know what's the logic behind clear tool ?
16:32:06 <kristenc> so we tag, then use the api to do the release automatically if the tests pass.
16:32:23 <kristenc> do I need to put the "link" tag after stuff?
16:32:23 <tpepper> sameo: it's either bash or python that basically does git short log diff'ing
16:32:39 <tpepper> #link https://github.com/01org/ciao/wiki/QA
16:32:52 <kristenc> #link https://developer.github.com/v3/repos/releases/
16:33:06 <kristenc> #link https://developer.github.com/v3/git/tags/
16:33:15 <tpepper> btw I also think the idea of tag preceeded by branch is problematic.  in the short term we're rolling forward fast.  branch implies stable support.
16:33:19 <sameo> tpepper: What's the changelog quality with that tool, in your opinion?
16:33:49 <tpepper> sameo: because they're doing it at the OS level and a couple times a day, it's actually useful.  you get a listing of packages that changed and a short list of changes
16:33:53 <tpepper> or a long list and you get scared
16:33:59 <tpepper> for us I could imagine something like:
16:34:07 <kristenc> one strategy I saw for having humans create and maintain the changelog that seems lightweight is that you make changelog updates part of your merge checklist.
16:34:13 <tpepper> ciao-controller:
16:34:13 <tpepper> foo
16:34:13 <tpepper> bar
16:34:13 <tpepper> ciao-launcher:
16:34:13 <tpepper> baz
16:34:32 <tpepper> that would be a nice log, if foo bar baz were semi well written commit summaries
16:34:36 <kristenc> so - for each pull request, you require a patch to the changelog (if you deem it important enough)
16:34:41 <sameo> kristenc: So the gatekeeper would have to manually create it ?
16:34:48 <sameo> kristenc: Ah, I see.
16:34:49 <kristenc> no - the PR submitter
16:34:54 <sameo> much better.
16:35:00 <tpepper> the problem with auto-git-short-logs is when it gives a list of 242 lines of change.
16:35:12 <sameo> tpepper: I like kristenc's idea.
16:35:19 <kristenc> so - the gatekeeper would evaluate whether a changelog entry was warrented, but not write it.
16:35:26 <kristenc> it would just gate merging if it wasn't done.
16:35:41 <kristenc> you can create a changelog.md file
16:35:55 <kristenc> that the github release process knows about.
16:36:18 <tpepper> I do think it would be nice if the gatekeeper had a tool that pre-generated a candidate changelog entry
16:36:31 <sameo> tpepper: Yes.
16:36:42 <tpepper> but having it part of the PR merge flow is a good way about it
16:37:05 <sameo> #info PRs should include a changelog.md change
16:37:21 <markusry> I need to disconnect I'm afraid.
16:37:25 <sameo> #info release tools to automate final changelog based on changelog.md changes.
16:37:40 <sameo> markusry: no worries, ttyl.
16:37:55 <kristenc> if we agree that we'll require manual changelog entries as part of the merge process, I can update the wiki to add this to our merge checklist.
16:38:05 <sameo> #action Document the requirement for modifying changelog.md as part of any PR.
16:38:11 <tpepper> I think that's good, but I propose two actions there:
16:38:21 <mrkz> kristenc: what about also mention about it on Contribute file?
16:38:28 <sameo> mrkz: Yep.
16:38:49 <kristenc> a good idea.  Or we can make a link in the Contribute file to our wiki so that the submitter can see our list.
16:38:53 <sameo> mrkz: Actually, a lot of what's on the release process wiki should make it to CONTRIBUTING
16:38:56 <tpepper> 1) auto generate short log list, edit if needed, commit to CHANGELOG file
16:38:57 <tpepper> 2) human edit NEWS file with human natural language info on major feature and bug fixes, commit file
16:38:59 <kristenc> that way we don't keep it in 2 places.
16:39:39 <tpepper> CONTRIBUTING.md should be high level imho, with a link to more detailed process (including gatekeeper punch list) on wiki
16:39:44 <kristenc> I personally think "CONTRIBUTING" is a separate thing than our gatekeeper checklist.
16:39:58 <tpepper> exactly
16:39:59 <kristenc> but that submitters would find it useful to see our checklist.
16:40:07 <sameo> kristenc: The "PR should include a changelog change" should be there.
16:40:11 <kristenc> yes.
16:40:14 <sameo> Or at least point to that.
16:40:26 <tpepper> CONTRIBUTING can say "for more information on how we handle PR's, see the wiki describing the full release process and quality assurance"
16:40:37 <kristenc> although - really, the right thing to say is "The PR *may* require a changelog change"
16:40:45 <sameo> #action sameo improve CONTRIBUTING to point to the release process wiki
16:40:46 <kristenc> it's a bit subjective whether it needs one.
16:40:47 <tpepper> but otherwise mostly leave CONTRIBUTING as the steps leading up to a PR
16:41:07 <mcastelino> kristenc: agree. Not all PRs may need changelog change
16:41:24 <kristenc> i think the changelog should be the executive summary
16:41:29 <sameo> #info Not all PRs may need a changelog change
16:41:34 <kristenc> any more detail and they should just read the git log.
16:41:41 <tpepper> I was thinking changelog details and NEWS be summary
16:41:49 <kristenc> where we enforce having excellent commit messages :)
16:41:50 <mrkz> tpepper: I like ^
16:42:01 <tpepper> another very nice thing about a changelog with details is it ends up as a web indexed file
16:42:10 <tpepper> web searches in problem archeaology find it
16:42:25 <tpepper> then you scroll up and learn your issue was probably fixed in release 20170429
16:42:31 <sameo> Ok, that sounds reasonable.
16:42:48 <kristenc> release notes?
16:43:06 <tpepper> that leaves changelog as partly / mostly machine generated and consumed, for cookie crumbs that humans later find
16:43:34 <sameo> So what would be the file we may ask PRs to modify ?
16:43:44 <mrkz> the NEWS file?
16:43:58 <tpepper> could just be in the comment file on the PR?  and the gatekeeper decides
16:44:24 <tpepper> if I say "hey this PR fixes a major issue" the gatekeeper can decide if that's major enough to elevate to NEWS
16:44:42 <sameo> Ok, so we're saying the gatekeeper should manually change NEWS based on PR comments ?
16:44:55 <tpepper> that's what I'm saying
16:45:04 <tpepper> we started with human manually changes CHANGELOG.
16:45:15 <sameo> PR creators, yes.
16:45:36 <tpepper> I propose CHANGELOG as mostly automated.  and gatekeeper doing the manual elevation to NEWS on demand as they merge news-worth PR's
16:45:52 <tpepper> but kristenc raises an interesting meta question.  what are "release notes"?
16:45:55 <kristenc> not sure I'm on board with this.
16:46:02 <sameo> Same here.
16:46:03 <tpepper> do we send email for all of the above?  or not?
16:46:25 <sameo> In that model, NEWS would be release notes, iiuc.
16:46:36 <tpepper> an example I like is:  https://curl.haxx.se/news.html
16:46:46 <kristenc> what is left on the agenda to discuss today?  I wonder if we should start an email thread about this to discuss further.
16:46:47 <tpepper> then click "changelog"  on the 7.49.0 note
16:47:04 <tpepper> https://curl.haxx.se/changes.html#7_49_0  is web indexed and hits on web searches
16:47:19 <sameo> tpepper: I like the idea of having an automated changelog.
16:47:35 <sameo> That would contain basically a --oneline output.
16:47:43 <mcastelino> I like how they have changes separate from bug fixes
16:47:49 <tpepper> qa and single machine setup are still on the agenda.  we can move on and keep refining release process over the coming weeks.
16:48:17 <sameo> #action Move the changelog generation discussion to the mailing list for now
16:48:35 <sameo> We have 12 minutes left, let's talk about QA.
16:48:43 <sameo> #topic QA
16:49:03 <sameo> So I'd like to know if we have our functional testing fully defined ?
16:49:11 <tpepper> fuentess has a bunch of good ideas on it
16:49:13 <fuentess> so I created a document that lists the testing
16:49:24 <tpepper> that needs moved to
16:49:27 <tpepper> #link https://github.com/01org/ciao/wiki/QA
16:49:29 <fuentess> I need to work on it to move it to github
16:49:39 <tpepper> we just discovered he can't edit
16:49:43 <fuentess> but it has some basic scenarios
16:49:59 <tpepper> need to look at  the wiki perm's.  probably in the github model fuentess clones wiki.git, edits pages, commits, does PR?
16:50:00 <sameo> #action fuentess to move the QA document to the wiki
16:50:27 <sameo> tpepper: Not sure if he can do PRs on the wiki.
16:50:32 <tpepper> this is maybe something that needs its own action item...github permissions
16:50:40 <tpepper> it seems we have "maintainer" and "not maintainer"
16:50:53 <tpepper> it's hard for me to believe we'd be that limited
16:51:09 <kristenc> I believe you can grant write permissions to the wiki separately.
16:51:11 <sameo> #action tpepper to check for better github permissions and grant e.g. wiki editing permission.
16:51:29 <kristenc> although perhaps the choice is only "maintainer" and "everyone on the planet"
16:51:52 <sameo> So I think we should discuss fuentess proposal once it's public on the wiki.
16:52:02 <kristenc> agreed.
16:52:04 <fuentess> sameo: sure
16:52:27 <sameo> #info fuentess QA proposal will be discussed next week, once published on the wiki
16:52:48 <sameo> tpepper: Did you want to quickly discuss something else on QA ?
16:53:39 <tpepper> I think we're good
16:54:11 <sameo> #topic single machine setup
16:54:26 <mcastelino> #link https://github.com/01org/ciao/issues/125
16:54:45 <sameo> Then let's move to the single machine setup, as it also relates to the gatekeeping topic
16:54:57 <sameo> mcastelino: What's missing to close that one ?
16:55:12 <mcastelino> scheduler change
16:55:22 <mcastelino> and actually testing it
16:55:27 <sameo> mcastelino: And launcher ?
16:55:43 <mrkz> I can play with it
16:55:51 <mcastelino> I think Mark has implemented it
16:55:52 <tpepper> I _think_ scheduler changes are small and should be done today/tomorrow
16:55:58 <tpepper> we'll all want to test this
16:56:04 <mcastelino> I need to pull in multiple PR's in a branch to test this
16:56:05 <sameo> #info Single VM setup depends on scheduler, launcher changes to be pushed.
16:56:07 <tpepper> it will become our primary workflow
16:56:15 <mcastelino> Also one issue with Travis and AWS
16:56:29 <kristenc> mcastelino: the fake keystone service is just a package, doesn't have a main.  I didn't know how you were doing the all in one setup, but some *thing* will have to create the keystone service.
16:56:30 <mcastelino> they way travis is setup this cannot run natively on travis as I hoped
16:56:36 <sameo> #info scheduler changes to be done by 05/20
16:56:41 <kristenc> I use it in my unit testing for example (controller_test.go)
16:56:54 <mcastelino> You will need to run a VM inside the travis VM which I have not yet tried
16:57:05 <sameo> mcastelino: Travis runs on AWS ?
16:57:21 <mcastelino> I think so... at least the logs comes from S3
16:57:47 <sameo> mcastelino: Are you planning to check if nested VMs work in travis ?
16:57:47 <tpepper> mcastelino: so this is a problem beyond just keystone (with keystone being partly resolved by not actually running a VM and having a dummy provider)
16:58:13 <mcastelino> kristenc: agree.. we need a dummy keystone service
16:58:23 <mcastelino> standalone
16:58:34 <kristenc> mcastelino: do you want me to create a simple go program for that?  where would it live?
16:58:58 <kristenc> I made test-utils in a pull request.
16:59:06 <sameo> kristenc: Maybe as a controller option ?
16:59:06 * kristenc hunts up link
16:59:18 <mcastelino> kristenc: that will work...
16:59:31 <mcastelino> we will need more fake services as we add more external components
16:59:36 <kristenc> #link https://github.com/01org/ciao/pull/139
16:59:41 <mcastelino> so all of them can live there
16:59:51 <kristenc> sameo, build option, or a normal parameter?
16:59:51 <tpepper> yes...we'll end up with a set of fake clients and servers
16:59:52 <sameo> #info We  will need more fake services as we add more external components
17:00:16 <sameo> kristenc: the latter but that actually won'tscale to other components I think
17:00:51 <sameo> #action Prepare for creating a set of fake clients and servers.
17:01:03 <sameo> folks we're running out of time I'm afraid.
17:01:22 <tpepper> one more thing on single machine:
17:01:31 <sameo> We can add the last 2 items to our next week agenda.
17:01:41 <kristenc> sameo: so, do you not want me to add the controller option then till we've thought through this a bit?
17:01:57 <tpepper> if we have special casing to enable it (eg: I will in scheduler), these should use a common runtime parameter, eg --enable-single-machine-dev
17:02:00 <kristenc> we can discuss on the mailing list or just in irc outside the meeting.
17:02:01 <mcastelino> I think all components should have this flag
17:02:07 <sameo> #action sameo single VM and QA to be added to next week agend
17:02:15 <tpepper> I've start populating next agenda
17:02:17 <tpepper> #link https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-05-26
17:02:28 <sameo> thanks.
17:02:33 <mcastelino> no meeting next week I assume
17:02:41 <kristenc> why?
17:02:43 <sameo> mcastelino: Why not ?
17:03:03 <tpepper> a couple of us are planning on learning a new programming language called "Go"
17:03:08 <sameo> kristenc: We can have it as a temporary solution I guess, for closing mcastelino issue asap.
17:03:15 <kristenc> oh darn it - I keep forgetting about that training.
17:03:18 <mcastelino> :)
17:03:25 <sameo> Ah, right.
17:03:31 <kristenc> i can't believe it's all week long.
17:03:46 <sameo> Let's assume we'll have that meeting next week and postpone it if needed.
17:04:10 <sameo> #action AmyLee7 to decide if we have this meeting next week
17:04:13 <tpepper> sounds like a plan
17:04:26 <sameo> Any final opens ?
17:04:29 <tpepper> fyi I'll be semi-mostly-out the week after that
17:04:43 <mrkz> sameo: I'd suggest to move opens at the end of the meeting
17:04:44 <tpepper> I think I'm on a plane for what would be the June 2 meeting time
17:04:55 <mrkz> since those would have variable time consume for the meeting
17:04:58 <sameo> #info tpepper to be out-is first week of June
17:05:13 <sameo> mrkz: Problem with that is we never get time for opens.
17:05:18 <kristenc> yep
17:05:19 <tpepper> mrkz: the way I normally run meetings is we get opens articulted the start of the meeting
17:05:31 <mrkz> I see
17:05:46 <tpepper> and either work them onto the agenda end, or formally allot time in the next agenda, or schedule a side band conversation to get a high priority issue covered
17:06:10 <sameo> All right, I'm going to close this meeting...
17:06:16 <mrkz> please do, thanks!
17:06:27 <sameo> #endmeeting

Weekly Meetings

Development

Architecture

Clone this wiki locally