20:01:40 #startmeeting tc 20:01:41 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:44 The meeting name has been set to 'tc' 20:01:52 A couple discussion topics on the agenda today 20:01:57 \o 20:01:59 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:02 \o 20:02:17 #topic Common API version discovery mechanism 20:02:27 We said in a past meeting that we would track progress on this 20:02:33 #link https://etherpad.openstack.org/api-version-discovery-proposal 20:02:41 gabrielhurley: care to give a quick update ? 20:03:19 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 yay baby steps 20:04:10 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 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 ok 20:04:42 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 questions on that ? 20:05:25 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 which concern was that? 20:05:53 the specific on is that /version/capabilities won't work for swift 20:06:07 it was on the etherpad (since deleted) and also on the mailing list thread 20:06:16 o/ 20:06:21 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 gotcha. I think I misunderstood that point. can you ping me separately about that so I can follow up? 20:06:43 as I said though, capabilities is gonna have to be a separate issure 20:07:22 dolphm: good question, and we may just have to have workarounds in the clients to deal with the "legacy" responses. 20:07:28 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 gabrielhurley: what about legacy clients? 20:08:25 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 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 backporting version discovery sounds like a painful, messy and dangerous task 20:09:21 IMHO it's a "from here on out this works" type of deal 20:09:22 agree 20:09:29 gabrielhurley: see notmyname's question just above 20:09:36 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 notmyname: I don't see a problem with it personally, but I'm open to concerns on it 20:10:09 the app technically already owns the / space, even if it's not responding there 20:10:22 OpenStack doesn't have good support for services not living at root currently 20:10:35 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 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 dolphm: +1000 20:11:23 dolphm: a new doc project ? 20:12:22 Other questions on that topic ? 20:12:30 ttx: don't know, good question 20:13:04 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 ttx: api documentation for the 300 response, approach to versioning that response (if any), perhaps /capabilities when we get there 20:13:41 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 gabrielhurley: +1 20:14:05 gabrielhurley: ok, so common API design rules 20:14:09 yeah 20:14:16 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 gabrielhurley: yes. Could be some wiki doc, though 20:15:06 pros and cons... wikis are easy to change ;-) 20:15:11 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 there is api-site 20:15:41 that documents the existing APIs 20:15:54 this is more about defining best practices and specs for *new* APIs 20:16:03 a goal for us all to work towards 20:16:20 gabrielhurley: ah, you want to include hateos, etc, there long-term? 20:16:22 we can have a new project and let TC plustwoing it 20:16:57 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 ttx: that'd make the most sense 20:17:23 anyway, implementation details. Anything more before we switch to talking about copyright headers ? 20:17:41 is there any new requirement for a doc standpoint to support capabilities? 20:17:48 for/from 20:17:53 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 annegentle: I don't think so 20:18:09 not yet at least 20:18:19 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 dolphm: absolutely. we can't force anyone to do anything 20:18:54 annegentle: it's more for downstream consumers (like Horizon) to understand what things should be allowed in the interface 20:19:09 but yes, the docs for extensions are weak. that's a separate issue. ;-) 20:19:37 ok, next topic 20:19:44 #topic Getting rid of copyright headers 20:19:55 markwash raised the idea of getting rid of copyright notices in file headers 20:20:02 #link http://lists.openstack.org/pipermail/openstack-dev/2013-May/009189.html 20:20:16 I think that *if* we do this, we have to do it consistently across all "OpenStack" projects 20:20:25 well 20:20:38 Do we really think its worth the effort? 20:20:40 for some more context #link http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html 20:20:48 mikal: is it really that much effort? 20:20:57 guys, can we hold on here for a sec 20:20:58 mikal: personally I'm not convinced of that 20:21:12 I agree with ttx about global, however I think this is going to be more problematic than it's worth 20:21:16 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 so there are three proposals in that email 20:21:40 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 the first proposal is pretty simple and cultural: we just try to avoid adding new copyright headers 20:22:05 hub_cap: None, except some false sense of *something* to *someone* 20:22:32 the justification for that is that copyright headers are a small but not insignificant effort to keep up to date 20:22:42 and our best efforts so far have produced huge inaccuracies 20:22:57 on top of that, they are completely unnecessary for folks to retain copyright 20:22:59 hub_cap: don't confuse the copyright statement with the license in the header, different issues 20:23:28 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 this proposal has no enforcement mechanism other than communication and review 20:23:53 we're essentially defining what the "new normal is" 20:23:58 markwash: I think you increase inaccuracies if you stop adding them while keeping old ones around 20:24:14 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 (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 don't really get it 20:24:47 TBH I'm still trying to figure out the maintenance burden? 20:24:56 dolphm: granting a copyright licenese is not the same as copyright ownership 20:25:10 jgriffith: there was an email in the thread that documented the effort that was going into reviewing the headers 20:25:14 My thought is if it makes somebody or somebody's legal team feel warm and fuzzy they can add copyright 20:25:25 dolphm: typically you or your employer owns the copyright in the code you write, and that's what the header indicates 20:25:28 markwash: I read it, but didn't see the effort 20:25:41 jgriffith: the problem is that we get a lot of cargo-culting around those warm-and-fuzzies 20:25:47 jeblair: makes sense; thanks! 20:25:53 markwash: I understand that 20:26:01 markwash: I'm not saying I like it/agree with it 20:26:05 I think another thing to consider is that, inaccurate copyrights could give the wrong impression to someone 20:26:09 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 Just a firm believer in choosing my battles 20:26:20 jgriffith, yes, yes 20:26:21 ttx: haha, +1 20:26:21 for example, several files in glance, I might think I can talk direclty to red hat to license the content 20:26:24 sorry 20:26:26 ttx, agree 20:26:50 * jgriffith is sad that markmc didn't agree with him :( 20:26:59 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 jgriffith, oh, I actually did 20:27:12 * jgriffith yell Yay!!! 20:27:39 well, I can see you guys have already dismissed my concern about the reviewing time 20:27:51 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 but frankly it is not fun when someone -1s your review becuase of copyright headers 20:28:11 markwash: they should be slapped 20:28:12 so reaching any kind of consensus around this is likely to take time 20:28:24 for a... limited gain. 20:28:28 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 annegentle: since folks should not believe the headers, they seem like a liability 20:28:50 Did we end up with NOTICE files being agreed to? 20:29:05 mikal: no 20:29:06 mikal, no, very much not 20:29:13 I don't really like NOTICE files either. . much better to accept that in-source isn't the way to go 20:29:14 I occasionally pull people up on Copyright headers 20:29:27 e.g. if they're obviously just sticking in OpenStack Foundation with no basis 20:29:35 it's not hard to understand what to put in a header 20:29:48 and I expect most people only need to be told once 20:29:55 and then don't make the most obvious mistakes again 20:30:02 markmc: my experience differs on that :) 20:30:06 and copyright is important for an open source project 20:30:21 sdague: on submitters? hopefully not reviewers 20:30:22 I've found repeated education required on both contributors and reviewers 20:30:33 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 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 that's sad, because honestly if you're reviewing code, you *better* have a basic understanding of this stuff 20:30:54 mikal: I feel like the whole "we have to remove them all" is a false dilemma 20:31:08 Ok, maybe you guys have a point here 20:31:14 russellb: people didn't get chosen for core reviewing based on how they evaluated copyright headers 20:31:17 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 markwash: in the sense of you just want to stop adding more and leave the current ones? 20:31:52 that's a false solution 20:31:53 markwash: cause that seems unfair to me... 20:32:11 mikal: that, plus remove the easy ones, like openstack foundation, and red hat (which has already offered unilateral permission) 20:32:15 mikal: in what way? 20:32:29 jeblair: how so? 20:32:38 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 markwash: I think you'll have the "well they did it, why can't I" 20:32:46 yeh, pretty mcuch 20:32:47 markwash: that will only make them more inaccurate 20:32:52 jeblair: +1 20:32:54 mikal: +1 20:32:54 and we'll say "those are historical artifacts of no import" 20:33:33 markwash: ideally, would you like no copyright notices anywhere? 20:33:42 if they are of no import, they should come out :) 20:33:50 jeblair: yes 20:33:50 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 and the corporate council of all the contributing companies feel that they are of no import? seems unlikely 20:34:10 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 i find that disturbing 20:34:29 jeblair: do you feel that way after reading http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html ? 20:34:36 I was impressed by the logic there 20:35:00 ttx: feels like a job for an AUTHORS file 20:35:18 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 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 or vcs logs 20:35:25 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 but a partial solution is a problem 20:35:44 markwash: I agree with you that technically and legally, what you propose is fine 20:36:09 jeblair: this is already policy on all the apache projects, do you not use them because of it? 20:36:19 markwash: but I expect contributors to continue to push copyrigth notices... and us having little ground to deny them 20:36:31 (unless they are all removed) 20:36:32 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 jeblair: many people don' 20:36:59 t add these headers for non-trivial changes 20:36:59 sdague: agreed. I expect more companies will react just like IBM, hence my "all of them or nothing" stance 20:37:07 jeblair: Look at nova/virt/libvirt/driver.py for example 20:37:20 jeblair: the true list of copyright holders for that file will be much longer than what's there 20:37:30 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 markwash: FWIW I agree with the philosophy and what your saying 20:38:00 markwash: I think the backlash is worse than the maintenance though 20:38:01 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 markwash: and I agree with others that it has to be global or nothing 20:38:31 Well, we also haven't tested the backlash at all 20:38:40 We could just try it with nova and see how bad it is 20:38:43 mikal: +1 20:38:44 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 mikal: unfortunately nova is the worst 20:38:55 Maybe we're over estimating how much people care 20:39:02 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 mikal: we already know IBM cares. I expect others to take the same "ok if everyone does it" stance 20:39:32 ttx: I feel like "moving to NOTICE" rather than "removing" might help soften the blow, do you agree? 20:39:52 ttx, not NOTICE, that's a whole other ball of wax 20:39:54 markwash: yeah, that's why I looked into that, see my thread on legal-discuss 20:40:13 ttx, maybe a centralised file, but naming it NOTICE opens a whole other thing 20:40:14 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 markmc: NOTICE or whatever works 20:40:54 jeblair: honestly, with different review teams on different projects, it's not going to be any worse than the current situation 20:41:09 in any case, I think its clear that files are not required to have copyright headers, correct? 20:41:53 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 and /maybe/ not worth it 20:42:32 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 then perhaps in a year or two, the problem will be relatively smaller in terms of cleanup 20:43:24 markwash: that's fine with me, as it's legally and technically accurate 20:43:43 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 so we should make sure people know that as well 20:44:04 and tend towards simple removal without replacement 20:44:07 markwash: but my trust in human nature is not as large as yours ;) 20:44:29 ttx: honestly, most heads-down devs I've talked to find headers very tedious 20:44:43 so being given license not to add anything would be nice for them 20:45:10 I'd like to remove all openstack foundation ones as well, honestly 20:45:19 but perhaps folks would prefer to wrap up the discussion for now? 20:45:28 markwash: I suspect most devs put in what their company asks them to. 20:45:33 markwash: can we agree to remove the openstack foundation/llc ones as a first step here? 20:45:33 Well, I think many of those were added by Rackspace 20:45:40 jeblair: you has a good rationale for keeping per-file info, though 20:45:44 ttx: we used to just copy and paste and update the year 20:45:46 dolphm: hardly 20:46:11 dolphm: i don't think they are yours to remove 20:46:22 (nor mine, just to be clear) 20:46:23 * markmc agrees with jeblair 20:46:30 jeblair: we would need permission from the foundation, yes 20:47:03 but considering all the inaccurate assignment to the foundation that goes on presently, I think they'd be inclined to accept 20:47:06 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 this is turning into quite a time sink 20:47:21 markwash, I actually doubt it - the foundation's counsel is pretty conservative IMHO 20:47:25 mikal: the board and the contributors are two separate bodies 20:47:28 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 markwash, dual-licensing is nothing to do with this 20:48:15 oh? 20:48:17 We should spend that time spent discussing this onto something much more useful, like suggesting names for stuff 20:48:19 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 markwash: it may also own copyright in code that fungi and I write. 20:49:02 ttx: Infuriating :-) 20:49:27 * fungi nods 20:49:51 jeblair: that seems like they don't need notices then 20:49:57 i bet ttx can write code too ;) 20:50:10 fungi: I can and I do :) 20:50:36 but i'm not a Foundation employee so I'll put in whatever I want ! 20:50:42 heh 20:50:55 ahh, right. crazy contractors 20:50:55 markwash: i'm not sure why the foundation owning a significant amount of code means they don't need a notice... 20:51:34 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 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 jeblair: the other issue is that folks at least for a time have been misattributing copyrights to the foundation 20:52:42 markwash, adding or removing the headers doesn't change ownership 20:52:42 markwash: that should stop. :) 20:53:16 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 ttx: +1 20:53:36 So documenting the technical and legal realities will certainly help in clearing things up 20:53:40 ttx: that sounds like a sane conclusion for the moment 20:54:08 but I wouldn't hold my breath on hoping everyone can dance to the same tune on that anytime soon 20:54:15 I think if we document the realities better, and some simple advice, we'll be in a better place 20:54:17 it's one of thsoe things you need to get right from the beginning 20:54:17 ttx: I have to offer https://wiki.openstack.org/wiki/Documentation/Copyright 20:54:32 because touching it afterwards is painful 20:54:47 because it's not just a technical issue. 20:55:20 annegentle: I'd like to streamline that page, would you be open to reviewing some changes? 20:55:27 would be good to add to https://wiki.openstack.org/wiki/LegalIssuesFAQ too 20:55:45 markwash: yes, and you could also move it out from under /Documentation/ 20:55:52 markmc: will do 20:56:05 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 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 heh 20:57:43 #topic Open discussion 20:57:54 2 more minutes, anyone has anything to raise ? 20:58:02 hard and fast is difficult when the legal speak is subjective enough to use wording like "substantially revised or updated" 20:58:03 I wanted to bring up a doc rename in progress here. 20:58:04 hey just wanted to mention that we are changing names in reddwarf land, nothign really to discuss 20:58:20 hub_cap: we could... suggest names. 20:58:27 we like to do that. 20:58:29 We've been removing "Developer Guide" from the titles of documents in -api repositories. 20:58:32 ttx: https://gist.github.com/hub-cap/5622714 20:58:40 my favorite so far is cask :) 20:58:49 hub_cap: you would 20:58:51 if u do have a suggestion feel free to ping me, ill add it 20:59:04 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 markwash: \o/ 20:59:05 :-) 20:59:07 "Stratius" :) 20:59:11 hah 20:59:17 * markmc was about to say exactly the same 20:59:24 If you PTLs/TCers have input, do say so in the reviews. 20:59:38 Rover? really? 20:59:59 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 dolphm: peep the last line 21:00:29 hub_cap, nice work though, naming is frickin hard 21:00:36 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 hub_cap: then why is there a gist?! 21:00:45 dolphm: cuz i locked it down 21:00:49 it went crazy quick 21:00:53 ok, end 21:00:57 #endmeeting