20:01:40 <ttx> #startmeeting tc
20:01:41 <openstack> Meeting started Tue May 21 20:01:40 2013 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:44 <openstack> The meeting name has been set to 'tc'
20:01:52 <ttx> A couple discussion topics on the agenda today
20:01:57 <gabrielhurley> \o
20:01:59 <ttx> #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee
20:02:02 <jgriffith> \o
20:02:17 <ttx> #topic Common API version discovery mechanism
20:02:27 <ttx> We said in a past meeting that we would track progress on this
20:02:33 <ttx> #link https://etherpad.openstack.org/api-version-discovery-proposal
20:02:41 <ttx> gabrielhurley: care to give a quick update ?
20:03:19 <gabrielhurley> Where it stands currently is that the versioning stuff is pretty much settled. I'd hoped to get some consensus around "capability" discovery too, but that's been a trickier issue, so I think progressing on version discovery independently is the thing to do for now.
20:03:53 <markmc> yay baby steps
20:04:10 <gabrielhurley> Next step is to put together an API sample/spec that everyone can agree on for what the response to a version discovery request should look like.
20:04:15 <ttx> gabrielhurley: do you think you need anything formal from the TC, or you're happy to go ahead summarizing the road ahead on openstack-dev and jfdi ?
20:04:23 <ttx> ok
20:04:42 <gabrielhurley> yep, I'll continue to drive from the dev list side currently, but it's always good to know the TC supports it
20:05:16 <ttx> questions on that ?
20:05:25 <notmyname> gabrielhurley: I have yet to see any response to the concerns raised by the swift team on some of the version discovery (although that shouldn't derail the larger questions)
20:05:37 <gabrielhurley> which concern was that?
20:05:53 <notmyname> the specific on is that /version/capabilities won't work for swift
20:06:07 <notmyname> it was on the etherpad (since deleted) and also on the mailing list thread
20:06:16 <vishy> o/
20:06:21 <dolphm> gabrielhurley: how do we approach backwards compatibility with existing 300 multiple choice responses? last i checked, there were some discrepancies on the implementation between projects
20:06:35 <gabrielhurley> gotcha. I think I misunderstood that point. can you ping me separately about that so I can follow up?
20:06:43 <gabrielhurley> as I said though, capabilities is gonna have to be a separate issure
20:07:22 <gabrielhurley> dolphm: good question, and we may just have to have workarounds in the clients to deal with the "legacy" responses.
20:07:28 <notmyname> on the api versioning side, is there any concern that an existing app at host/v1 is now raising it's scope to respond to /?
20:07:48 <dolphm> gabrielhurley: what about legacy clients?
20:08:25 <dolphm> gabrielhurley: just assume none of them are smart enough to be using it? (auth_token currently does some trivial inspection of the 300 response)
20:08:29 <gabrielhurley> dolphm: the only way out is to rewrite history, which I don't think we're in the business of doing. Legacy clients don't support version discovery. They're pinned to whatever version they were built to work with.
20:09:09 <gabrielhurley> backporting version discovery sounds like a painful, messy and dangerous task
20:09:21 <gabrielhurley> IMHO it's a "from here on out this works" type of deal
20:09:22 <dolphm> agree
20:09:29 <ttx> gabrielhurley: see notmyname's question just above
20:09:36 <ttx> <notmyname> on the api versioning side, is there any concern that an existing app at host/v1 is now raising it's scope to respond to /?
20:09:49 <gabrielhurley> notmyname: I don't see a problem with it personally, but I'm open to concerns on it
20:10:09 <gabrielhurley> the app technically already owns the / space, even if it's not responding there
20:10:22 <gabrielhurley> OpenStack doesn't have good support for services not living at root currently
20:10:35 <ttx> gabrielhurley: I propose that we consider the topic solved as far as the TC goes -- please just raise it back from the dead if you encounter a roadblock that you think we can collectively help you with
20:10:36 <dolphm> i'm thinking we need a openstack/common-api project to consistently define things at that level for (at least) core projects
20:10:52 <gabrielhurley> dolphm: +1000
20:11:23 <ttx> dolphm: a new doc project ?
20:12:22 <ttx> Other questions on that topic ?
20:12:30 <dolphm> ttx: don't know, good question
20:13:04 <ttx> dolphm: what would be in your openstack/common-api project ? base principles that every openstack API should implement ? Or code to that effect ?
20:13:35 <dolphm> ttx: api documentation for the 300 response, approach to versioning that response (if any), perhaps /capabilities when we get there
20:13:41 <gabrielhurley> base principles at least would be my hope. reusable code would probably be better off living in oslo, but the two are related
20:13:47 <dolphm> gabrielhurley: +1
20:14:05 <ttx> gabrielhurley: ok, so common API design rules
20:14:09 <gabrielhurley> yeah
20:14:16 <gabrielhurley> we direly need a place for that sort of thing to live
20:14:22 * markmcclain thanks to delta.. I'm here for a little while
20:14:50 <ttx> gabrielhurley: yes. Could be some wiki doc, though
20:15:06 <gabrielhurley> pros and cons... wikis are easy to change ;-)
20:15:11 <dolphm> so, keystone-core has plustwoability over https://github.com/openstack/identity-api even though i sort of see it as a doc project -- i'm not sure there's an existing group that makes sense for reviewing openstack/common-api ?
20:15:24 * annegentle catches up reading
20:15:31 <notmyname> there is api-site
20:15:41 <gabrielhurley> that documents the existing APIs
20:15:54 <gabrielhurley> this is more about defining best practices and specs for *new* APIs
20:16:03 <gabrielhurley> a goal for us all to work towards
20:16:20 <dolphm> gabrielhurley: ah, you want to include hateos, etc, there long-term?
20:16:22 <ttx> we can have a new project and let TC plustwoing it
20:16:57 <gabrielhurley> dolphm: yeah. and things like needs around filtering, pagination, etc. that all projects need some form of. we need to stop reinventing the wheel on those.
20:17:10 <gabrielhurley> ttx: that'd make the most sense
20:17:23 <ttx> anyway, implementation details. Anything more before we switch to talking about copyright headers ?
20:17:41 <annegentle> is there any new requirement for a doc standpoint to support capabilities?
20:17:48 <annegentle> for/from
20:17:53 <dolphm> gabrielhurley: i'm down for that, as long as we make a distinction between what is required of openstack api's and what is a very strongly recommended best practice
20:18:05 <gabrielhurley> annegentle: I don't think so
20:18:09 <gabrielhurley> not yet at least
20:18:19 <annegentle> methinks we don't document extensions very well today so I don't know how capabilities will be an improvement, docs-wise, other than letting the api self-doc? I guess?
20:18:22 <gabrielhurley> dolphm: absolutely. we can't force anyone to do anything
20:18:54 <gabrielhurley> annegentle: it's more for downstream consumers (like Horizon) to understand what things should be allowed in the interface
20:19:09 <gabrielhurley> but yes, the docs for extensions are weak. that's a separate issue. ;-)
20:19:37 <ttx> ok, next topic
20:19:44 <ttx> #topic Getting rid of copyright headers
20:19:55 <ttx> markwash raised the idea of getting rid of copyright notices in file headers
20:20:02 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2013-May/009189.html
20:20:16 <ttx> I think that *if* we do this, we have to do it consistently across all "OpenStack" projects
20:20:25 <markwash> well
20:20:38 <mikal> Do we really think its worth the effort?
20:20:40 <markwash> for some more context #link http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
20:20:48 <dolphm> mikal: is it really that much effort?
20:20:57 <markwash> guys, can we hold on here for a sec
20:20:58 <ttx> mikal: personally I'm not convinced of that
20:21:12 <jgriffith> I agree with ttx about global, however I think this is going to be more problematic than it's worth
20:21:16 <ttx> but some people are not even convinced it's a good idea to drop per-file info
20:21:31 * ttx holds
20:21:39 <markwash> so there are three proposals in that email
20:21:40 <hub_cap> so being a new project, i have 16 different versions of the headers in my code (overstatement). what is the purpose of keeping them?
20:22:04 <markwash> the first proposal is pretty simple and cultural: we just try to avoid adding new copyright headers
20:22:05 <jgriffith> hub_cap: None, except some false sense of *something* to *someone*
20:22:32 <markwash> the justification for that is that copyright headers are a small but not insignificant effort to keep up to date
20:22:42 <markwash> and our best efforts so far have produced huge inaccuracies
20:22:57 <markwash> on top of that, they are completely unnecessary for folks to retain copyright
20:22:59 <russellb> hub_cap: don't confuse the copyright statement with the license in the header, different issues
20:23:28 <hub_cap> russellb: oh i mean copyright... i know u fixed a good bit of them but ive had issues internally w/ them and my team
20:23:44 <markwash> this proposal has no enforcement mechanism other than communication and review
20:23:53 <markwash> we're essentially defining what the "new normal is"
20:23:58 <ttx> markwash: I think you increase inaccuracies if you stop adding them while keeping old ones around
20:24:14 <dolphm> tangential: i don't totally understand how anyone can claim copyright without directly conflicting with the CLA Grant of Copyright License clause- https://review.openstack.org/static/cla.html
20:24:22 <ttx> (or at least you increase confusion)
20:24:40 * markmc notes the combination of "these headers don't mean anything" and "oh noes! they're inaccurate!"
20:24:43 <markmc> don't really get it
20:24:47 <jgriffith> TBH I'm still trying to figure out the maintenance burden?
20:24:56 <jeblair> dolphm: granting a copyright licenese is not the same as copyright ownership
20:25:10 <markwash> jgriffith: there was an email in the thread that documented the effort that was going into reviewing the headers
20:25:14 <jgriffith> My thought is if it makes somebody or somebody's legal team feel warm and fuzzy they can add copyright
20:25:25 <jeblair> dolphm: typically you or your employer owns the copyright in the code you write, and that's what the header indicates
20:25:28 <jgriffith> markwash: I read it, but didn't see the effort
20:25:41 <markwash> jgriffith: the problem is that we get a lot of cargo-culting around those warm-and-fuzzies
20:25:47 <dolphm> jeblair: makes sense; thanks!
20:25:53 <jgriffith> markwash: I understand that
20:26:01 <jgriffith> markwash: I'm not saying I like it/agree with it
20:26:05 <markwash> I think another thing to consider is that, inaccurate copyrights could give the wrong impression to someone
20:26:09 <ttx> jgriffith: if our group spends more than 10 minutes discussing it, I think that will be more time spent on it than maintaining them ever will
20:26:11 <jgriffith> Just a firm believer in choosing my battles
20:26:20 <markmc> jgriffith, yes, yes
20:26:21 <jgriffith> ttx: haha, +1
20:26:21 <markwash> for example, several files in glance, I might think I can talk direclty to red hat to license the content
20:26:24 <markmc> sorry
20:26:26 <markmc> ttx, agree
20:26:50 * jgriffith is sad that markmc didn't agree with him :(
20:26:59 <markwash> ttx: my hope with a policy like this is that at least if we know how things *should* be, we can outgrow the problem
20:27:02 <markmc> jgriffith, oh, I actually did
20:27:12 * jgriffith yell Yay!!!
20:27:39 <markwash> well, I can see you guys have already dismissed my concern about the reviewing time
20:27:51 <ttx> markwash: the trick is that it's not really a technical problem, I think. People/companies are also attached to the fuzzy attribution that those notice get them
20:27:59 <markwash> but frankly it is not fun when someone -1s your review becuase of copyright headers
20:28:11 <jgriffith> markwash: they should be slapped
20:28:12 <ttx> so reaching any kind of consensus around this is likely to take time
20:28:24 <ttx> for a... limited gain.
20:28:28 <annegentle> ttx: markwash: there's git blame, and there's copyright headers, for trying to figure out who might know something about a particular file. You can pick which you believe.
20:28:46 <markwash> annegentle: since folks should not believe the headers, they seem like a liability
20:28:50 <mikal> Did we end up with NOTICE files being agreed to?
20:29:05 <ttx> mikal: no
20:29:06 <markmc> mikal, no, very much not
20:29:13 <markwash> I don't really like NOTICE files either. . much better to accept that in-source isn't the way to go
20:29:14 <markmc> I occasionally pull people up on Copyright headers
20:29:27 <markmc> e.g. if they're obviously just sticking in OpenStack Foundation with no basis
20:29:35 <markmc> it's not hard to understand what to put in a header
20:29:48 <markmc> and I expect most people only need to be told once
20:29:55 <markmc> and then don't make the most obvious mistakes again
20:30:02 <sdague> markmc: my experience differs on that :)
20:30:06 <jeblair> and copyright is important for an open source project
20:30:21 <russellb> sdague: on submitters?  hopefully not reviewers
20:30:22 <sdague> I've found repeated education required on both contributors and reviewers
20:30:33 <jeblair> we should be able to document for new contributors what is expected, and it shouldn't take that much time in the long run
20:30:35 <mikal> So, I agree that copyright lines in the headers are inaccurate and annoying. I just worry that its a really big job to remove them. Not technically, but from an arguing with people perspective.
20:30:38 <russellb> that's sad, because honestly if you're reviewing code, you *better* have a basic understanding of this stuff
20:30:54 <markwash> mikal: I feel like the whole "we have to remove them all" is a false dilemma
20:31:08 <jgriffith> Ok, maybe you guys have a point here
20:31:14 <sdague> russellb: people didn't get chosen for core reviewing based on how they evaluated copyright headers
20:31:17 <markwash> offered by folks who didn't like the proposal to begin with and didn't like finding out their legal advice was out of date
20:31:44 <mikal> markwash: in the sense of you just want to stop adding more and leave the current ones?
20:31:52 <jeblair> that's a false solution
20:31:53 <mikal> markwash: cause that seems unfair to me...
20:32:11 <markwash> mikal: that, plus remove the easy ones, like openstack foundation, and red hat (which has already offered unilateral permission)
20:32:15 <markwash> mikal: in what way?
20:32:29 <markwash> jeblair: how so?
20:32:38 <mikal> markwash: I'm sure that people will say "how come I can't have one when all those people over there have them?"
20:32:44 <jgriffith> markwash: I think you'll have the "well they did it, why can't I"
20:32:46 <sdague> yeh, pretty mcuch
20:32:47 <jeblair> markwash: that will only make them more inaccurate
20:32:52 <sdague> jeblair: +1
20:32:54 <ttx> mikal: +1
20:32:54 <markwash> and we'll say "those are historical artifacts of no import"
20:33:33 <jeblair> markwash: ideally, would you like no copyright notices anywhere?
20:33:42 <sdague> if they are of no import, they should come out :)
20:33:50 <markwash> jeblair: yes
20:33:50 <ttx> markwash: unfortunately some companies see copyright notices as a contribution advertising space. So keeping the old ones around while new contributions don't generate new ones is likely to be... contested
20:33:56 <notmyname> and the corporate council of all the contributing companies feel that they are of no import? seems unlikely
20:34:10 <jeblair> the trouble i have with that is that we would be distributing open source software with no indication of who actually owns the copyright
20:34:13 <jeblair> i find that disturbing
20:34:29 <markwash> jeblair: do you feel that way after reading http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html ?
20:34:36 <markwash> I was impressed by the logic there
20:35:00 <markwash> ttx: feels like a job for an AUTHORS file
20:35:18 <ttx> markwash: I fear it's not a legal or technical issue. It's a warm fuzzies and a "why me and not him" issue
20:35:20 <jeblair> markwash: yes, i do actually.  i think it would be very strange not to have any idea who owned the copyright to OpenStack code
20:35:20 <notmyname> or vcs logs
20:35:25 <sdague> ttx: that's exactly the bind i'm in. I've gotten preliminary sign off that ibm is cool with them coming out, as long as it's policy and everyone's comes out.
20:35:40 <sdague> but a partial solution is a problem
20:35:44 <ttx> markwash: I agree with you that technically and legally, what you propose is fine
20:36:09 <sdague> jeblair: this is already policy on all the apache projects, do you not use them because of it?
20:36:19 <ttx> markwash: but I expect contributors to continue to push copyrigth notices... and us having little ground to deny them
20:36:31 <ttx> (unless they are all removed)
20:36:32 <jeblair> notmyname: vcs logs can be wrong (and are often VERY wrong in our projects), and moreover, they don't actually tell you who owns the copyright
20:36:53 <mikal> jeblair: many people don'
20:36:59 <mikal> t add these headers for non-trivial changes
20:36:59 <ttx> sdague: agreed. I expect more companies will react just like IBM, hence my "all of them or nothing" stance
20:37:07 <mikal> jeblair: Look at nova/virt/libvirt/driver.py for example
20:37:20 <mikal> jeblair: the true list of copyright holders for that file will be much longer than what's there
20:37:30 <markwash> one potentially tangential concern is, why do people need to track down the copyrights? why can't they just accept asl 2.0 licensing from the foundation?
20:37:45 <jgriffith> markwash: FWIW I agree with the philosophy and what your saying
20:38:00 <jgriffith> markwash: I think the backlash is worse than the maintenance though
20:38:01 <markwash> jeblair: we can also put in notices that say "you should look to this projects something-or-other for any hope of tracking down copyrights" in every file
20:38:13 <jgriffith> markwash: and I agree with others that it has to be global or nothing
20:38:31 <mikal> Well, we also haven't tested the backlash at all
20:38:40 <mikal> We could just try it with nova and see how bad it is
20:38:43 <sdague> mikal: +1
20:38:44 <markwash> so the main reason for global or nothing, is a sense of fairness for companies that want to use notices as a advertising space?
20:38:53 <markwash> mikal: unfortunately nova is the worst
20:38:55 <mikal> Maybe we're over estimating how much people care
20:39:02 <ttx> agree that nobody should care, from a technical or legal standpoint. But in practice they care, because their name is on something, and it has value to them
20:39:31 <ttx> mikal: we already know IBM cares. I expect others to take the same "ok if everyone does it" stance
20:39:32 <markwash> ttx: I feel like "moving to NOTICE" rather than "removing" might help soften the blow, do you agree?
20:39:52 <markmc> ttx, not NOTICE, that's a whole other ball of wax
20:39:54 <ttx> markwash: yeah, that's why I looked into that, see my thread on legal-discuss
20:40:13 <markmc> ttx, maybe a centralised file, but naming it NOTICE opens a whole other thing
20:40:14 <jeblair> mikal, sdague: i think it would be terrible to start rejecting commits to nova because they had (C) notices, but not do the same for every project -- not doing the same across all projects is going to cause SO MUCH confusion
20:40:28 <ttx> markmc: NOTICE or whatever works
20:40:54 <sdague> jeblair: honestly, with different review teams on different projects, it's not going to be any worse than the current situation
20:41:09 <markwash> in any case, I think its clear that files are not required to have copyright headers, correct?
20:41:53 <ttx> So in summary, I expect resistance from companies liking that they are mentioned, unless everyone is removed. Which makes the whole thing a bit complex to set up
20:42:04 <ttx> and /maybe/ not worth it
20:42:32 <markwash> so I'd honestly at this point be pretty happy if the canonical HACKING documentation was "put one in if you really want, but we don't really think there are any good legal or otherwise reasons to, so please try to restrain yourself" and leave it at the current free for all
20:42:44 <markwash> then perhaps in a year or two, the problem will be relatively smaller in terms of cleanup
20:43:24 <ttx> markwash: that's fine with me, as it's legally and technically accurate
20:43:43 <markwash> also, if you substantially modify a file, I'm pretty sure you are allowed to remove previous headers and replace your own
20:43:50 <markwash> so we should make sure people know that as well
20:44:04 <markwash> and tend towards simple removal without replacement
20:44:07 <ttx> markwash: but my trust in human nature is not as large as yours ;)
20:44:29 <markwash> ttx: honestly, most heads-down devs I've talked to find headers very tedious
20:44:43 <markwash> so being given license not to add anything would be nice for them
20:45:10 <markwash> I'd like to remove all openstack foundation ones as well, honestly
20:45:19 <markwash> but perhaps folks would prefer to wrap up the discussion for now?
20:45:28 <ttx> markwash: I suspect most devs put in what their company asks them to.
20:45:33 <dolphm> markwash: can we agree to remove the openstack foundation/llc ones as a first step here?
20:45:33 <mikal> Well, I think many of those were added by Rackspace
20:45:40 <ttx> jeblair: you has a good rationale for keeping per-file info, though
20:45:44 <markwash> ttx: we used to just copy and paste and update the year
20:45:46 <jeblair> dolphm: hardly
20:46:11 <jeblair> dolphm: i don't think they are yours to remove
20:46:22 <jeblair> (nor mine, just to be clear)
20:46:23 * markmc agrees with jeblair
20:46:30 <markwash> jeblair: we would need permission from the foundation, yes
20:47:03 <markwash> but considering all the inaccurate assignment to the foundation that goes on presently, I think they'd be inclined to accept
20:47:06 <mikal> I wonder if we should ask the board to back us up here... Ask the board members to go back to their companies and explain the rationale for not adding more copyright headers?
20:47:20 <russellb> this is turning into quite a time sink
20:47:21 <markmc> markwash, I actually doubt it - the foundation's counsel is pretty conservative IMHO
20:47:25 <ttx> mikal: the board and the contributors are two separate bodies
20:47:28 <markwash> also I don't believe the foundation hopes to license the parts of openstack they hold copyright to separately from the ASL 2.0
20:48:04 <markmc> markwash, dual-licensing is nothing to do with this
20:48:15 <markwash> oh?
20:48:17 <ttx> We should spend that time spent discussing this onto something much more useful, like suggesting names for stuff
20:48:19 <jeblair> markwash: my understanding is that the foundation has copyright ownership of a chunk of code that rackspace donated to it, and that its (current) bylaws prohibit it from doing anything with that code other than releasing it under ASL-2.0
20:49:01 <jeblair> markwash: it may also own copyright in code that fungi and I write.
20:49:02 <markwash> ttx: Infuriating :-)
20:49:27 * fungi nods
20:49:51 <markwash> jeblair: that seems like they don't need notices then
20:49:57 <fungi> i bet ttx can write code too ;)
20:50:10 <ttx> fungi: I can and I do :)
20:50:36 <ttx> but i'm not a Foundation employee so I'll put in whatever I want !
20:50:42 <hub_cap> heh
20:50:55 <fungi> ahh, right. crazy contractors
20:50:55 <jeblair> markwash: i'm not sure why the foundation owning a significant amount of code means they don't need a notice...
20:51:34 <markwash> jeblair: to me it seems like the set of rights they have with code they own copyright to, and the set of rights they have with code licensed to them by the CLA, are congruent
20:51:44 <jeblair> markwash: it seems like aside from anything else, for the purposes of copyright ownership of code, the foundation is in the same boat as all the other contributors
20:52:34 <markwash> jeblair: the other issue is that folks at least for a time have been misattributing copyrights to the foundation
20:52:42 <markmc> markwash, adding or removing the headers doesn't change ownership
20:52:42 <jeblair> markwash: that should stop.  :)
20:53:16 <ttx> seriously, this may seem like an easy problem to solve, but it's not -- and the current situation is not nearly bad enough for us to invest in fixing it
20:53:26 <jeblair> ttx: +1
20:53:36 <ttx> So documenting the technical and legal realities will certainly help in clearing things up
20:53:40 <dolphm> ttx: that sounds like a sane conclusion for the moment
20:54:08 <ttx> but I wouldn't hold my breath on hoping everyone can dance to the same tune on that anytime soon
20:54:15 <markwash> I think if we document the realities better, and some simple advice, we'll be in a better place
20:54:17 <ttx> it's one of thsoe things you need to get right from the beginning
20:54:17 <annegentle> ttx: I have to offer https://wiki.openstack.org/wiki/Documentation/Copyright
20:54:32 <ttx> because touching it afterwards is painful
20:54:47 <ttx> because it's not just a technical issue.
20:55:20 <markwash> annegentle: I'd like to streamline that page, would you be open to reviewing some changes?
20:55:27 <markmc> would be good to add to https://wiki.openstack.org/wiki/LegalIssuesFAQ too
20:55:45 <annegentle> markwash: yes, and you could also move it out from under /Documentation/
20:55:52 <annegentle> markmc: will do
20:56:05 <markwash> annegentle: we need some hard and fast rules "do do this" "don't do this" for some of the obvious problems we have seen
20:56:31 <annegentle> I think 1-2 years and some guidance will help.
20:57:03 * markwash is happy about not being on the hook for writing HACKING checks, at least
20:57:14 <ttx> heh
20:57:43 <ttx> #topic Open discussion
20:57:54 <ttx> 2 more minutes, anyone has anything to raise ?
20:58:02 <dolphm> hard and fast is difficult when the legal speak is subjective enough to use wording like "substantially revised or updated"
20:58:03 <annegentle> I wanted to bring up a doc rename in progress here.
20:58:04 <hub_cap> hey just wanted to mention that we are changing names in reddwarf land, nothign really to discuss
20:58:20 <ttx> hub_cap: we could... suggest names.
20:58:27 <ttx> we like to do that.
20:58:29 <annegentle> We've been removing "Developer Guide" from the titles of documents in <project>-api repositories.
20:58:32 <hub_cap> ttx: https://gist.github.com/hub-cap/5622714
20:58:40 <hub_cap> my favorite so far is cask :)
20:58:49 <markwash> hub_cap: you would
20:58:51 <hub_cap> if u do have a suggestion feel free to ping me, ill add it
20:59:04 <annegentle> Some of you have/haven't noticed. I originally was guiding Diane Fleming to make them "API Specifications" but I think "API Reference" is more apt for cross-project truthiness.
20:59:04 <hub_cap> markwash: \o/
20:59:05 <markwash> :-)
20:59:07 <ttx> "Stratius" :)
20:59:11 <markmc> hah
20:59:17 * markmc was about to say exactly the same
20:59:24 <annegentle> If you PTLs/TCers have input, do say so in the reviews.
20:59:38 <markmc> Rover? really?
20:59:59 <dolphm> hub_cap: it'd be nice if that list had a one liner explanation for each name lol
21:00:10 * jeblair looks for a weather baloon smothering someone
21:00:10 <hub_cap> dolphm: peep the last line
21:00:29 <markmc> hub_cap, nice work though, naming is frickin hard
21:00:36 <hub_cap> markmc: ya not a fan of rover or rex... but when i removed them it hurt someones feelings.. and im def not in the business of that LOL
21:00:38 <dolphm> hub_cap: then why is there a gist?!
21:00:45 <hub_cap> dolphm: cuz i locked it down
21:00:49 <hub_cap> it went crazy quick
21:00:53 <ttx> ok, end
21:00:57 <ttx> #endmeeting