This repository has been archived by the owner on Jul 16, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 51
Weekly Meeting 2016 06 02
Kristen Carlson Accardi edited this page Jun 2, 2016
·
8 revisions
- opens (5 minutes)
- Release process
- Should we start tagging and releasing next week ?
- Automated Changelog
- Define quality and security standard for imported 3rd party packages
- ciao f2f at linuxcon NA
- bugs (10 minutes): pre-seed a list of new or priority up/down candidates into the agenda for meeting focus
- prioritize
- scrub
- update/assign
Meeting started by sameo_ at 16:02:37 UTC. The full logs are available at ciao-project/2016/ciao-project.2016-06-02-16.02.log.html .
-
LINK: https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-06-02 (sameo_, 16:03:05)
-
opens (sameo_, 16:03:59)
- f2f to be added to the agenda (sameo_, 16:05:42)
- Next nova f2f scheduled in Hillsboro in July (sameo_, 16:06:37)
- ACTION: All concerned people to take a look at Trello (sameo_, 16:07:40)
-
Release process (sameo_, 16:07:58)
- LINK: https://github.com/01org/ciao/wiki/Release-Process (tpepper, 16:08:22)
- tpepper confirms github has no permissions: Need full priv to tag. (sameo_, 16:10:13)
- ACTION: kristenc to work on release scripts (sameo_, 16:10:55)
- IDEA: tpepper proposes to have the scripts in our repo (sameo_, 16:11:22)
- IDEA: kristenc offers to put scripts under ciao-releases. Scripts to be written in go. (sameo_, 16:11:56)
- Golanf FTW ! (sameo_, 16:12:03)
- official daily releases will start once scripts are ready. No other blockers. (sameo_, 16:13:53)
- 2 main reasons for updating vendor packages: 1) functional (API changes, etc...) reasons and 2) security reasons (sameo_, 16:24:36)
- Current quality gates for updating a vendor package: a) ciao unit tests to pass b) functional testing to pass c) security champion review (sameo_, 16:25:50)
- 3 main reasons for updating vendor packages: 1) functional (API changes, etc...) reasons , 2) dependency change and 2) security reasons (sameo_, 16:28:29)
- ACTION: Get MikeL into the meeting (sameo_, 16:28:40)
- ACTION: AmyLee7 to invite MikeL to the meeting (sameo_, 16:28:54)
- Current quality gates for updating a vendor package: a) ciao unit tests to pass b) functional testing to pass (No security review yet) (sameo_, 16:29:27)
- No automatic package update (sameo_, 16:31:28)
- ACTION: markusry to own vendor package updates based on open issues. (sameo_, 16:32:07)
- All used packages together with their dependencies are vendored (sameo_, 16:38:21)
- ACTION: markusry to improve ciao-vendor to run unit tests on vendored package (sameo_, 16:41:16)
- Vendor unit testing results to become a vendor update criteria. (sameo_, 16:42:10)
- LINK: https://github.com/01org/ciao/issues/191 (sameo_, 16:43:51)
- the needed gophercloud package to be discussed in issue #191 (sameo_, 16:44:07)
-
Ciao f2f (sameo_, 16:44:37)
- IDEA: Next Ciao f2f/sprint to be colocated with LinuxCon NA - Toronto - Aug 18-21 (sameo_, 16:45:53)
- IDEA: After linuxcon NA seems better: August 25-28 (sameo_, 16:49:43)
- IDEA: rent a coworking space or a a hotel conf room in Toronto (sameo_, 16:52:08)
- ACTION: AmyLee7 check on booth demo needs (tpepper, 16:54:01)
- ACTION: AmyLee7 to check with Sabrina on conf rooms or coworking space avail. (sameo_, 16:54:33)
- ciao sprint to be publicly announced (ml at least). (sameo_, 16:56:07)
- ACTION: sameo to extend the meeting by 15-20mn for bug scrubbing (sameo_, 16:59:11)
-
bug scrub (sameo_, 16:59:20)
- P1- Stopper- gates a customer, other developer or organization on a critical path. (sameo_, 17:07:03)
- P2- Blocker- significant enough that it gates work that is important for a milestone, either yours or the teams or another team (sameo_, 17:07:11)
- P3- Backlog- should be fixed as, it is important, but not gating (sameo_, 17:07:18)
- P1, P2, P3 and P4 are bug labels only (sameo_, 17:08:00)
- features/enhancements have specific labels (sameo_, 17:08:17)
- bug and feature/enhancement labels are not exclusive (sameo_, 17:08:39)
- P4- Probably won't be fixed, close after a few weeks if not fixed (sameo_, 17:09:03)
- IDEA: monthly releases + release labels to tag features + release named to months (sameo_, 17:28:24)
- ACTION: sameo to edit the wiki with releases and feature labels proposals (sameo_, 17:28:52)
- ACTION: each component owner should tag her/his bugs (sameo_, 17:30:13)
- ACTION: sameo to create Px labels. (sameo_, 17:30:23)
- ACTION: each component owner should tag her/his bugs to really start doing bug scrub next week (ww24) (sameo_, 17:30:56)
Meeting ended at 17:31:59 UTC.
- All concerned people to take a look at Trello
- kristenc to work on release scripts
- Get MikeL into the meeting
- AmyLee7 to invite MikeL to the meeting
- markusry to own vendor package updates based on open issues.
- markusry to improve ciao-vendor to run unit tests on vendored package
- AmyLee7 check on booth demo needs
- AmyLee7 to check with Sabrina on conf rooms or coworking space avail.
- sameo to extend the meeting by 15-20mn for bug scrubbing
- sameo to edit the wiki with releases and feature labels proposals
- each component owner should tag her/his bugs
- sameo to create Px labels.
- each component owner should tag her/his bugs to really start doing bug scrub next week (ww24)
- AmyLee7
- AmyLee7 to invite MikeL to the meeting
- AmyLee7 check on booth demo needs
- AmyLee7 to check with Sabrina on conf rooms or coworking space avail.
- kristenc
- kristenc to work on release scripts
- markusry
- markusry to own vendor package updates based on open issues.
- markusry to improve ciao-vendor to run unit tests on vendored package
-
UNASSIGNED
- All concerned people to take a look at Trello
- Get MikeL into the meeting
- sameo to extend the meeting by 15-20mn for bug scrubbing
- sameo to edit the wiki with releases and feature labels proposals
- each component owner should tag her/his bugs
- sameo to create Px labels.
- each component owner should tag her/his bugs to really start doing bug scrub next week (ww24)
- sameo_ (148)
- kristenc (96)
- tpepper (91)
- markusry (80)
- AmyLee7 (20)
- jvillalo_mobl (8)
- mrkz (3)
- arjan_work (3)
- mcastelino (2)
- ciaomtgbot (2)
- ciaoslackbridge (1)
- chamings (1)
- carlosag (1)
- leoswaldo (1)
Generated by MeetBot_ 0.1.4
.. _MeetBot: http://wiki.debian.org/MeetBot
###Full IRC Log
16:02:37 <sameo_> #startmeeting
16:02:37 <ciaomtgbot> Meeting started Thu Jun 2 16:02:37 2016 UTC. The chair is sameo_. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:37 <ciaomtgbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:02:50 <tpepper> roll call...
16:02:52 <tpepper> o/
16:02:55 <kristenc> hi
16:02:57 <jvillalo_mobl> o/
16:02:58 <chamings> o/
16:02:58 <mrkz> o/
16:03:05 <sameo_> #link https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-06-02
16:03:06 <ciaoslackbridge> <> Pssst! I didn’t unfurl <https://github.com/01org/ciao/wiki/Weekly-Meeting-2016-06-02> because it was already shared in this channel quite recently (within the last hour) and I didn’t want to clutter things up.
16:03:17 <leoswaldo> o/
16:03:25 <kristenc> i need to implement that mute button function for ciaoslackbridge
16:03:26 <sameo_> thanks ciaoslackbridge, I love you too.
16:03:36 <markusry> tppeper: I think it's a bug in test-cases. I'll take a look
16:03:59 <sameo_> #topic opens
16:04:19 <sameo_> hey mcastelino
16:04:20 <markusry> o/
16:04:24 <sameo_> Feeling better ?
16:04:26 <mcastelino> 0/
16:04:26 <carlosag> o/
16:04:27 <kristenc> well, now that mcastelino is here, we can start :).
16:04:32 <sameo_> :)
16:04:38 <sameo_> Anyone has some opens ?
16:04:52 <AmyLee7> yes- can everyone take a look at trello?
16:05:01 <kristenc> right now?
16:05:11 <AmyLee7> no before next week on Monday please
16:05:18 <tpepper> sameo_: I think we should talk about f2f briefly during this meeting
16:05:24 <kristenc> good idea.
16:05:34 <sameo_> tpepper: Yes, let me add that to the agenda
16:05:42 <sameo_> #info f2f to be added to the agenda
16:05:51 <tpepper> (fyi also there's a Nova f2f in July in Hillsboro which I intend to attend)
16:06:16 <kristenc> i recall them discussing that in Austin.
16:06:37 <sameo_> #info Next nova f2f scheduled in Hillsboro in July
16:07:23 <AmyLee7> o/
16:07:40 <sameo_> #action All concerned people to take a look at Trello
16:07:50 <sameo_> Let's move to the next topic then
16:07:58 <sameo_> #topic Release process
16:08:22 <tpepper> #link https://github.com/01org/ciao/wiki/Release-Process
16:08:38 <sameo_> I put 2 questions there: Should we start tagging ? How do we automatically generate changelogs ?
16:08:40 <kristenc> last week we started using the merging process. I was thinking that this week I might work on automating some of the release process, since salvador is busy.
16:09:05 <tpepper> we can definitely write / start using scripting to create tags and changelogs
16:09:17 <kristenc> sameo_, I think yes, we should start tagging even if we don't have the QA reports yet.
16:09:21 <sameo_> kristenc: If we could at least get an automate tagging+changelog, we could start using it.
16:09:28 <tpepper> I had the AR two weeks ago to look at github permissions...they basically have none.
16:09:29 <sameo_> kristenc: I fully agree.
16:09:39 <tpepper> a tag creating entity will need full write priv's on our repo
16:09:49 <kristenc> sameo_, yes. why don't I write some scripts since I've looked a bit into the github api for doing releases.
16:10:09 <kristenc> where should I check in the scripts though? our repo, or a different one? my inclination is a new repo.
16:10:09 <tpepper> plus kristenc has write priv's ;0
16:10:13 <sameo_> #info tpepper confirms github has no permissions: Need full priv to tag.
16:10:20 <sameo_> kristenc: Lovely, thanks.
16:10:48 <tpepper> I like the idea of having the scripts in our repo because they become the release process documentation
16:10:55 <sameo_> #action kristenc to work on release scripts
16:11:01 <sameo_> tpepper: Yep
16:11:05 <kristenc> ok - so how about under the ciao project, we have ciao-releases
16:11:13 <kristenc> i might write the release scripts in go.
16:11:19 <tpepper> :)
16:11:20 <kristenc> because I can.
16:11:22 <sameo_> #idea tpepper proposes to have the scripts in our repo
16:11:30 <sameo_> kristenc: Sounds great.
16:11:56 <sameo_> #idea kristenc offers to put scripts under ciao-releases. Scripts to be written in go.
16:12:03 <sameo_> #info Golanf FTW !
16:12:12 <sameo_> sorry, could not resist.
16:12:23 <tpepper> somebody didn't run misspell on that info tag
16:12:26 <kristenc> it does make doing http GET/POST easy.
16:12:28 <sameo_> haha :)
16:12:39 <sameo_> kristenc: Yep.
16:12:58 <sameo_> kristenc: As soon as you have those ready, we should start doing daily releases.
16:13:27 <kristenc> ok - I am "done" for now looking at Cinder so I'll make this my priority for the next week.
16:13:34 <sameo_> thanks.
16:13:53 <sameo_> #info official daily releases will start once scripts are ready. No other blockers.
16:14:13 <kristenc> 2 items related to release that I'm not sure about.
16:14:35 <kristenc> 1. when do we move our vendored packages
16:14:57 <kristenc> 2. defining quality/standards for vendored packages.
16:15:08 <tpepper> 1. needs it's own process defined
16:15:15 <kristenc> for example, I am going to need us to move to the head of gophercloud for cinder support.
16:15:18 <tpepper> and 1. should include 2.'s answer
16:15:54 <sameo_> kristenc: For the gophercloud example it's fairly easy because there is no choice.
16:16:06 <kristenc> they don't seem to have many tags, do they.
16:16:12 <sameo_> nope.
16:16:31 <markusry> kristenc: Does cinder support bring in a new package?
16:16:31 <sameo_> Last release is from 2014...
16:16:38 <sameo_> markusry: No.
16:16:38 <tpepper> we've got unit testing of our code that uses gophercloud, so if we don't break us, we should be safe to pull it in
16:16:43 <tpepper> do we need more process than that?
16:16:49 <tpepper> that's CI/CD in a nutshell
16:16:54 <sameo_> I agree.
16:16:56 <markusry> I mean new package under rackspace/gophpercloud
16:17:06 <markusry> There are lots of packages under there?
16:17:15 <tpepper> although..I haven't _looked_ at our coverage and presume we have meaningful coverage of the gophercloud usage
16:17:40 <kristenc> markusry, I believe so.
16:18:01 <sameo_> kristenc: Is cinder v2 a different package than v1 ?
16:18:05 <kristenc> although - they may have made cinder part of the service client package.
16:18:25 <kristenc> sameo: it's in a different subdir - I don't know if that is a different package.
16:18:38 <sameo_> kristenc: It seems both are under the 'volumes' package
16:18:53 <kristenc> our CI doesn't currently try to go get updated packages and test them.
16:18:56 <sameo_> tpepper: Good point. I'm not sure about that.
16:19:12 <kristenc> so do we need a separate thing that does that, and how often do we use it?
16:19:41 <markusry> Right now it wouldn't build
16:19:48 <markusry> docker api breaks
16:20:03 * kristenc grumbles about docker
16:20:04 <markusry> I'm not sure there's much point in doing this on a regular basis
16:20:28 <kristenc> the security people claimed that we should be doing this more often than every few weeks.
16:20:37 <sameo_> markusry: Do you suggest we update vendor packages only when needed, on a per package base ?
16:21:16 <kristenc> of course, their basic assumption is that security bugs are getting fixed, not introduced.
16:21:17 <mcastelino> markusry: question on docker API... how much latency will we introduce or features will we loose if we invoke docker using the CLI vs the API?
16:21:17 <markusry> Well, I'd sort of like to update them when we do a major release.
16:21:24 <markusry> Not just a daily release.
16:21:27 <sameo_> kristenc: I guess we'd need a solid functional testing story for doing that.
16:21:39 <kristenc> markusry, we aren't doing any major releases any time soon.
16:21:48 <kristenc> it will be months probably.
16:21:55 <markusry> I was just typing that question
16:21:57 <tpepper> kristenc: the security people need to look at if/how CVE's are published for random github golang vendor library code
16:22:21 <AmyLee7> Is Mike our security champion?
16:22:42 <markusry> So we could do it when we need to for functional reasons and when there is a security issue
16:22:44 <tpepper> yeah
16:23:01 <tpepper> we should invite mike here
16:23:06 <kristenc> seems like a good idea. we just need a way to know when there are security issues.
16:23:25 <tpepper> and give him an action to tell us how we know there's a sec issue in a vendored package so we can pull in a fixed ver
16:23:40 <kristenc> hurray! great idea. make Mikey do it.
16:23:59 <sameo_> Ok, let me summarize:
16:24:36 <sameo_> #info 2 main reasons for updating vendor packages: 1) functional (API changes, etc...) reasons and 2) security reasons
16:24:36 <markusry> mcastelino: Yes we could do this to reduce our dependencies. We'd need to rewrite a lot of code though.
16:25:21 <markusry> And we may have file handle limit issues
16:25:35 <markusry> Although I could control this
16:25:50 <sameo_> #info Current quality gates for updating a vendor package: a) ciao unit tests to pass b) functional testing to pass c) security champion review
16:26:07 <sameo_> markusry, kristenc, tpepper: Do we agree with the security champion part ?
16:26:27 <tpepper> i'm not sure
16:26:27 <sameo_> mcastelino: calling into the CLI sounds a bit hackish to me...
16:26:30 <markusry> d) update required by another dependency that we are updating
16:27:05 <sameo_> markusry: That would be the justification for update, not the quality gate ?
16:27:06 <kristenc> sameo_, in principle, but in practice I'm not sure if that will be something they have bandwidth for and it will slow us down waiting for them.
16:27:08 <markusry> sameo_: How much time would that take and what will they do?
16:27:13 <tpepper> sameo_: I think we need automation that watches for CVEs and tells us. If it's a human who does some review at major or minor releases and declares they've noticed some CVE for which we should bumb a vendor'd lib...that sounds painful.
16:27:28 <kristenc> sameo: I was just going to express my discomfort at calling the docker cli directly.
16:27:48 <sameo_> Ok, so we're saying only unit + functional testing passing ?
16:28:12 <tpepper> we should get Mike's opinion
16:28:15 <tpepper> and action plan ;0
16:28:23 <kristenc> sameo_, maybe for now? I think we need to have Mike help us define how we deal with security aspects.
16:28:24 <tpepper> his opinion will be update anytime there's an issue
16:28:29 <sameo_> #info 3 main reasons for updating vendor packages: 1) functional (API changes, etc...) reasons , 2) dependency change and 2) security reasons
16:28:34 <tpepper> the action plan for that....is harder
16:28:40 <sameo_> #action Get MikeL into the meeting
16:28:47 <tpepper> I pinged him
16:28:54 <sameo_> #action AmyLee7 to invite MikeL to the meeting
16:28:54 <tpepper> might not be online yet
16:29:27 <sameo_> #info Current quality gates for updating a vendor package: a) ciao unit tests to pass b) functional testing to pass (No security review yet)
16:29:54 <sameo_> kristenc: Does that answer your 2 items ?
16:30:47 <kristenc> just want to clarify a process detail. So we'll file an issue when we want a package updated. other than that, there's no automatic update.
16:30:58 <sameo_> kristenc: Agreed.
16:31:08 <tpepper> agree
16:31:23 <kristenc> ok - i have filed one already to update gophercloud and I assigned it to mark. are we making mark in charge of this?
16:31:28 <sameo_> #info No automatic package update
16:31:38 <sameo_> markusry: Do you want to own this ?
16:31:40 <tpepper> markusry: is the vendoring guru
16:31:47 <markusry> Yes. Makes sense
16:32:07 <sameo_> #action markusry to own vendor package updates based on open issues.
16:32:08 <markusry> regarding unit tests, we should only require that tests pass for the packages we actually use
16:32:10 <sameo_> markusry: thanks.
16:32:28 <markusry> So if you look at gophercloud there's tons of packages in there.
16:32:33 <markusry> But we only use a small subset
16:33:04 <markusry> So I'm not sure it makes sense to block an dependency update when an unused package in the same repo fails its tests
16:33:14 <markusry> if that makes sense
16:33:40 <markusry> The failing code doesn't even get vendored
16:33:47 <sameo_> It does. otoh a package failing its tests upstream would be a really bad quality sign..
16:33:52 <markusry> if it's not used.
16:34:12 <markusry> That's true but if you look at some of the docker repos. They're huge
16:34:20 <markusry> We only use a tiny proportion of them
16:35:06 <markusry> github.com/01org/ciao/vendor/github.com/docker/distribution/uuid for example
16:35:09 <sameo_> markusry: So you're proposing we only vendor the fraction of packages we use ?
16:35:25 <markusry> That's what we already do
16:35:37 <markusry> Fraction of the repos
16:35:39 <markusry> Not the packages
16:35:45 <sameo_> But we vendor gophercloud entirely for example ?
16:35:50 <markusry> No
16:36:10 <sameo_> Oh, ok...I thought we vendor the whole thing.
16:36:26 <markusry> No we can't
16:36:35 <markusry> Otherwise the wildcards would break
16:36:41 <sameo_> Do we detect if the vendored packages depend on non vendored ones ?
16:36:49 <markusry> doing go install ./... would build everything, including docker
16:36:54 <markusry> Yes
16:37:03 <markusry> ciao-vendor check
16:37:10 <sameo_> And so we vendor the entire dependency chain ?
16:37:17 <markusry> Yes
16:37:22 <sameo_> Nice.
16:37:45 <tpepper> we have to
16:37:53 <sameo_> markusry: So what was your concern here ?
16:38:21 <sameo_> #info All used packages together with their dependencies are vendored
16:38:26 <tpepper> markusry: that we get specific bits like "github.com/docker/distribution/uuid" instead of "github.com/docker" ?
16:38:39 <markusry> For example, this is all we use from gophercloud
16:38:40 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud
16:38:40 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/openstack
16:38:40 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/openstack/identity/v2/tenants
16:38:40 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/openstack/identity/v2/tokens
16:38:40 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/openstack/identity/v3/tokens
16:38:42 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/openstack/utils
16:38:44 <markusry> github.com/01org/ciao/vendor/github.com/rackspace/gophercloud/pagination
16:38:57 <markusry> tpepper: Yes
16:39:22 <sameo_> markusry: Why is that an issue ?
16:39:51 <markusry> gophercloud has 169 packages. We only use and copy 7 right now
16:40:11 <sameo_> That's a good thing :)
16:40:19 <markusry> So the issue was, a unit test failure in github.com/rackspace/gophercloud/rackspace/orchestration/v1/buildinfo which we do not use
16:40:25 <markusry> should not stop us updating
16:40:38 <markusry> The seven packages listed above which we do
16:40:38 <sameo_> Got you. And I agree.
16:40:47 <markusry> I can add this into ciao-vendor
16:40:58 <markusry> to run unit tests on vendored packages
16:41:16 <sameo_> #action markusry to improve ciao-vendor to run unit tests on vendored package
16:41:58 <tpepper> nice
16:42:10 <sameo_> #info Vendor unit testing results to become a vendor update criteria.
16:42:18 <kristenc> sounds like I need to confirm that you are pulling in the gophercloud package I need.
16:42:25 <kristenc> I'll put it in the issue if you aren't.
16:42:36 <markusry> kristenc: We'll need to discuss later.
16:42:44 <sameo_> kristenc: We're not pulling it currently.
16:42:45 <markusry> basically, ciao-vendor won't pull it in if it's not used
16:43:10 <kristenc> ok - I'll specify the one I need and we can discuss in the issue.
16:43:27 <markusry> kristenc: Okay
16:43:51 <sameo_> #link https://github.com/01org/ciao/issues/191
16:44:07 <sameo_> #info the needed gophercloud package to be discussed in issue #191
16:44:21 <sameo_> Let's move to the next topic as we're running out of time...
16:44:37 <sameo_> #topic Ciao f2f
16:45:06 <sameo_> So we're thinking of having a Ciao f2f and sprint right before LinuxCon NA
16:45:10 <tpepper> yesterday we got to discussing one, maybe colocated with LinuxCon NA in Toronto
16:45:38 <tpepper> something like Aug. 18 - 21 or so
16:45:49 <tpepper> linuxcon is aug 22-24
16:45:53 <sameo_> #idea Next Ciao f2f/sprint to be colocated with LinuxCon NA - Toronto - Aug 18-21
16:46:06 <sameo_> markusry, mcastelino: Would that work for you ?
16:46:09 <kristenc> the more I think about having a sprint in a hotel the more I like it. it's hard to put in 12 hour days when you are still going home at night. family obligations seem to stay. if we do this before linuxcon, we just have to drag ourselves up to a hotel room to sleep.
16:46:15 <markusry> sameo_: Actually it's not great
16:46:29 <markusry> It conflicts with the golang uk conference I was hoping to attend
16:46:36 <markusry> It's also school holidays.
16:46:49 <tpepper> we could also do just after linuxcon? 25-28?
16:46:59 <kristenc> which are the no good days?
16:48:13 <markusry> After linux con should be okay for me
16:48:31 <tpepper> that can work for me
16:48:47 <kristenc> so my theory was that 3 days was the minimum we needed to get a decent amount of work accomplished. what do you all think?
16:49:02 <tpepper> I agree
16:49:02 <kristenc> after is ok with me too.
16:49:03 <markusry> Agreed.
16:49:04 <sameo_> kristenc: 3 days is the bare minimum, yes.
16:49:16 <kristenc> we did 5 in London and were busy the entire time.
16:49:35 <tpepper> depending on what all is happening at the conference Mon-Wed, I see a number of us actually doing a lot of hacking then too
16:49:43 <sameo_> #idea _After_ linuxcon NA seems better: August 25-28
16:49:53 <kristenc> are they going to have a ciao demo in the booth at linuxcon?
16:49:54 <markusry> So 27-28 is a weekend. Not a problem for me, but just wanted to point this out.
16:50:01 <markusry> Might even be better for me in fact.
16:50:11 <sameo_> Same here.
16:50:15 <kristenc> its ok with me to work over the weekend for the sprint.
16:50:30 <sameo_> kristenc: I don't know. AmyLee7 might know
16:50:42 <markusry> Would we be able to get into the office?
16:50:52 <kristenc> i would like to be home by the 31st though - that is my anniversary :).
16:51:09 <sameo_> markusry: The Toronto office ?
16:51:18 <AmyLee7> I think its ok to work over the weekend but we would want to add in at least a half day break
16:51:21 <kristenc> do we need an office?
16:51:21 <AmyLee7> let me chack on it
16:51:26 <markusry> Ah, it would be in Toronto even if it's after LinuxCon
16:51:27 <tpepper> we don't need an office
16:51:36 <tpepper> we can find a coworking space probably though
16:51:45 <kristenc> we'd do ok with a hotel room in a pinch.
16:51:45 <tpepper> or something at the hotel/conf possibly
16:51:56 <markusry> Sounds good.
16:52:08 <sameo_> #idea rent a coworking space or a a hotel conf room in Toronto
16:52:09 <tpepper> Toronto's a hipster town..there must be coworking spaces
16:52:25 <kristenc> i know the hotel will give you a conference room
16:52:42 <kristenc> just not sure how booked out it's going to be with all the other events colocated with linuxcon.
16:53:31 <sameo_> AmyLee7: Could you start checking that we could potentially get a conference room at the hotel ?
16:53:55 <AmyLee7> yes
16:53:56 <kristenc> or maybe a hotel suite with a living room like thing.
16:54:00 <AmyLee7> I will work with Sabrina on that
16:54:01 <tpepper> #action AmyLee7 check on booth demo needs
16:54:18 <AmyLee7> and look into co-working spaces and conference rooms for the ciaocon
16:54:33 <sameo_> #action AmyLee7 to check with Sabrina on conf rooms or coworking space avail.
16:54:52 <kristenc> question: should we invite the world to attend our sprint (likely nobody will... but it's a gesture)
16:55:09 <sameo_> kristenc: We should announce it on the ml at least.
16:55:18 <markusry> So after Linuxcon sounds good. I'll just need to double check a few things first though. Can I confirm tomorrow?
16:55:26 <sameo_> markusry: Sure.
16:55:35 <kristenc> probably we need to make sure we'll get budget approved?
16:55:48 <tpepper> yeah there's that too
16:56:07 <sameo_> #info ciao sprint to be publicly announced (ml at least).
16:56:36 <sameo_> yep, this is all hypothetical at the moment... But we can't ask for a budget without a plan and schedule.
16:56:59 <sameo_> All right folks, we have 4 minutes left, and one topic.
16:57:16 * kristenc guesses we won't get to bug scrubs again this week.
16:57:40 <kristenc> do we need to extend the meeting for 20 minutes for bug scrubbing?
16:57:52 <AmyLee7> yes I think so
16:58:09 <sameo_> kristenc: fine with me.
16:58:10 <kristenc> maybe we should always plan on 10:00 - 10:20 for that.
16:58:12 <AmyLee7> or we can do a quick 20 min meeting at the bgn of the week as a bug scrub
16:58:24 <kristenc> I'd rather just get it done after this one.
16:58:31 <tpepper> yeah I vote for this week
16:58:35 <sameo_> yep.
16:59:08 <AmyLee7> ok
16:59:11 <sameo_> #action sameo to extend the meeting by 15-20mn for bug scrubbing
16:59:20 <sameo_> #topic bug scrub
16:59:31 <AmyLee7> Manohar and I have a conflict 10-11 today with NPG team
16:59:33 <AmyLee7> so need to drop
17:00:14 <AmyLee7> I have a few suggestions with Kent and Abe's input on bug priority definitions
17:00:20 <AmyLee7> P1- Stopper- gates a customer, other developer or organization on a critical path.
17:00:20 <AmyLee7> P2- Blocker- significant enough that it gates work that is important for a milestone, either yours or the teams or another team
17:00:20 <AmyLee7> P3- Backlog- should be fixed as, it is important, but not gating
17:00:20 <AmyLee7> P4- Probably won't be fixed, close after a few weeks if not fixed
17:00:43 <AmyLee7> these are just ideas and will let you all discuss
17:00:56 <jvillalo_mobl> Need to drop guys
17:00:58 <tpepper> is the idea that we'd tag github issues with "Pn" strings?
17:01:10 <sameo_> tpepper: We need to decide that here.
17:01:11 <tpepper> or label rather. github label the issues.
17:01:14 <kristenc> or maybe trello does this for us?
17:01:40 <sameo_> kristenc: will trello translate that into a github label ?
17:02:22 <tpepper> we'll have to experiment
17:02:23 <kristenc> i don't know. I've never used trello.
17:02:28 <jvillalo_mobl> I think trello actually does that, I have used it before
17:02:29 <sameo_> I'm thinking about people looking at our github and trying to understand what are our main issues.
17:02:33 <tpepper> I've never used it for antyhing like this
17:02:35 <jvillalo_mobl> it uses labels
17:02:38 <kristenc> we should probably play with it.
17:02:38 <markusry> Amy mentioned that github integration might only come with the paid version
17:02:50 <kristenc> hum.
17:02:51 <markusry> So we mightn't be able to experiment right now
17:02:54 * kristenc googles.
17:02:55 <sameo_> jvillalo_mobl: Can it create labels on github ?
17:02:56 <jvillalo_mobl> Trello is free for opensource projects I think
17:03:15 <sameo_> jvillalo_mobl: The integration with github is not free though.
17:03:19 <tpepper> should we just action that experimentation for the next days and move to the actual scrub?
17:03:22 <jvillalo_mobl> sameo: Not sure if it can, but labels can be created by project mantainers and trello can use them
17:04:09 <jvillalo_mobl> right forgot about that detail..
17:04:10 <sameo_> So we'd end up potentially creating bug labels from both trello and github ?
17:04:12 <kristenc> seems possible that the github integration is only available for the business version. weird.
17:04:32 <tpepper> people gotta make money somehow
17:04:46 <kristenc> i guess that's true. it's going to make it hard to experiment.
17:04:54 <kristenc> to see if it meeets your needs.
17:05:04 <sameo_> Indeed.
17:05:04 <kristenc> i wish they had a 30 day trial period or something.
17:05:49 <kristenc> well - let's add the priorities the only way we can for now. labels.
17:06:09 <jvillalo_mobl> really need to drop guys, btw on webui we already use "high" and "medium" labels like p1 and p2
17:06:13 <tpepper> we can experiment on the free ver and see what we see
17:06:13 <sameo_> Yep. Do we agree with AmyLee7 proposal ?
17:06:24 <markusry> Yes, looks good to me
17:06:32 <kristenc> yes.
17:06:38 <tpepper> I'm not passionate about the numbers. they usually end up arbitrary. so "yes"
17:06:42 <markusry> Right now we have some issues marked as bugs and some as enhancements
17:07:02 <kristenc> what they mean to me is that if you have a P1, it should be the only thing you are working on.
17:07:03 <sameo_> #info P1- Stopper- gates a customer, other developer or organization on a critical path.
17:07:09 <markusry> I guess these numbers are for bugs only
17:07:11 <sameo_> #info P2- Blocker- significant enough that it gates work that is important for a milestone, either yours or the teams or another team
17:07:18 <sameo_> #info P3- Backlog- should be fixed as, it is important, but not gating
17:07:23 <sameo_> P4- Probably won't be fixed, close after a few weeks if not fixed
17:07:28 <tpepper> I take these as bug only, not feature
17:07:30 <kristenc> if you have a P2 - you could possibly balance what you are doing with feature addition/enhancements if you had a good reason.
17:08:00 <sameo_> #info P1, P2, P3 and P4 are bug labels only
17:08:17 <sameo_> #info features/enhancements have specific labels
17:08:32 <sameo_> #bug and feature/enhancement labels are not exclusive
17:08:33 <kristenc> how do we prioritize features/enhancements?
17:08:39 <sameo_> #info bug and feature/enhancement labels are not exclusive
17:08:43 <mrkz> sameo_: I think you missed the info tag for the p4 to make it into the minutes
17:09:03 <sameo_> #info P4- Probably won't be fixed, close after a few weeks if not fixed
17:09:06 <sameo_> mrkz: Thx
17:09:08 <tpepper> p4's the one that doesn't matter anyway...
17:09:09 <tpepper> :)
17:09:26 <kristenc> p4 is usually the "document and close" priority.
17:09:56 <sameo_> kristenc: I guess a feature/enhancement that's blocking will come with a P* label ?
17:10:15 <tpepper> i'd rather see delivery dates than P's
17:10:31 <tpepper> either a date and it's happening, or no date and it's not in plan currently
17:10:46 <sameo_> So a milestone ?
17:10:47 <kristenc> features show up when someone submits a patch.
17:10:58 <kristenc> and they either make it or they don't.
17:11:09 <tpepper> the P's would be about giving people a sense of if a patch is coming
17:11:10 <kristenc> since we are doing time based releases.
17:11:17 <tpepper> same for a target date, except it's more concrete
17:11:50 <sameo_> kristenc: But you may want to track a future feature that you have zero code for ?
17:11:53 <tpepper> could also just a "process" to keep your enhancement ticket up to date with text describing progress and when you might submit a patch
17:12:36 <kristenc> sameo_, what's the goal with tracking the feature.
17:12:47 <markusry> Be back in a minute
17:12:56 <sameo_> kristenc: planning
17:13:16 <tpepper> imho tracking features gives us a way to manage resource allocations, and users a way to manage expectations of us delivering
17:13:18 <sameo_> kristenc, tpepper: Maybe we could tag features with a future version label ?
17:13:50 <tpepper> sameo_: I agree. it's either soon-ish (1-2Q's) with reasonable confidence, or "future-enhancement"
17:14:03 <sameo_> so feature A gets labeled with 'v0.5' meaning we plan to integrate it with that version.
17:14:14 <kristenc> maybe instead of target version you need to do a target date.
17:14:29 <tpepper> I agree with kristenc
17:14:45 <sameo_> Can github do that ?
17:14:47 <kristenc> if you plan to have a feature done by October - then you put that in rather than the release.
17:15:00 <tpepper> I'd do "enhancement" label with target date label, else label it is "future-enhancement"
17:15:28 <markusry> I'm back
17:15:33 <tpepper> eg: label's "enhancement" and "2016-10-31", else label "future-enhancement"
17:15:52 <sameo_> tpepper: So you'd create a label for each potential new date ?
17:16:05 <kristenc> I was thinking we should just do quarterly labels.
17:16:08 <tpepper> or could be "targetdate-2016-10-31" and "targetdate-future"
17:16:19 <tpepper> I'm ok with quarters
17:16:27 <tpepper> would like months more
17:16:30 <markusry> Maybe we need to see what Trello will do for us before we decide.
17:16:32 <tpepper> don't need day
17:16:34 <sameo_> kristenc: That's almost like version labels if we do time based releases.
17:17:13 <kristenc> well - we do nightly releases. so the quarterly label just says that we'll aim for getting the feature done sometime in Qx
17:17:52 <kristenc> its more likely having a quarterly objective :).
17:18:56 <tpepper> yes. my only concern is that boss talky people and users have a sense of the objectives. and complain if they'd like them altered.
17:18:58 <sameo_> So the problem I see with adding time labels to features is that it won't allow people to know which ciao major release they should use if they want features A,B and C.
17:19:22 <kristenc> sameo: aren't we putting that in the release notes?
17:19:23 <sameo_> Or not easily at least.
17:19:29 <tpepper> we can close the feature with a lable indicating the major release inwhich it was included
17:19:36 <markusry> So the go project uses version milestones
17:19:42 <markusry> But they have two releases a year
17:20:00 <kristenc> github will show you when it was merged.
17:20:04 <kristenc> that should be enough.
17:20:06 <markusry> And the releases general fall every 6 months
17:20:08 <tpepper> could label with "released-in-vX.YY"
17:20:17 <kristenc> plus the release notes will document the pull request.
17:20:24 <markusry> So if you see an issue with a 1.7 label, you know if will be fixed in July.
17:20:43 <sameo_> markusry: That's what I'm proposing.
17:21:18 <sameo_> tpepper: That's assuming we manually label an issue we just fixed.
17:21:28 <markusry> sameo_: Sounds good to me. Give us a bit of flexibility and github can cope with it.
17:21:48 <sameo_> kristenc and tpepper disagree though.
17:21:57 <tpepper> sameo_: I was imagining at the release time. the things it included get marked as included.
17:22:04 <tpepper> that's the agile deferred commitment mindset
17:22:27 <kristenc> i am not quite on board - it's true.
17:22:29 <tpepper> instead of committing we'll have a thing called 1.7 and that it will be in July and that it will include X, Y, and Z. which effectively means we're waterfall.
17:22:43 <tpepper> we'll have a major release when we have one
17:22:47 <tpepper> and it will include what it included
17:22:59 <sameo_> tpepper: Yes, absolutely.
17:23:03 <kristenc> we really haven't talked about doing monthly releases, and we keep throwing around the term "major release" and I don't even know what it is yet.
17:23:13 <sameo_> tpepper: labels are just planned features for a given release.
17:23:21 <sameo_> we re-label if they could not make it.
17:23:41 <sameo_> kristenc: That's right.
17:23:43 <tpepper> I'm ok with that if we're going to do a monthly release
17:23:45 * mrkz has to drop
17:24:23 <tpepper> and I'm ok doing a monthly release
17:25:02 <tpepper> (I'm going to have to drop soon)
17:25:18 <sameo_> Ok. So _if_ we do monthly releases, we can have release labels to stick to features.
17:25:26 <sameo_> kristenc: What do you say ?
17:26:34 <arjan_work> or we can just name our releases to months
17:26:36 <arjan_work> and just schedule time
17:26:41 <arjan_work> and keep things simple
17:26:46 <kristenc> sameo: ok - I suppose we are spending too much time thinking about this. we can always change our minds - release process is an evolution.
17:27:04 <kristenc> we aren't carving this into a rock on a mountain.
17:27:10 <tpepper> yep
17:27:17 <sameo_> true.
17:27:28 <sameo_> Let me log that as ideas...
17:27:40 <kristenc> sameo_, why don't you edit the wiki with what you think should happen, we'll try it and see how it works for us.
17:28:07 <tpepper> were we going to do an actual bug scrub in the extended meeting time?
17:28:19 <kristenc> heh. that was my original thought :).
17:28:24 <sameo_> #idea monthly releases + release labels to tag features + release named to months
17:28:27 <sameo_> kristenc: Will do
17:28:52 <sameo_> #action sameo to edit the wiki with releases and feature labels proposals
17:29:05 <sameo_> tpepper, kristenc: I have to leave as well now, unfortunately.
17:29:23 <tpepper> we can each informally scrub bugs this week?
17:29:27 <sameo_> 7.30pm in my part of the world.
17:29:39 <tpepper> and crack the agenda whip better next week
17:29:39 <kristenc> we should each go tag the bugs in our own component.
17:29:46 <kristenc> with Px
17:29:52 <tpepper> yes
17:29:57 <sameo_> kristenc, tpepper: good idea
17:30:13 <sameo_> #action each component owner should tag her/his bugs
17:30:23 <sameo_> #action sameo to create Px labels.
17:30:56 <sameo_> #action each component owner should tag her/his bugs to really start doing bug scrub next week (ww24)
17:31:38 <tpepper> o/ (departing)
17:31:40 <sameo_> If we don't have any further opens, I'll call it a meeting.
17:31:51 <kristenc> even if we do :)
Development
Architecture