16:01:00 <adrian_otto> #startmeeting Solum Team Meeting
16:01:02 <openstack> Meeting started Tue Nov 26 16:01:00 2013 UTC and is due to finish in 60 minutes.  The chair is adrian_otto. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:05 <openstack> The meeting name has been set to 'solum_team_meeting'
16:02:12 * samkottler waves
16:02:50 <adrian_otto> #topic Roll Call
16:02:54 <russellb> o/
16:02:55 <kraman2> here
16:02:55 <briancline> o/
16:02:57 <tomblank> Tom Blankenship, Rackspace
16:02:57 <claytonc> o/
16:02:57 <adrian_otto> hello everyone
16:03:01 <RoshanAgr> Roshan Agrawal, Rackspace
16:03:03 * samkottler is here
16:03:07 * funzo is here
16:03:16 <tdeckers> Tom Deckers, Cisco... new guy
16:03:16 <coolsvap> Swapnil Kulkarni
16:03:28 <muralia> Murali Allada, Rackspace
16:03:29 <funzo> hey tdeckers, welcome
16:03:32 * russellb doesn't think corporate affiliations are important in this context, fwiw
16:03:33 <RoshanAgr> welcome Tom
16:03:36 <jwforres> Jessica here
16:03:47 <paulmo> Paul Montgomery, Rackspace
16:03:59 * briancline also a new guy, at least for this project
16:04:06 <brents> Brent Smithurst, ActiveState
16:04:07 <devkulkarni> Devdatta Kulkarni, Rackspace
16:04:15 <adrian_otto> welcome newcomers!
16:04:53 <paulczar> Paul Czarkowski, Rackspace
16:04:56 <rajdeep> hi
16:05:07 <aratim> Arati Mahimane, Rackspace
16:05:11 <russellb> sigh
16:05:18 <rajdeep> Rajdeep Dua, VMware
16:05:44 <adrian_otto> #link https://wiki.openstack.org/wiki/Meetings/Solum our agenda for today
16:06:07 <devkulkarni> whoa.. lots of items
16:06:10 <adrian_otto> #Topic Announcements
16:06:23 <adrian_otto> need to move quickly to get through this monster agenda
16:06:28 <adrian_otto> 1) Working Groups
16:06:34 <adrian_otto> We have arranged two working groups:
16:06:41 <adrian_otto> A) Language Pack Working Group
16:06:46 <adrian_otto> Subscribe to https://blueprints.launchpad.net/solum/+spec/lang-pack to join it.
16:06:55 <adrian_otto> (we can make a LP team for this as needed)
16:07:03 <adrian_otto> Participate in the Doodle poll to schedule the meeting series: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Language_Pack_Working_Group_Series
16:07:03 <russellb> i'm a little concerned about the sizes of these groups and the impact it may make on getting something done ASAP
16:07:24 <russellb> i'd almost rather just one person go off and make a strawman proposal
16:07:28 <russellb> and we beat it up on the mailing list
16:07:38 <adrian_otto> russellb: we should do that too
16:07:43 <russellb> instead of limiting progress to a meeting once a week
16:07:44 <kraman2> russellb: +1
16:08:03 <adrian_otto> I think it's importatnt to source input from the full group, but not all of us are expected to generate code
16:08:14 <adrian_otto> B) Git Integration Working Group
16:08:21 <adrian_otto> Subscribe to https://blueprints.launchpad.net/solum/+spec/git-integration to join it.
16:08:21 <russellb> design by committee :)
16:08:21 <adrian_otto> Participate in the Doodle poll to schedule the meeting series: https://wiki.openstack.org/wiki/Solum/BreakoutMeetings#Git_Integration_Working_Group_Series
16:08:29 <claytonc> for the language-pack working group i have not seen feedback via the ML, I would expect people who are interested to be responding already
16:08:36 <adrian_otto> let's try a few things and see what works best
16:08:49 <adrian_otto> #topic Review action items from prior meeting
16:08:57 <adrian_otto> aotto: Schedule breakout meetings for new working groups
16:08:57 <adrian_otto> (in progress, Doodle polls mentioned above)
16:09:07 <adrian_otto> #topic Review of Solum SFO Community Workshop
16:09:15 <adrian_otto> https://etherpad.openstack.org/p/SolumSFOCommunityWorkshop
16:09:21 <adrian_otto> Roshan Agrawal: Report number of attendees, companies represented, format, lessons learned, and next steps.
16:09:21 <adrian_otto> For remote participants: Are there improvements we could make for next time?
16:09:34 <adrian_otto> let's wait for Roshan first
16:09:35 <RoshanAgr> We had 35 attendees in person
16:09:48 <RoshanAgr> and another 25 joined remotely
16:09:55 <RoshanAgr> All in all, heavy participation
16:10:03 <russellb> now we need code from all these people :)
16:10:20 <RoshanAgr> russellb: yes sure :-)
16:10:32 <adrian_otto> for those who have not been watching the Gerrit system, we have good velocity in terms of patches
16:10:47 <adrian_otto> keep up the great participation in terms of code reviews
16:10:58 <RoshanAgr> Any feedback from participants on the structure of the workshop?
16:11:10 <RoshanAgr> My sense is that it went really well
16:11:22 <coolsvap> adrian_otto, RoshanAgr : The arrangement was very nice, hangout helped a lot to be involved, the timing could be a concern for some :) but i guess it can be followed for future workshops
16:11:23 <RoshanAgr> We worked thorugh several design topics
16:11:39 <adrian_otto> we got positive remarks from a bunch of you, but are really seeking ways to improve for next time, so if you have criticism, and don't want to voice it here, please catch me or Roshan on PM
16:12:24 <RoshanAgr> We have etherpad notes from the workshop - we should file them/reference them for further discussions on the topics discussed
16:12:29 <adrian_otto> did the Remote attendees all feel like they were able to follow?
16:12:49 <briancline> agreed on what coolsvap mentioned regarding timing
16:13:25 <russellb> hangout worked well, i just had a lot of conflicts
16:13:25 <briancline> by any chance was it able to be recorded?
16:13:44 <russellb> briancline: probably a better use of time to just review the notes
16:13:45 <RoshanAgr> We have notes: https://etherpad.openstack.org/p/SolumWorkshopTrack1Notes
16:13:55 <adrian_otto> briancline: good suggestion, we will see about doing that next time
16:14:00 <russellb> and start ML threads on anything that needs more discussion
16:14:09 <claytonc> In terms of pure productive output it likely was extremely valuable for driving consensus on a few core topics
16:14:11 <adrian_otto> russellb: yes
16:14:21 <claytonc> forcing people to yay/nay items
16:14:22 <briancline> RoshanAgr: thanks
16:14:26 <adrian_otto> How frequently should we schedule these events? In-Person? Virtual?
16:14:44 <RoshanAgr> briancline: welcome
16:14:48 <funzo> virtual is much easier on budgets
16:14:49 <claytonc> no more than every 4 months
16:14:52 <adrian_otto> most of us are attending ODS on 6 month intervals
16:15:06 <claytonc> post ODS is potentially a good option
16:15:10 <RoshanAgr> how about every 3 months
16:15:16 <RoshanAgr> right in the middle of two ODS
16:15:18 <russellb> every 3 is pretty aggressive
16:15:19 <claytonc> it lets us absorb other teams stuff and then bring it back to a targetted discussion
16:15:24 <briancline> what about a combination of both, except a traveling circus? for instance an Austin office for a subsequent venue
16:15:27 <claytonc> i believe other teams are suggesting that
16:15:40 <briancline> that is, unless most participants are in the bay area
16:15:56 <RoshanAgr> I am suggesting twice a year.
16:16:08 <russellb> twice/year like design summits makes sense
16:16:11 <RoshanAgr> ODS + workshop + ODS + workshop
16:16:12 <adrian_otto> we should do some homework to plot the location of participants. We do know we are pretty spread out, mostly from the US
16:16:53 <russellb> but should always treat the mailing list as the first class citizen, and where decisions should ultimately be made whenever possible :)
16:16:54 <adrian_otto> ok, so please think on this topic and we will follow up on ML
16:17:08 <adrian_otto> russellb: agreed
16:17:16 <adrian_otto> #topic Discuss alignment with Icehouse Release Schedule
16:17:25 <adrian_otto> Do we want to align with the icehouse milestone schedule: https://wiki.openstack.org/wiki/Icehouse_Release_Schedule
16:17:44 <russellb> adrian_otto: what does alignment mean
16:17:49 <adrian_otto> we have 4 milestones in LP, but I have not targeted them to dates
16:18:10 <adrian_otto> alignment would mean milestone 1 = i2, etc
16:18:23 <adrian_otto> so we would do a time based release schedule rather than feature based
16:18:31 <russellb> in general, working along the openstack schedule makes sense, but i don't know if the existing milestones are scoped to match the schedule right now, are they?
16:18:41 <adrian_otto> this might not make sense until we have a base set of functionality first
16:18:58 <kraman2> adrian_otto: while starting this project might make more sense to do feature basd release for the first few releases
16:19:08 <adrian_otto> my opinion is that we should start alignment as soon as we have one working use case
16:19:19 <claytonc> the combination of those two statements makes sense to me
16:19:26 <briancline> I would think so, to avoid another swift-like situation (it may have served well in the past but for a new project it seems anomalous)
16:19:31 <tomblank> adrian_otto: it may be too soon for us to go to date based schedule but as soon as we have base functionality i think that would be good.
16:19:34 <russellb> as long as each iteration is aggressive, feature based seems OK for now
16:20:04 <adrian_otto> ok, anyone feel strongly that we should switch to dates before we have some basic features done?
16:20:11 <sallamaraju> RoshanAgr was the use case described on white board with 7-8 steps captured some place?
16:20:45 <RoshanAgr> it is on my phone, and Krisha also has it. I or Krisha will publish it
16:20:46 <briancline> I sort of do, though it seems a valid point that i1 is going to be a miss in that case
16:20:50 <russellb> i dunno ... time based is tempting, makes life easier with it aligned with everything else
16:20:58 <russellb> i1 does have some notable stuff
16:20:59 <claytonc> sallamaraju: RoshanAgr i owe a todo from ML to add more scenarios like that as well
16:21:16 <kraman2> RoshanAgr: I have the picture as well and can publish it
16:21:18 <russellb> there's an API binary, the service is integrated with devstack, some initial API implementation is there
16:21:19 <RoshanAgr> claytonc: perfect
16:21:32 * briancline intrigued
16:21:44 <briancline> didn't realize it was that far along (mostly re: devstack)
16:21:49 <russellb> the more i think of it, the more i like just using the main openstack schedule
16:21:54 <russellb> yeah we need more people writing/reading the code
16:21:56 <briancline> in that case, I actually feel more strongly now about icehouse alignment
16:22:03 <adrian_otto> ok, so I think I see consensus here that we should stay on the feature milestone system for now
16:22:08 <russellb> decent velocity, but not that many people compared to how many say they are interested in this project
16:22:16 <adrian_otto> and revisit alignment with the date based system
16:22:30 <russellb> i'm actually arguing the opposite
16:22:40 <adrian_otto> ok
16:22:49 <russellb> don't have to do the feature freeze part
16:23:16 <russellb> but alignment is good
16:23:20 <briancline> wrt the aforementioned writing/reading code part, I'm glad to help, as the holidays are going to be slooowww for me this year, it seems
16:23:36 <russellb> and as each openstack milestone hits, a solum milestone update email can go out talking about project status and what we accomplished
16:23:46 <adrian_otto> russellb: I see the key reason that the number of developers submitting patches is small is because there are many developers who are getting used to the way this project works.
16:23:54 * russellb nods
16:23:55 <adrian_otto> we have a lot of open design items
16:24:09 <briancline> yes, that's the sole reason I haven't tangibly jumped in by now
16:24:21 <adrian_otto> and as we converge on some ideas, and devs get familiar with the way things work, whic will ramp up naturally
16:24:25 <russellb> yep, need to burn through those, and hopefully identify the smallest reasonable iteration to start with
16:24:49 <rajdeep> +1 on open design items
16:25:03 <adrian_otto> so, let's table this discussionfor now
16:25:17 <russellb> ok...
16:25:22 <adrian_otto> and let's revisit it on ML to make the consensus very clear
16:25:38 <adrian_otto> and let's look at some blueprints to help advance our design situation
16:25:43 <adrian_otto> #topic Review Blueprints
16:25:58 <adrian_otto> First Milestone: https://launchpad.net/solum/+milestone/0.1
16:26:07 <russellb> link doesn't work
16:26:08 <adrian_otto> this is a view of all blueprints for the first milestone
16:26:16 <adrian_otto> oh, no
16:26:22 <RoshanAgr> https://launchpad.net/solum/+milestone/milestone-1
16:26:27 <RoshanAgr> That is the right link
16:26:27 <rajdeep> permission error
16:26:48 <adrian_otto> https://launchpad.net/solum
16:27:02 <adrian_otto> look at the section "Series and milestones"
16:27:18 <adrian_otto> then click on milestone-1 on that little line/dot chart
16:27:28 <adrian_otto> that should show you the blueprints in this milestone
16:27:48 <adrian_otto> does that work?
16:27:58 <russellb> the link RoshanAgr posted works
16:28:12 <adrian_otto> ok, sorry for the mixup
16:28:20 <adrian_otto> Subscribe to each blueprint if you want email updates on them.
16:28:29 <adrian_otto> Ask for Assignee status if you can keep track of development on the feature and report on it weekly at our IRC meetings. You do not have to write the code yourself if you are the Assignee, only champion it.
16:28:32 <kraman2> adrian_otto: the blueprint for git is not specifically the one for git pull workflow. is that intentional?
16:28:43 <RoshanAgr> Ability to push code to the platform via Git: I would request Assignee status for that blueprint
16:28:48 <russellb> fwiw, assignee in other projects == implementor
16:28:58 <adrian_otto> kraman2: Roshan will address
16:29:12 <kraman2> RoshanAgr: will ping you offline
16:29:18 <adrian_otto> hold on before we jump in on those
16:29:20 <RoshanAgr> kraman2: sure
16:29:24 <adrian_otto> let's start simple
16:29:41 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/definitions Definitions and terminology used in Project Solum
16:29:52 <adrian_otto> Seek Definition Approval. Are we ready to proceed, or is more discussion needed?
16:30:16 <tdeckers> just catching up... Application seems ambiguous.  Has Application package been considered?
16:30:41 <adrian_otto> tdeckers: we can revisit that one
16:31:02 <adrian_otto> I'll just take noted for subjects to discuss on this BP if we are not ready to approve it
16:31:09 <adrian_otto> since we have a long list to look at today
16:31:14 <tdeckers> np
16:31:14 <claytonc> tdeckers: let's go to the ML on that one
16:31:20 <claytonc> haven't had a good discussion
16:31:30 <adrian_otto> ok, will do, let's advance to the next if there are no further remarks
16:31:53 <briancline> I would say strike "OS Container" and keep it generic as "Deployment Unit"
16:32:06 <RoshanAgr> briancline: +1
16:32:17 <claytonc> +1
16:32:27 <tdeckers> +1
16:32:41 <coolsvap> +1
16:32:46 <gokrokve> +1
16:32:50 <tomblank> +1
16:32:56 <adrian_otto> Ok, thanks. We will not seek approval, because we have more changes on this
16:32:59 <jwforres> I would like to see some concept of 1-1 vs 1-many on the relationships in that diagram if possible
16:33:07 <adrian_otto> will revisit later.
16:33:16 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/app-deploy-manage (roshanagr) Solum-R1 Stories: Application Deployment/management
16:33:29 <adrian_otto> Note, this has several child blueprints, each will be individually discussed/approved.
16:33:31 <russellb> R1 == milestone 1?  or?
16:33:48 <adrian_otto> yes R1=milestone1
16:33:50 <adrian_otto> Seek Definition Approval. Are we ready to proceed, or is more discussion needed?
16:33:51 <RoshanAgr> russellb: R1 != milestone 1
16:33:55 <russellb> heh
16:33:58 <adrian_otto> what?
16:34:10 <adrian_otto> oh, because some were marked as out of scope?
16:34:21 <gokrokve> R1 = requirement #1
16:34:26 <RoshanAgr> yes
16:34:40 <RoshanAgr> also , what gokrokve said
16:34:40 <adrian_otto> aha, I see
16:34:59 <russellb> i think it's useful to capture requirements around the milestone
16:35:14 <russellb> so if some of this is in and some out, maybe it makes sense to clarify that somehow?
16:35:30 <adrian_otto> so do we need further iteration on this as proposed, or should we approve this, and focus on the child BP's next?
16:35:35 <RoshanAgr> russellb: yes agreed. We still need some requiment identifier
16:35:53 <russellb> I think it should be updated to clearly identify what is in scope for the milestone
16:35:54 <RoshanAgr> R1, R2 is an attempt, but I can see how that can be confusing
16:35:57 <russellb> and the rest pushed off to something else
16:36:17 <devkulkarni> russellb: +1
16:36:25 <kraman2> this is a high level blueprint which is broken down into smaller ones. perhaps we should keep only the implementation BPs as part of the milestone.
16:36:39 <russellb> perhaps.
16:36:51 <gokrokve> Yes. We had a list of requirements to be implemented in M1.
16:36:53 <russellb> the list of blueprints targeted at the milestone sort of define the milestone on their own
16:37:01 <gokrokve> This list was captured in etherpad.
16:37:01 <rajdeep> one question on deployment
16:37:13 <adrian_otto> kraman2: that's somethign I did discuss with Rohan, and I support that approach
16:37:22 <adrian_otto> *Roshan
16:37:30 <RoshanAgr> kraman2: agreed.
16:37:32 <russellb> some of this is user story stuff, and some of it identifies some design details (the CLI stuff)
16:37:34 <adrian_otto> rajdeep: ?
16:37:36 <rajdeep> how does the persistent store get rewired from local settings to remote setting
16:37:43 <rajdeep> on deployment
16:37:48 <russellb> the story would be less detailed and just that ... I can create a thing via the CLI
16:37:53 <kraman2> russellb: ys, but we can move that into the CLI BP itself
16:37:54 <russellb> or see the deatils of the thing
16:37:58 <russellb> sure
16:38:30 <adrian_otto> rajdeep: can you expand on that question with some additional detail about your concern?
16:38:49 <rajdeep> e.g jdbc url would change to the private ip of the container where service is running
16:39:24 <rajdeep> developer first builds the app locally
16:39:34 <rajdeep> and then does deployment to solum
16:39:48 <rajdeep> solum should auto rewire to the remote persistent store
16:40:36 <adrian_otto> in that case you would need to make the configuration option flexible. One way to do that is to use a service registry. Another way might be to abstract data services behind Heat resources that are defined by Providers, and you look up the address of it at runtime.
16:40:51 <gokrokve> Solum will support runtime variables and environment but it is up to developer to map these variables to some specific services' parameters.
16:41:24 <adrian_otto> gokrokve: yes, and environment variables is another way to handle it, which is a bit less flexible, but a common technique
16:41:30 <rajdeep> yes we should do both auto and manual rewiring
16:41:32 <rajdeep> giving option to the developer
16:41:48 <tdeckers> persistance service lookup seems the way to go.  Would be interesting to see how migrations of the persistence service itself would be handled though
16:42:04 <adrian_otto> ok, so not to get too far in the weeds on this right now
16:42:04 <tdeckers> e.g. schema migrations is apps require it, etc..
16:42:14 <rajdeep> ok
16:42:24 <gokrokve> It might be a requirement for "badger" or "language pack" to support auto rewiring for common services.
16:42:29 <adrian_otto> we have a few important blueprints that I'd like to get assigned today
16:42:47 <gokrokve> I can take User authentication for incoming requests.
16:43:06 <russellb> gokrokve: is that just using keystone auth token middleware?
16:43:12 <adrian_otto> ok, we will get there in a couple minutes gokrokve
16:43:12 <RoshanAgr> I volunteer for: Ability to push code to the platform via Git
16:43:14 <russellb> should be pretty quick/easy :)
16:43:24 <adrian_otto> our next one is:
16:43:25 <adrian_otto> #link https://blueprints.launchpad.net/solum/+spec/git-integration (assignee-needed) Ability to push code to the platform via Git
16:43:44 <adrian_otto> remember that being assigned means that you will be polled at these weekly meetings for status
16:43:47 <gokrokve> russellb: Not really. It is an integration with keystone but we need to figure out an access model for solum resources.
16:43:55 <adrian_otto> that we expect you to keep informed about the status of allr elated dev work
16:44:15 <gokrokve> Yes. I will update you on the status for this BP each meeting.
16:44:15 <adrian_otto> but it does not meant that you will individually write all the code
16:44:20 <russellb> does the blueprint capture the first iteration of git integration?
16:44:32 * russellb thinks the primary author of the code should be the assignee :)
16:44:32 <kraman2> russellb: there is a git-pull BP for that
16:44:33 <devkulkarni> russellb: BP has two parts
16:44:39 <kraman2> i can take that one
16:44:44 <russellb> kraman2: cool
16:44:47 <devkulkarni> one is git-pull, another bp is git-push
16:44:47 <briancline> I'd like to jump on solum-git-pull as well
16:45:07 <RoshanAgr> adrian_otto: is the expectation for an assignee writes some code
16:45:08 <russellb> so this has both pull and push under it, both are part of first iteration?
16:45:13 <adrian_otto> so if you want to work on one of these (contribute code/design) just subscribe to the BP
16:45:15 <russellb> RoshanAgr: i hope so
16:45:23 <kraman2> no, only pull is part of first itr
16:45:30 <adrian_otto> and let one of you own it who is a subject matter expert
16:45:39 <russellb> ok, if just pull, looks like some dependency juggling needs to be done
16:45:40 <kraman2> atleast thats what we discussed suring F2F
16:46:01 <russellb> or just remove the push from the dep tree
16:46:19 <kraman2> russellb: push is needed as well
16:46:30 <kraman2> there pull and push are seperate
16:46:39 <russellb> right, but the way the blueprints are set up right now, it's saying both are in the first milestone
16:46:40 <kraman2> if we keep just pull BP on milestone 1, we should be fine
16:46:57 <russellb> ok, so then git-integration wouldn't be on milestone-1
16:47:05 <kraman2> adrian_otto: RoshanAgr: can we make that change?
16:47:06 <russellb> and just solum-git-pull
16:47:18 <devkulkarni> russellb: that is correct
16:47:22 <paulczar> for first itr could be as basic as a url to a tarball ( github generates these automagically )  … that would reduce the deps even further
16:47:22 <RoshanAgr> russellb: a subset of that will be (it still needs to broken into child blueprints
16:47:39 <adrian_otto> ok, so do I have a volunteer to own the parent blueprint git-integration (Roshan, do you want it, or is there a better Stacker for that?)
16:47:51 <kraman2> adrian_otto: I can own the git flow
16:48:02 <kraman2> if RoshanAgr doesnt mind :)
16:48:11 <adrian_otto> ok, set yourself as assignee, or if it does not allow you I can do it for you
16:48:13 <russellb> RoshanAgr asked about code expectation, i don't think that was answered
16:48:18 <RoshanAgr> kraman2: I won't mind :-)
16:48:19 <russellb> <RoshanAgr> adrian_otto: is the expectation for an assignee writes some code
16:48:37 <adrian_otto> russellb: I missed that sorry. What was the concern? Can we repeat it?
16:48:40 <adrian_otto> aha
16:48:54 <adrian_otto> no, an assignee is not necessarily a code writer
16:48:58 <russellb> why?
16:49:03 <adrian_otto> but you need to follow all the patches for that feature
16:49:14 <russellb> why wouldn't you go to the person doing the work for an update?
16:49:16 <adrian_otto> so I prefer that it be owned by a developer
16:49:33 <adrian_otto> so they can review all the code that posts to that blueprint. It should at least be a reviewer.
16:49:52 <adrian_otto> this is a case where there will be more than one developer
16:50:01 <adrian_otto> if there is onyl one, this is simple, he/she owns it
16:50:05 <kraman2> russellb: how are other projects (nova?) structured ?
16:50:17 <adrian_otto> if there is a group contributing, then you pick a captain, essentially
16:50:19 <russellb> and if there are multiple, one of the developers would own it?
16:50:27 <russellb> right ... then the answer to the question is yes then right?
16:50:30 <adrian_otto> russellb: yes
16:50:36 <russellb> the expectation is generally that the assignee is helping write the code at least
16:50:40 <RoshanAgr> In the case of git blueprint, kraman2 has volunteered
16:50:57 <adrian_otto> yes, that makes sense for that one
16:51:00 <RoshanAgr> I think he is the right owner of it since he will be closer to the code
16:51:14 * briancline also volunteered for pull
16:51:15 <adrian_otto> any other participants will be subscribers
16:51:33 <adrian_otto> and I ask that if you write *any* code for that bp that you review all patches for it.
16:51:53 <kraman2> +1
16:51:55 <adrian_otto> so you don't end up with duplicative contributions, or in conflict
16:52:31 <adrian_otto> for those who are new to using Gerrit+Launchpad together, the system can automatically post links to the patches in the LP whiteboard for the blueprint
16:52:44 <adrian_otto> when the Gerrit topic is listed in the whiteboard
16:53:04 <adrian_otto> so all you need to do is be a subscriber, and you will get an email every time someone posts a review against that blueprint
16:53:08 <adrian_otto> make sense?
16:53:17 <russellb> you can also get email notifications from gerrit
16:53:24 <russellb> for new changes, merged changes, or any updates to reviews
16:53:33 <adrian_otto> russellb: yes
16:53:41 <adrian_otto> that's more of a firehose
16:54:15 <russellb> but i would expect anyone working on this full time to keep up with that, IMO
16:54:33 <russellb> should always have an idea of what code is in flight
16:55:44 <adrian_otto> ok, so we had a packed agenda today, and I knew it would be hard to get through all of it, so I'll allow you to use the Agenda wiki page to know what needs to be assigned, and let's get those all assigned. See me if there are any questions, please.
16:55:56 <briancline> so as a closing point, the current assignees on these should be following everything related, possibly contributing code
16:56:03 <adrian_otto> for those topics that need discussion, let's fire up ML threads for each
16:56:12 <briancline> if i understood that correctly
16:56:28 <kraman2> briancline: i think assignees will be contributing code
16:56:40 <russellb> kraman2: +1 :)
16:56:43 <adrian_otto> briancline: yes, if you own it, there is an expectation that you are down in the details
16:56:58 <adrian_otto> and that you are helping advance it
16:57:03 <briancline> ok
16:57:31 <adrian_otto> and even if you are doing most of the code, and you don't want to be the owner, you will not be forced to.
16:57:34 <devkulkarni> briancline, kraman2: please feel free to add/modify to git-solum-pull bp. will be happy to discuss it afterwards
16:57:42 <adrian_otto> but one of your co-contributors will
16:57:50 <russellb> i don't understand why the person doing most of the code would *not* be the owner
16:57:57 <russellb> they are the owner by definition, to me
16:57:57 <kraman2> devkulkarni: will start a ML thread about it
16:58:12 <adrian_otto> russellb: I think that will happen naturally
16:58:26 <adrian_otto> and we can re-assign the owner when it makes sense
16:58:34 <russellb> ok.
16:58:49 <adrian_otto> but I don't want contributors to get the sense that if they are not marked as the owner that they can't work on it
16:58:52 <coolsvap_> I think instead of much debating about who should own it, be a subscriber and write code :)
16:58:58 <adrian_otto> so I want to be very explicit about that
16:59:10 <devkulkarni> coolsvap_: +2 :)
16:59:20 <adrian_otto> exactly
16:59:22 <adrian_otto> so
16:59:23 <adrian_otto> #topic Open Discussion
16:59:33 <adrian_otto> sorry I never have enough time for this part of the meeting
16:59:49 <adrian_otto> I will need to do a better job of keeping the Agenda shorter
17:00:14 <gokrokve> It will be hard for this stage of the project.
17:00:20 <russellb> ML threads should help
17:00:24 <adrian_otto> indeed
17:00:35 <RoshanAgr> We covered a lot. great meeting
17:00:39 <adrian_otto> thanks everyone, I'm super pumped about where we are
17:00:41 <adrian_otto> #endmeeting