20:02:19 <ttx> #startmeeting tc
20:02:19 <openstack> Meeting started Tue Sep 15 20:02:19 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:24 <openstack> The meeting name has been set to 'tc'
20:02:32 <ttx> Agenda for this Technical committee meeting at:
20:02:37 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:55 <ttx> #topic OpenStack programming languages resolution
20:03:01 <ttx> #link https://review.openstack.org/217710
20:03:10 <ttx> The latest version tweaks the wording to be clearer, as suggested by annegentle and sdague
20:03:20 <ttx> This now has enough votes to pass. I'll approve it now unless someone screams
20:03:36 <russellb> lgtm!
20:04:07 <flaper87> lgtm and it addressed sdague's comments
20:04:11 * ttx leaves 30 more seconds for jeblair to re-register his +1
20:04:31 <jeblair> ttx: i think i just did?
20:04:37 <ttx> ah, refreshed
20:04:52 <ttx> #topic Cross-project track workgroup: collecting topics
20:05:05 <ttx> Since we don't have that much on the agenda, I figured we could use some time to discuss the cross-project track, since so many TC members are interested in helping there
20:05:11 <ttx> Two weeks ago a number of people signed up to help there:
20:05:18 <ttx> (dhellmann, sdague, mordred, flaper87, lifeless and me on the TC side + thingee & Rockyg)
20:05:25 <ttx> A few data points first...
20:05:26 * dims_ lurks
20:05:33 <ttx> Number of slots: We have seven 40-min time slots, and we can use 2 or 3 parallel rooms
20:05:43 <ttx> (in Vancouver we only used 2 parallel rooms, for a total of 14 slots)
20:05:53 <ttx> We have a time slot (at 2pm) where the Ops have nothing scheduled, so we can have devs+ops sessions in the track
20:06:22 <dhellmann> ttx: when you say 7 slots, is that total or is that 7 times the number of parallel rooms we decide to use?
20:06:29 <ttx> Also late afternoon the Ops track is in workgroup sessions so we can have more ops-oriented topics then as well
20:06:36 <jeblair> ttx: when you say 2 or 3, do you mean we can adjust as necessary, or do we need to decide on 14 or 21 sessions?
20:06:40 <ttx> 7 times * number of parallel rooms
20:06:48 <flaper87> +1 for dev+ops session
20:06:54 <edleafe> +1
20:07:04 <ttx> we have 3 rooms available -- whether we use all of them all the time is up to us
20:07:13 <flaper87> mmh, I wonder if 21 slotes would make it really difficult for folks that need/want to attend several
20:07:17 <lifeless> we have 9 top level items on https://etherpad.openstack.org/p/mitaka-cross-project-session-planning so far
20:07:17 <jeblair> ttx: gotcha
20:07:27 <david-lyle> flaper87: ++
20:07:37 <ttx> How do you want to handle the track contents ? Should we take suggestions, or just decide what the content should be ?
20:07:40 <flaper87> Lets see how many topics we have but I'm afraid 21 will be too many
20:07:50 <ttx> that etherpad was not communicated that wi
20:07:52 <ttx> dely yet
20:08:16 <jeblair> flaper87: if i'm following, we just leave rooms empty for some sessions to the degree we want to handle that.
20:08:17 <dhellmann> I'd like to see what we can come up with as a group, and then fill in with community suggestions.
20:08:25 <russellb> i'd suggest putting owner/session-lead names beside each proposal
20:08:28 <russellb> before it gets too far
20:08:32 <ttx> dhellmann: sounds good
20:08:35 <jeblair> russellb: ++
20:08:36 <russellb> bcause that's a pain to chase down later
20:08:38 <dhellmann> In the past, we've tended to have proposals for sessions that included just 2 projects at a time, though maybe folks understand the intent better now.
20:09:24 <flaper87> jeblair: yup
20:09:33 <anteaya> I don't see cross-project communication on the list, does anyone know if anne was going to propose a session for it?
20:09:55 <flaper87> anteaya: no idea here
20:10:12 <dhellmann> anteaya: that's a good one, why don't you start and you and annegentle can cooperate?
20:10:33 <anteaya> I can put it on the list since anne isn't here and let her decide how she wants to proceed
20:10:40 <dhellmann> ++
20:10:41 <jeblair> anteaya: ttx just signed up for it
20:10:41 <anteaya> happy to help if anne wishes
20:10:45 <anteaya> ah great
20:10:48 <anteaya> ttx: thanks
20:11:02 <jeblair> anteaya: at least, something very very similar i think :)
20:11:18 <anteaya> line 34 looks close enough to me
20:11:47 <dhellmann> ttx: it might be interesting to get some input from some of the working groups like API and UX, too
20:11:51 <Rockyg> anteaya, +1
20:12:04 <ttx> One thing lifeless said on the Glance thread made me think -- "goals you've identified are well within our [all OpenStack contributors] power to address during the next cycle"
20:12:13 <ttx> Wondering whether we should define a few cross-project goals on a given cycle
20:12:24 <anteaya> ttx we can try and see what happens
20:12:28 <Rockyg> dhellmann, Yeah.  the API group should have a session that pretty much involves all projects
20:12:31 <ttx> and use the cross-project track to discuss them
20:12:39 <lifeless> ttx: well - thats what I did with the constraints thing
20:13:05 <lifeless> ttx: it wasn't something that needed lots of people pushing on it, but affects /everyone/
20:13:36 <Rockyg> would a config session be worthwhile?  Getting consistency across configuration would help ops temendously
20:13:51 <flaper87> there are some, bigger ones, that have cross-prokject impact and needs some care. User facing notifications, for instance.
20:14:07 <flaper87> I believe there's a cross-project spec for that
20:14:23 <dhellmann> flaper87: is someone signed up to do that work? we've talked about it in the past, but the follow-through hasn't been great
20:14:35 <dhellmann> flaper87: and you have enough to do, so don't volunteer ;-)
20:14:45 <ttx> How about we close that brainstorming at the TC meeting next week, and decide if we need to open a CFP for more cross-project topics then ?
20:14:49 <flaper87> dhellmann: LOOL
20:14:53 <dhellmann> ttx: ++
20:15:02 <flaper87> dhellmann: I know Angus was writing the spec but then no one followed up as you said
20:15:02 <lifeless> ttx: I think we should ask for inputs now
20:15:13 <flaper87> but I kinda think it's important
20:15:22 <lifeless> ttx: there's no benefit I can see to waiting
20:15:24 <ttx> lifeless: <dhellmann> I'd like to see what we can come up with as a group, and then fill in with community suggestions.
20:15:32 <flaper87> Rockyg: if not in a session, it'd be worth mentioning it in the dev+ops session
20:15:34 <lifeless> ttx: yes, I saw that. I'm disagreeing :)
20:15:39 <ttx> ok, flight!
20:15:42 <ttx> or fight!
20:15:47 <lifeless> Adrenaline?
20:15:56 <ttx> Last cycle we used a Google form to take suggestions
20:16:23 <ttx> I'm fine either way. I agree that there is no harm in taking suggestions anyway
20:16:25 <flaper87> I liked the google form, it allowed to comment etc
20:16:27 <Rockyg> flaper87, notifications definitely are hot -- and how/when they should be logged.  jaypipes was also really on that for a while
20:16:34 <anteaya> for the lines that are just the title of a working group, like API working group, can we get a sense of the burning issue taht what to discuss or is just giving them a room to see each other sufficient?
20:16:36 <jeblair> flaper87: it did not allow everyone to comment
20:16:44 <flaper87> jeblair: oh, mh :(
20:16:48 <ttx> anyone up for creating the form ? Or should I just copy the old one and start it ?
20:16:59 <jeblair> didn't we use to have a nice web app just for this? :)
20:17:05 <lifeless> ttx: Than you for volunteering :)
20:17:15 <lifeless> *Thank*
20:17:26 * russellb was fond of the web app, personally
20:17:37 <jeblair> russellb: me too
20:17:42 <dhellmann> it didn't have features for commenting, did it?
20:17:50 * dhellmann only vaguely remembers
20:17:54 <Rockyg> google apps don't get China dev input -- they're blocked
20:18:19 <russellb> dhellmann: i think it did ...
20:18:44 <david-lyle> I remember comments
20:18:52 <dhellmann> ok, cool
20:18:56 * ttx doesn't look forward resurrecting that code
20:19:02 <russellb> heh, that's fine
20:19:04 <dhellmann> it's sort of short notice
20:19:30 <ttx> Rockyg: maybe we can redirect Chinese users to human proxies that will create entries for them ?
20:19:36 <flaper87> I guess it'll be etherpad to allow for everyone to chime in
20:19:59 <ttx> dhellmann: do you agree with opening up the suggestions pandora box asap ?
20:20:05 <lifeless> I have no concerns about giving folk the etherpad url
20:20:05 <jeblair> i'd love to be able to comment this time.  i was unable to do so last time.
20:20:39 <Rockyg> etherpad would work.
20:20:43 <dhellmann> ttx: if we really want to, that's fine. Using an etherpad failed at this scale in the past, which is why we used the google form, but if that's an issue for parts of the community we can sort through whatever comes into the etherpad
20:20:51 <ttx> etherpad is such a mess when we used it for large-scale collection
20:20:57 <Rockyg> Any way to enforce identification with a color or typed line?
20:21:10 <anteaya> Rockyg: you can't enforce anything with etherpad
20:21:21 <dhellmann> ttx: want to try a mailing list thread?
20:21:29 <ttx> Rockyg: trust me, that etherpad we used two cycles ago was a mess
20:21:45 <russellb> yeah..
20:21:50 <ttx> dhellmann: can be hard to tell what's a suggestiojn and what's not, but I guess we don't need to precisely count anyway
20:21:53 <Rockyg> ml would be cause a lot of traffic, but it would also refine the topics
20:21:54 <flaper87> Then I'd say google form and ask people to send emails if they can't access it
20:21:59 <dhellmann> https://etherpad.openstack.org/p/kilo-crossproject-summit-topics
20:22:31 <jeblair> i wish we could lead by example here and use a tool that's accessible to everyone in our community
20:22:50 <flaper87> jeblair: we can certainly be prepared for the next summit
20:23:08 * dhellmann hesitates suggesting a git repo
20:23:16 <anteaya> jeblair: ++
20:23:24 <harlowja> https://www.zoho.com/forms/ ? (similar to google stuff?)
20:23:28 <jeblair> flaper87: we've had since the last one.  :(
20:23:29 <jgriffith> jeblair: do you have anything in mind that is feasible to do now?
20:23:30 <russellb> yaml2summitsched
20:23:30 <anteaya> dhellmann: well gerrit can figure out comments
20:23:40 <dhellmann> anteaya: if all you have is a hammer...
20:23:43 <Rockyg> dhellmann, would be just like etherpad if you think about it, but with names attached at least
20:23:48 <anteaya> dhellmann: it is handy
20:23:50 <ttx> jeblair: suggestions?
20:24:12 * jgriffith despises etherpads FWIW (probably not much)
20:24:13 <jeblair> jgriffith: it seems the only objection to the previous summit app is cobwebs?
20:24:27 <jgriffith> jeblair: ahh... fair point
20:24:47 <jeblair> i'm moving house right now, so maybe i'm just used to clearing them out :)
20:24:50 <Rockyg> jgriffith, ++
20:24:51 <jgriffith> jeblair: I personally thought the "old app" worked fine
20:25:11 <ttx> jeblair: you clearly never had to clear out cobwebs from code I wrote
20:25:23 <dhellmann> if we're going to move back to that app, it sounds like ttx wants a volunteer to clean up the code and get it running again
20:25:27 <jgriffith> LOL
20:25:41 <flaper87> :P
20:25:44 <ttx> dhellmann: it's not difficult, it's just a lot of manual pain
20:25:49 <jeblair> ttx: i think i actually did have to figure out how to modify track leads while you were on vacation once :)
20:25:51 <jgriffith> I'd volunteer if I had a clue what i was getting int ot :)
20:25:55 <ttx> since we never got round to properly puppetize it
20:26:06 <dhellmann> ttx: maybe that's something for the next summit, then
20:26:08 <jgriffith> s/ot/to/
20:26:14 <jeblair> ttx: i will put money where my mouth is and help, but could not do it alone
20:26:33 <fungi> is the source in gerrit at least, or does it need importing?
20:26:40 <ttx> jeblair: if you help me and fasttrack any infra hoop, we might be able to pull it off quickly together
20:26:48 <ttx> fungi: all in gerrit
20:27:04 <jeblair> ttx: deal
20:27:08 * flaper87 volunteers ttx jeblair for this job
20:27:11 <flaper87> sold
20:27:24 <jgriffith> jeblair: I can offer up some assitance, but not a ton of time to promise
20:27:24 <fungi> and if memory serves, the server itself exists and has a mostly empty placeholder in our puppet
20:27:26 <ttx> #action jeblair and ttx to resurrect odsreg
20:27:47 <jeblair> whew, ttx remembers the name.  that's a good start.  :)
20:27:54 <jeblair> (and will save me some time)
20:28:07 <ttx> It's just that we need to ignore a lot of what it used to do, like sched.org scheduling
20:28:31 * jeblair is excellent at commenting out code
20:28:52 <david-lyle> ttx: ping if I can provide any django assistance
20:29:07 <ttx> I think I resurrected it once already, but used commenting out heavily to do so, rather than build the config options that would allow to run a light version
20:29:13 <russellb> what does the sched.org stuff now?
20:29:13 * anteaya pats david-lyle on the back
20:29:15 <russellb> manual?
20:29:21 <jgriffith> ttx: jeblair I mentioned as well I'm happy to help out if/where I can
20:29:22 <ttx> it's the incredible cheddar
20:29:27 <ttx> russellb: ^
20:29:29 <russellb> oic
20:29:32 <dougwig> HenryG, kevinbenton: what's the long-term plan with db deadlocks?  those retry decorators are stinky cheese.
20:29:48 <dougwig> OOPS, sorry.  :)
20:29:49 <ttx> which is like 10 times better than odsreg ever was, but does not do collection at all
20:30:06 <ttx> it's stateless and could even run in a container. That's how awesome it is
20:30:12 <jeblair> dougwig: nice!  cheddar to stinky cheese in 5 seconds!
20:30:18 <russellb> dougwig: timing was interesting
20:30:31 <dougwig> wow, that's awesome for not even reading the channel.
20:30:40 <markmcclain> hahah
20:31:15 <ttx> OK, so let me summarize... We continue to brainstorm on the etherpad, we find a way to start up odsreg for cross-project session collection before end of week, and we discuss it again next week.
20:31:22 <harlowja> dougwig https://aphyr.com/posts/327-call-me-maybe-mariadb-galera-cluster was a good read
20:31:23 <jeblair> ttx: and there's a mongodb joke in there somewhere
20:31:33 <harlowja> 'In this post, we’ll see MariaDB Galera Cluster allow transactions to read partially committed state.' (oops)
20:32:11 <ttx> #topic Communications workgroup report
20:32:17 <ttx> annegentle, flaper87: o/
20:32:25 <flaper87> o/
20:32:44 <flaper87> The last blog post came out before our lsat week's meeting
20:32:54 <flaper87> I don't think we need another one this week
20:33:02 <flaper87> but I'll sync w/ annegentle
20:33:45 * flaper87 silently goes back to his desk
20:34:20 <ttx> #topic Other workgroups
20:34:27 <ttx> Any other workgroup with a report ?
20:34:50 <ttx> I guess not
20:34:58 <ttx> #topic Open discussion
20:35:05 <ttx> Lots of things to discuss in Open discussion this week !
20:35:26 <ttx> cpallares wanted to mention something about CoC, but is not around currently
20:35:42 <ttx> let me find what she told me
20:36:19 <ttx> "I have merged the Code of Conduct here https://etherpad.openstack.org/p/CoC"
20:36:30 <ttx> comments welcome ^
20:36:33 <flaper87> awesome
20:36:36 * flaper87 clicks
20:36:38 <ttx> #link https://etherpad.openstack.org/p/CoC
20:36:53 <ttx> * Glance priorities for Mitaka (http://lists.openstack.org/pipermail/openstack-dev/2015-September/074360.html)
20:37:02 <ttx> dhellmann came up with target priorities for the Glance team, from the perspective of the rest of the OpenStack community
20:37:03 <dhellmann> thanks to everyone who has joined in that conversation
20:37:21 <ttx> I think that's great work atht we should do more often
20:37:28 <flaper87> dhellmann: ++
20:37:45 <Rockyg> Bravo!
20:37:46 <hogepodge> it was great discussion, and helped to clear up some misconceptions that I had also
20:38:03 <jeblair> i think it's really good and like the conversations that have come out of it
20:38:22 <jeblair> and especially the information
20:38:31 <ttx> Yeah, at the very least that helps clearing things up, and ideally that would steer the PTL election discussion and the Mitaka cycle in the direction most of the community want Glance to take
20:38:46 <flaper87> From a community perspective, I believe this leaves me with: 1) We need to look after other projects more often 2) We gotta improve our communication and make sure concerns and doubts are properly communicated
20:38:50 <dhellmann> yeah, the confusion seems in large part to be a communication issue, so I'm glad folks are talking more now
20:38:52 <jeblair> i feel like a lot of people have a clue what's going on now and what people are talking about.  and we're learning real things about how glance is used and not just speculating.  :)
20:39:16 <flaper87> Many misconceptions people had about Glance were communicated late or to other folks that probably weren't familiar enough with the API.
20:39:19 <hogepodge> as the local defcore/interop rep, there's some relevance to capabilities outside of nova that we're working on, particularly with regards to glance, cinder, neutron, and keystone, all of which have cross-project concerns
20:39:30 <flaper87> Just to be clear, this is not a complain but an observation for us as a community
20:39:30 <Rockyg> would a cross-project session be worthwhile for Glance talking to the rest of OpenStack?
20:39:37 <ttx> I take it as a bit of a reality check, more than as a top-down edict
20:39:40 <flaper87> We can't let situations like this to go thus far
20:40:01 <ttx> and it may cut both ways
20:40:19 <dhellmann> hogepodge: I'm going to be pushing for us to improve communication between contributors and defcore over the next cycle, going both directions.
20:40:39 <flaper87> Rockyg: I'd probably recommend people to attend Glance sessions about what will happen in Mitaka
20:40:50 <hogepodge> to that end, there are a bunch of iterop reviews in openstack/defcore that it would be nice for the community to review. I can post to the mailing list.
20:40:58 <flaper87> not sure what could be said in a cross-project session of Glance folks talking to the rest
20:41:02 <dhellmann> hogepodge: yes, please start a thread
20:41:17 <Rockyg> flaper87, the only problem with that is when the other projects' important sessions conflict...
20:41:18 <flaper87> hogepodge: ++
20:42:05 <flaper87> Rockyg: yup, that's unfortunate
20:42:34 <ttx> ok, another topic I wanted to discuss now is:
20:42:37 <ttx> * Convergence on common deprecation policy
20:42:45 <ttx> I wanted to quickly discuss convergence on a common deprecation base policy, following the thread at:
20:42:46 <jgriffith> or just have consistent API's and missions
20:42:46 <dhellmann> Rockyg, flaper87 : as long as we get the nova/glance and cinder/glance sessions we need, that should be good for right now
20:42:47 <jgriffith> AKA don't break crap
20:42:56 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-September/073576.html
20:43:03 <ttx> we also discussed it at the cross-project meeting last week
20:43:10 <ttx> As I posted recently on the thread, it looks like there is convergence on:
20:43:20 <ttx> "config options and features will have to be marked deprecated for a minimum of one stable release branch and a minimum of 3 months"
20:43:22 <Rockyg> dhellmann, ++
20:43:27 <lifeless> yeah
20:43:30 <ttx> with some language to encourage major features to be marked deprecated for at least two stable release branches
20:43:39 <lifeless> so I want to call out in particular that libs and clients have had different rules
20:43:42 <ttx> So I'll post a new patchset to https://review.openstack.org/207467 along those lines
20:43:50 <dhellmann> ttx: have you compared the API deprecation timelines proposed against what defcore expects? we might need to call out defcore explicitly in that document
20:44:16 <annegentle> dhellmann: good q
20:44:21 <dhellmann> perhaps hogepodge can look at it and comment
20:44:31 <hogepodge> dhellmann: will do
20:44:52 <ttx> dhellmann: well, the doc says you need to do a survey before deciding on the deprecation timeframe
20:44:52 <dtroyer> lifeless: that's one reason for the time-based components
20:44:53 <dhellmann> we should be fine to use a shorter time frame for something that isn't used by defcore, but we need to make sure we know how to tell what is/isn't
20:44:55 <lifeless> specifically clients for a long time didn't break anything ever
20:45:11 <lifeless> that changed with the branching stuff relatively recently
20:45:16 <ttx> so somethign that is part of a defcore capability would certainly have a longer deprecation time to account for that
20:45:25 <dhellmann> ttx: I'd like for there to be explicit language mentioning defcore, since we've identified that as a thing projects don't know enough about
20:45:27 <lifeless> libs have been somewhat unclear about what they can and can't do
20:45:50 <hogepodge> dhellmann: we have two active standards at any time, which can cover different versions but still fit in a deprecation window, but we should make sure everything matches up and makes sense
20:45:51 <lifeless> dtroyer: yes
20:46:01 <ttx> lifeless: should we say that the proposed rule is for services ?
20:46:03 <dhellmann> hogepodge: we need a way to say that clearly
20:46:04 <lifeless> dtroyer: I'm advocating discussion around not branching clients or libs this summit
20:46:11 <hogepodge> dhellmann: agree
20:46:11 <ttx> and keep the discussion opened for libs ?
20:46:24 <dtroyer> lifeless: ++
20:46:32 <hogepodge> dhellmann: we also need to make sure that deprecation takes into account cross project concerns
20:46:47 <dhellmann> hogepodge: ++
20:46:54 <ttx> hogepodge: the rule is just one of the things the tag mandates
20:47:10 <ttx> See https://review.openstack.org/207467
20:47:10 <lifeless> ttx: I don't want to exclude clients and libs from backwards compat - its important there. I think though that the expression may be different
20:47:45 <lifeless> ttx: I'm still working up the discussion - as long as we can revisit the tag I think its fine today
20:47:46 <ttx> lifeless: would you care to propose something on that ML thread ?
20:47:51 <lifeless> ttx: nope :)
20:48:02 <flaper87> lifeless: mmh, if we're following semver in libraries, shouldn't we just stick to that ?
20:48:06 <fungi> lifeless: part of the issue with the client-libraries is that they're both application developer/api user client implementations and also cross-service communication libraries between openstack server components, and those use cases have clashed spectacularly in the past
20:48:10 <lifeless> ttx: in that - I don't think I've got a cogent holistic case to present yet
20:48:16 <lifeless> fungi: yes, I get that
20:48:18 <ttx> ok, I'll make the poilicy service-specific and say something is cooking for libs
20:48:35 <lifeless> flaper87: this is orthogonal to semver
20:48:46 <lifeless> flaper87: we should totally still be following semver
20:48:47 <dhellmann> ttx: ++, we can amend the policy to add lib stuff when we work out the details
20:48:51 <flaper87> ttx: ++
20:49:09 <flaper87> lifeless: sorry, I probably just missed the context of what you were saying
20:49:10 <fungi> lifeless: so the client libraries didn't actually avoid breaking anything ever, they just avoided user-facing breakage (and basically changed anything they wanted for server-to-server communication)
20:49:28 <lifeless> fungi: by user I think you mean CLI
20:49:39 <lifeless> fungi: anyhow, I'm familiar with the debate
20:49:44 <fungi> cli and "cloud application development"
20:50:09 <EmilienM> §b dmacpher-afk
20:50:19 * dhellmann squints at EmilienM
20:50:49 <ttx> OK, last thing I wanted to mention is:
20:50:53 <ttx> * No/Low/Danger-diversity tag name bikeshedding (https://review.openstack.org/218725)
20:51:07 <EmilienM> dhellmann: sorry
20:51:10 <Rockyg> PUce!
20:51:10 <ttx> Another WIP tag, the one to signal fragile affiliation diversity, which has turned into a name bikeshedding contest
20:51:22 <ttx> The argument is not really about the tag itself or how it was defined, but mostly on how much negative the name should be
20:51:22 <lifeless> fungi: dhellmann: and thers - started a etherpad at https://etherpad.openstack.org/p/branchless-clients-and-libs : I haven't put content in yet but will be doing so today
20:51:23 <dhellmann> EmilienM: np, I just couldn't make out what that was, my client didn't like some of the unicode :-)
20:51:31 <ttx> feel fre to weigh in, it's fun
20:51:58 <flaper87> ttx: </sarcasm> (?)
20:52:04 <annegentle> ttx: I do not think you know what fun means :)
20:52:24 * dhellmann hands ttx a teddy bear
20:52:42 <ttx> personally I think it's ok to be slightly negative, but apparently YMMV
20:53:11 <annegentle> ttx: small teams can be nimble and quick
20:53:14 <ttx> anyway, that one is driven by jogo, to whom I extend my encouragements and thanks
20:53:15 <russellb> i've been thinking about it a lot, and coming around to the thinking that negative tags may be more harmful than helpful
20:53:15 <annegentle> ttx: but yeah
20:53:48 <ttx> annegentle: this is not a question of small, or fast. It's a question about the risk of not being there at all tomorrow.
20:54:02 <lifeless> russellb: +1
20:54:08 <russellb> mostly because i want to be a more friendly and welcoming community, not one where you show up and get a set of "you're bad" labels
20:54:09 <lifeless> russellb: sorry, I mean -(-1)
20:54:12 <russellb> heh
20:54:18 <ttx> Those projects can be killed by the will of a single person, and it's not fair to expose our users to that risk without a warning sign
20:54:32 <edleafe> all projects are safe, but some are safer than others :)
20:54:37 <lifeless> ttx: hang on
20:54:49 <lifeless> ttx: Not all our users are equally sophisticated
20:54:58 <lifeless> ttx: Not all our users use things from git etc
20:55:12 <ttx> edleafe: ++
20:55:15 <lifeless> ttx: we have distributors and vendors who have direct relations with a huge fraction of our users
20:55:17 * jeblair wonders which person has this power...
20:55:18 <markmcclain> russellb: I think welcoming also means taking on the challenge of us openly acknowledging a team is danger without making it too difficult to dig out of the hole we created by labeling them as at risk
20:55:49 <anteaya> I have osdreg up and breathing
20:55:50 <ttx> jeblair: the CEO of the company who owns 99% development of a project can kill it. It happened before and will happen again
20:55:51 <annegentle> ttx: right, right
20:56:03 <lifeless> ttx: a very diverse project with deprecation periods stable releases and puppet guides may still be a bad choice for a user
20:56:09 <fungi> "killed" is used liberally here. the project ceases to have development resources, but can be picked up by new contributors as soon as anyone cares
20:56:19 <edleafe> lifeless: but not for that reason
20:56:24 <ttx> lifeless: it's not the only warning sigh. It's just "a sign"
20:56:28 <Rockyg> anteaya, you go, grrl!
20:56:45 <jeblair> anteaya: nicely timed, btw :)
20:56:49 <ttx> fungi: is anyone picking up MagnetoDB ?
20:56:54 <edleafe> lifeless: this is just another data point for them to evaluate
20:56:56 <fungi> i think the projects which die because of a change in availability of development resources also had little to no user community
20:57:05 <ttx> if that project did not have diversity before, it's unlikely to get it once it's killed ?
20:57:08 <lifeless> edleafe: so, I'm not debating *that*
20:57:10 <jeblair> anteaya: will resurrect any important dead projects
20:57:13 <annegentle> is it like guns don't kill people people kill people fungi ttx?
20:57:22 <lifeless> ttx: projects have had diversity and lost it
20:57:24 <flaper87> well, users don't necessarily means devs
20:57:25 <anteaya> jeblair: not sure about that
20:57:28 <lifeless> ttx: I've been involved in one such...
20:57:40 <edleafe> fungi: so how about a "lack-of-community-support" tag? :)
20:57:41 <fungi> outside openstack, at least, it's not unusual for some company to stop development on an open source application and then the community forks or resumes development on it themselves
20:57:44 <lifeless> here's a suggestion
20:57:45 <ttx> lifeless: not to the point of getting that tag, right ?
20:57:45 <edleafe> that's less negative
20:58:12 <david-lyle> the brought-to-you-by sponsorship tag?
20:58:20 <edleafe> david-lyle: ha!
20:58:26 <lifeless> ttx: I have't checked the stats, but suspect its due to a couple of the spin-out tools keeping diversity, not the $project
20:58:28 <fungi> flaper87: any sufficiently advanced free software user is indistinguishable from a developer ;)
20:58:41 <lifeless> The issue AIUI is that we want to say 'has not earnt tag X'
20:58:44 <lifeless> and make that discoverable
20:58:55 <flaper87> fungi: lol
20:59:08 <edleafe> no matter how you wrap it, it's a negative condition
20:59:12 <lifeless> I know, the rule for 'danger' was going to be lower than the rule for 'diverse' - but fundamentally we want to surface that there is a badge they haven't earnt.
20:59:15 <lifeless> so why don't we do that
20:59:18 <ttx> lifeless: I don't think so. There is a space where the project is not diverse and still is not in danger
20:59:20 <lifeless> in the UI
20:59:28 <annegentle> ttx: I agree
20:59:30 <ttx> those are different questions
20:59:32 <lifeless> show earnt and unearnt badges
20:59:32 <thingee> 1 minute warning
20:59:38 <flaper87> I kinda feel what we're discussing here is how to make it less negative when the condition itself is just bad
20:59:44 <flaper87> not necessarily the project's fault
20:59:44 <lifeless> I don't think its bad
20:59:45 <dtroyer> edleafe: exactly, and recognizing that should be ok
20:59:50 <lifeless> I think its the starting point for things
20:59:54 <lifeless> start small and ramp up
21:00:32 <ttx> anyway, more on that review!
21:00:35 <flaper87> lifeless: no one is arguing about that but rather that as lon as you're small, we need to commuicate that
21:00:37 <ttx> time is up
21:00:44 * flaper87 hugs everyone
21:00:46 <ttx> #endmeeting